>… but it doesn't really explain why? Could you perhaps elaborate?
Because the terminology is terrible, and there's nothing soft about
the "soft" limit. There is only one limit that counts: the "soft" one.
The "hard" limit is not a resource limit, it's a framework: it sets the
window in which the real limit can evolve. Setting the (soft) limit
is a local operation; setting the window, on the other hand, should be
system-wide, and only done once. If you allow the "hard limit" to be
changed after that one time at boot, there is just no reason for the
existence of this "hard" limit at all - it becomes useless.
> Usually, if I'm raising a limit, I have one specific
>process in mind that needs the high limit, so raising the limit for only
>that process protects against unexpected resource overuse by other
>processes.
Yes, and raising the "soft" limit is exactly how you do that. The
"hard limit" just tells you how high you can raise it - it's a property
of the system.
> That would of course be less likely if other processes still
>had to raise their soft limit first, but the documentation also tells me
>there's "virtually no reason" to ever raise the hard limit without also
>raising the soft limit.
Indeed, I may need to change the behaviour of s6-softlimit to allow
the setting of the hard limit only, without touching the soft limit
unless it would be higher than the value. The -H and -h options were
added as afterthoughts, grafted on the code, and I realize the
implementation isn't very good. The documentation says there is
virtually no reason to use -h because it's risky, but the program
really should do better. Thanks for directing my attention to it.
--
Laurent
Received on Sat Dec 06 2025 - 21:22:50 CET