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

[Tom Gundersen]

Hi Michael,

On Tue, Jul 16, 2013 at 3:24 AM, Michael Biebl <mbiebl at gmail.com> wrote:
> an interesting issue was raised as part of reviewing a patch for
> iodione [1], a system service which needs a runtime directory. We
> thought this might need further dicussion, so reposting the issue to
> systemd-devel:
>
> For system services needing a runtime directory, we basically have two
> (three) options nowadays
> 1/ use ExecStartPre=/usr/bin/mkdir /var/run/foo
> 2/ use a tmpfile snippet
> (3/ let the daemon create the runtime directory itself)
>
> In [1] we recommended the the usage of 1/ over 2/.
> The main reason for that were, that systemd-tmpfiles properly handles
> applying security policies, like SELinux labels, and it avoids
> spawning unnecessary processes (every ExecStartPre=/usr/bin/mkdir is a
> separate process)

I think the current way of doing this (letting tmpfiles or the daemon
itself handle it) is for the best, for the reasons you mention. Also
because it means we only have one tool to create folders during early
boot.

> Zbyszek is arguing, that splitting the configuration over two files, a
> tmpfile and  a service file, complicates things for the administrator,
> as things are no longer in a single place.

Hm, that is a fair point, but we also have the dual argument: if we
add a new place to configure runtime dirs without removing the old
(which I suppose we can't), the admin will anyway have to look in both
places to figure out what is going on...

> He also argues, that tmpfiles are active, independently of the
> service, which needs them. Which can lead to unused runtime
> directories.

I suppose the concern here is speed? If it can be shown that there is
a real speed advantage of not creating unneeded directories I guess
that's something worth discussing (I must admit that would surprise me
though).

-t