[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: setting open files limit for daemon processes
From: |
Attila Lendvai |
Subject: |
Re: setting open files limit for daemon processes |
Date: |
Fri, 25 Feb 2022 14:09:43 +0000 |
> > su - [daemon user] -c 'ulimit -aHS' -s `which bash`
>
> That might set the limit of the user when that user logins (and hence,
> PAM things are run), but I don't see how this changes the limit of
> shepherd itself. I don't think that shepherd interacts with PAM at
> all?
my understanding of PAM is rather limited, but i guess it cannot hook into
setuid(), and as such it has no means to affect the ulimits of processes spawned
by Shepherd.
> My suggestion is to do (setrlimit RLIMIT_NOFILE [...]) inside shepherd
> itself -- when shepherd starts, or between 'fork' and 'exec'. Maybe
looking at the code, it'd be nice if we factored out a variant of fork (maybe
called CALL-IN-FORK) that took a thunk and called it in the forked path. that
would allow me to use that abstraction in user code to easily insert a call to
setrlimit before the EXEC-COMMAND, or whatever else is needed.
maybe using that abstraction we could straight out move EXEC-COMMAND to the guix
side? my thinking here is that toching/testing/updating the Shepherd codebase
seems to be much more trouble than the Guix codebase.
i'd be happy to play with this, but i don't know how to run a Guix VM that is
built using my modified Shepherd; i.e. i have no idea how to test what i'm
doing.
> an '#:open-file-limit' argument could be added to 'fork+exec-command'?
that would be the safest/simplest way to resolve this, but then what about all
the other limits?
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“There can be no keener revelation of a society’s soul than the way in which it
treats its children.”
— Nelson Mandela (1918–2013)