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

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

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