Re: AW: Still much more than 350 sockets needed!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409

Attachment: pgpq9LmM2iEo2.pgp
Description: PGP signature

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux