Re: setting open files limit for daemon processes

[Attila Lendvai <attila@lendvai.name>]

> > 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)