Dear Laslo,
sorry for the late reply, I had a really busy week (course to teach) :/.
I didn't have the chance to test the new code, which I will do soon,
hopefully.
If I understand correctly your solution is to read the rlimit from the
system and then update accordingly.
Now it seems to me a good solution, however I have to ask: do we really
need to set the rlimit on the number of processes (which are fixed)?
I mean, what is the rationale behind it? Security purposes?
I'm just asking out of curiosity, to understand better the design
choices :D.
Thank you,
Giulio.
On 1/21/21 1:18 AM, Laslo Hunhold wrote:
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
