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

[Gildas <3ntr0p13@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

Hi,

I know it's weird to quote a subject from 2005, but I found this while I
was looking for a reason why chpst wasn't behaving the way it was expected
(when one assume you can raise the limit above the hard value).

It seems that chpst is very often used to raise the number of file limit
when starting a daemon as root, as the default file number limit in Linux
(1024) is not enough for a number of use cases.

To be able to do that, though, one as to do "ulimit -n 5000; chpst -o 5000
command", which seems to be like a waste of resources since the same
syscalls are called again and again.

It would be nice if you could raise the hard limit above its  previously
set value in a simpler way that would make it more efficient for the use
case above.

I've tested a naive patch (https:// <https://gist.github.com/3757463>
gist.github.com
<https://gist.github.com/3757463>/3757463<https://gist.github.com/3757463>)
that allows to set a higher value for both soft and hard values when the
given limit is over the hard value AND the effective uid is 0.

This would fix the use case above as your could run a command as root with
a higher file limit value than the default with a more concise "chpst -o
5000 command".

Does it makes sense? What have I overlooked? Thanks for your insights on
the matter!

If  it actually makes sense, and this modification could be merged, I'd be
glad to provide a patched version of the manpage as well!

Regards, Gildas