Re: Suggest documentation of "soft limit" logic for chpst

[Laurent Bercot <ska-supervision@skarnet.org>]

> I had been trying to raise the limit on number of open files via 'chpst
> -o 10000'.  I thought this was working properly, so I was focused on
> examining the daemon for bugs.  Then I finally had the insight to test
> whether 'chpst -o 10000 && ulimit -a' was doing what I expect.  Now I'm
> doing a 'ulimit -n 10000' instead of a 'chpst -o 10000'.

 chpst is not a shell builtin, and does not work the way ulimit does.
It does not change the state in your shell ; it's impossible to do that
with external programs on Unix, only builtins can.
 chpst only changes the _process state_ of the _current process_, i.e.
chpst itself, which execs into the command line you're supposed to give.
'chpst -o 10000' does nothing, but 'chpst -o 10000 frob' will run 'frob'
with a modified max number of open files. Only 'frob' can see the changes
and that has nothing to do with soft or hard limits.

 By the way, 10000 is overkill. Even if your kernel has very high limits,
any program that handles 10000 file descriptors will have serious
performances issues, unless the kernel _and_ the program are specifically
designed. for that case.
 See http://www.kegel.com/c10k.html for more information.

-- 
 Laurent