I know what needs done, but not necessarily the most elegant way to do it:
You can create a group, called "audio" or something, and make sure the
users who need sound are a member of that group.
chown .audio /dev/dsp, then
chmod g+rw /dev/dsp
The problem with this is that it will disappe
ar/lock/subsys/fam
;;
*)
echo $"Usage: $0 {start|stop|}"
exit 1
;;
esac
Marc DeTrano wrote:
Yep, I was not out of the woods yet...
This is a tough issue to reliably test. It looks like in addition to
the soft and hard limits you can set in the limits.conf, there
Yep, I was not out of the woods yet...
This is a tough issue to reliably test. It looks like in addition to
the soft and hard limits you can set in the limits.conf, there is also a
kernel-limit to cap it all off. root can override that limit, so I also
added:
ulimit -n 2048
in the start s
hardnofile 2048
restarted xinetd (to freshen famd), and now, doing the same test, a new
user could login even with the open file count for famd up at 1038.
Hope that helps for anyone facing a similar issue.
Marc
Marc DeTrano wrote:
I think the "unlimited" in that
there is the trusty lsof + wc
lsof -c famd | wc -l
398
In fact, looking at the lsof output for famd does show a lot of files
opened (clearly for various fam clients), but just one userid (that
changes).
Perhaps its time for some more experimentation.
Marc
Joe Baker wrote:
Marc DeTrano wro
g the 1024 limit. (maybe?) Since the user is
"changing" I would have to up the limits across the board.
Thanks for your help.
Marc
Joe Baker wrote:
Marc DeTrano wrote:
I have started to see a problem with famd reporting "too many open
files", similar to the issue rec
I have started to see a problem with famd reporting "too many open
files", similar to the issue recently posted by John McMonagle.
Running LTSP 4.1, on a Mandrake 10.1 system.
cat /proc/sys/fs/file-max
309816
ulimit -a
core file size(blocks, -c) 100
data seg size (kbytes,
