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

[Lennart Poettering]

On Tue, 16.07.13 03:24, Michael Biebl (mbiebl at gmail.com) wrote:

> Hi,
> 
> 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 2/ over 1/.
> 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 tend to agree with this.

> 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.
> He also argues, that tmpfiles are active, independently of the
> service, which needs them. Which can lead to unused runtime
> directories.

I am not too concerned about unused runtime directories. After all this
is not something that would (or even could) grow without bounds. There
will never be more than O(n) runtime directores for n being the number
of packages you have installed (or had installed).

We will always need setting up of tmpfiles during boot, as many clients
expect certain directories to be existant in /run without any specific
daemon running. Thus, we couldn't move this stuff into service files ---
we could only allow both.

However, I am not convinced that allowing tmpfiles to be denoted in unit
files would be a good thing though, because it sounds unnecessary. It
really sounds as if the daemons which need that should rather create the
directories on their own before making use of them. This should
generally be the most robust solution. And in such a case there's no
need to denote anything about this in the unit files at all...

I mean, this is the general recommendation anyway: if possible just fix
the daemon to create the dirs as it needs it. Use tmpfiles only if
that's not feasible, maybe because the daemon never runs privileged code
or because the dirs need to exist at boot already.

Something I'd love to see though is if we could make it easier to apply
tmpfiles stuff automatically on package installation. More specifically,
I'd like an RPM macro to be added that handles this, and which is
sufficient for packagers to call for their tmpfiles. ALl in order to
ensure that the user can invoke the services right after package
installation without requiring a reboot.

> One suggestion that came up was, to specficy runtime directories in a
> declarative fashion in the .service file itself, which means it would
> be only be created if the service itself is enabled.

The way I see tmpfiles is that they don't actually do anything active,
they just reserve some space where something else then does something
active. It just sets up working areas, and doesn't actually play in
them. As such the impact, the cost of tmpfiles is minimal. It's like
installing a package and then not using it, i.e. you have stuff lying
around that is dead, but prepares everything for the time when you
actually want to run it, not more. If you want to get rid of the runtime
dirs (or the normal packaged files) you should just remove the package
in question...

I hope this makes some sense?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.