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? 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. 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 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...
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
