… 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
