On Mon, 18 Jan 2021 23:03:11 +0100 Laslo Hunhold <[email protected]> wrote:
> that is a really nice observation! Thanks for pointing it out and your > elaborate explanation. I must honestly admit that I assumed the limit > was per process and not per user. I'll think about how to approach > this the best way; given your aforementioned fact, I only see two > options: > > 1) Don't touch the rlimits and let it fail, giving a proper error > message (might be problematic for open file descriptors that > might get exhausted at runtime). One can also check the limits > beforehand and error out (e.g. if we cannot guarantee 4 fds per > slot). > 2) Uncrement the rlimits by first reading them and setting the > incremented value. possible problems here are TOCTOU (even > though the risk here is not too high) and a possible > interference in things that shouldn't be touched by convention. To give a followup, I went with option 2), because it allows the smoothest operation. Quark is run as root and thus can seize all the assets it needs. I'm sure many set their global resource limits to reasonable values, but if you run your server and give it a thread and slot count, you can estimate that it might exceed your resources. In that respect, it is forgivable by quark to just raise the bar instead of failing. Thanks again, Giulio, for your input and patch suggestion. I hope this fixes your issues in your case! With best regards Laslo
