Suggest documentation of "soft limit" logic for chpst

Suggest documentation of "soft limit" logic for chpst

[Jared Rhine]

It might be helpful to have a little bit of discussion on the chpst
manpage which outlines that chpst is dealing with soft limits.

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'.

I had read the manpage a couple of times while doing this investigation,
but it's brief with respect to what chpst is really doing with these
switches.  It wasn't until I saw "softlimit(8)" at the bottom that I
started to suspect the source of my problem.  Maybe mentioning the
actual logic in-line with the manpage text would be useful.

I'd also be in favor of chpst being able to raise limits (hard ulimit)
to emulate ulimit more directly, but that's a separate conversation.

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

[Laurent Bercot]

> 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

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

[Jared Rhine]

On Tue, 2005-11-22 at 05:54 +0100, Laurent Bercot wrote:
> > 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.

Sorry.  A typo of mine caused you to overinterpret my cluelessness.  I
am aware of both ulimit and chpst's behavior; I could not be using chpst
successfully in other contexts without that awareness.

The actual command I used to test was `chpst -o 10000 sh -c 'ulimit
-a'`.

The rest of my concerns still stand.  It would be helpful to have the
specific soft/hard behaviors of chpst documented in the man page.  chpst
may still benefit from fuller ulimit-style support (specifically
raising), as opposed to only the "limit" operation of setrlimit(2).  As
I believe both chpst and the shell ulimit call use the same system call
to change process limits, chpst could in theory be made to support more
ulimit-style features.

> By the way, 10000 is overkill.

With respect, since I did not indicate the context or appliciation for
my need for 10K open files, you don't have any basis by which to judge
whether it's overkill.  Trust me, I need 10K open files for the
application in question, and there is nothing amiss with my application,
system, or design.

I appreciate your attempts at education.

-- 
Jared Rhine <jared@wordzoo.com>

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

[Laurent Bercot]

> A typo of mine caused you to overinterpret my cluelessness.

 Okay. Sorry about that - couldn't be sure. ;)


> The rest of my concerns still stand.  It would be helpful to have the
> specific soft/hard behaviors of chpst documented in the man page.

 I'm a bit confused by your question, then.
 Only soft limits are taken into account by the kernel: only soft limits
can generate SIGXCPU, make sbrk() or open() fail, etc. etc. When you say
"changing the limits for a process", you're naturally talking about
soft limits.
 Hard limits exist only to prevent a process from raising its soft
limits beyond certain values. They're only taken into account when
performing setrlimit(). Hard limits don't limit a process, they limit
a process' limits. ;)

 I'll try to reformulate your suggestion:
 Whereas ulimit allows hard limit manipulations as well as soft limit
ones, chpst only handles soft limits. This can be confusing for ulimit
users; the chpst documentation should mention the fact that only soft
limits can be modified.
 Additionally, it would be nice to have an option to make chpst change
hard limits too, and thus emulate ulimit's behaviour more closely.
 Is my reformulation accurate ?


> With respect, since I did not indicate the context or appliciation for
> my need for 10K open files, you don't have any basis by which to judge
> whether it's overkill.  Trust me, I need 10K open files for the
> application in question, and there is nothing amiss with my application,
> system, or design.

 I believe you. Pardon my curiosity, then: what kind of application are
you running ? Is it a server, and in that case, is it using specific
techniques to avoid the c10k problem ? I'll understand perfectly if you
choose not to answer, or to answer in private.

-- 
 Laurent.

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

[Gildas]

[-- 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