[systemd-devel] runtime directories for services vs. tmpfiles
kay at vrfy.org
Tue Jul 16 12:25:48 PDT 2013
On Tue, Jul 16, 2013 at 9:17 PM, Tomasz Torcz <tomek at pipebreaker.pl> wrote:
>> If RuntimeDirectory= is set we'd create it and chown() it to the UID/GID
>> set with User= and Group=. We'd apply the mode specified in
>> RuntimeDirectoryMode= to it.
> There are daemons which do, in order:
> 1) start as root
> 2) open some root-only resources, like network sockets
> 3) change to less priviledge user
> 4) if all OK, write PID file or some state in /run
> 5) do the work
> Those daemons can't have User= specified, because 2) would fail.
> And because they must start as root, systemd can't know what
> chown() to do on runtime dir.
> So what's the solution?
> a) declare those daemons incompatible with RuntimeDirectory* stuff
> - nothing changes, they continue to use separate tmpfile .conf
> b) fix the daemons?
B, sure, when it's private to the daemon and it run as root, it should
prepare its own environment itslef. It's just weird to assume someone
else does that for the daemon.
And it's just slightly less broken to use a tmpfiles to work around
such a broken daemon init. :)
Stuff is different though if the directory is some kind of an API,
then tmpfiles are sure fine, and creating them at boot is the right
More information about the systemd-devel