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

Michael Biebl mbiebl at gmail.com
Mon Jul 15 18:24:54 PDT 2013


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

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)

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

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.

I think this idea warrants further discussion, so I'm posting it here.


[1] http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/Week-of-Mon-20130715/000147.html

Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

More information about the systemd-devel mailing list