[systemd-devel] runtime directories for services vs. tmpfiles

[Kay Sievers]

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
thing.

Kay