On Wednesday 26 April 2006 11:15pm, Callum Lerwick wrote:
On Wed, 2006-04-26 at 15:17 -0600, Lamont R. Peterson wrote:
> * soft nofile 1024
> * hard nofile 65535
>
> Of course, set values that make sense for the soft limit, since
> unprivileged users can't change that. On RHEL & FC, pam_limit.so is
> loaded
> in /etc/pam.d/system-auth, so no modifications will be needed.
Why change the soft limit at all?
For those who didn't catch it earlier (this is from the email you just
quoted):
"OK. Running "ulimit -n 2048" on the client box in my 3-box setup, yielded
the result that 2045 network connections could be made, as root. Trying to
run that ulimit command as an unprivileged user results in an error message
(as expected)."
Note that "ulimit -n" did *not* work for unprivileged users.
Leave it be, and just do a ulimit -n
before starting the descriptor eating process. Also, * is probably
dangerous, put a specific username there. Or at least a group.
So, unless they are running their client app as root, ulimit -n will not work.
Azureus likes to eat file descriptors. (It seems to keep every file
open
at all times on every active torrent. Ugh.) Its impossible to activate a
torrent with lots of small files unless you raise the limit. I raised my
hard limit in limits.conf, then I have a script that starts up Azureus
like this:
#!/bin/sh
ulimit -n 16384
cd ~/azureus
JAVA_PROGRAM_DIR="/usr/lib/jvm/jre-1.5.0-sun/bin/" \
exec nice -1 ./azureus
It would seem that you run that as root. Otherwise, the ulimit command
wouldn't work.
Works nice. Note that greatly raising a users descriptor limit opens
the
possibility of a user or two running into the *kernel* descriptor limit,
which IIRC is set at compile time. I imagine this could cause a nasty
DoS situation. I've never tried it so I dunno...
On my notebook:
# cat /proc/sys/fs/file-max
102640
# echo "10000000" > /proc/sys/fs/file-man
# cat /proc/sys/fs/file-max
10000000
So, that's tunable. But, is there a compiled in ceiling that such a setting
passes? Will the echo command fail if I hit such a limit? If I hd the
kernel source handy (and if I had time, today), I'd go hunt it down.
--
Lamont R. Peterson <lamont(a)gurulabs.com>
Senior Instructor
Guru Labs, L.C. [
http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409