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

[Colin Guthrie]

'Twas brillig, and Michael Biebl at 16/07/13 02:24 did gyre and gimble:
> 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)
> 
> 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.
> 
> 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.

Hmmm, I can certainly see the argument, but it would be a shame to have
multiple ways to achieve the same goal through different places too (it
makes the documentation case much more confusing).

There is also an argument that on first install, one has to call
"systemd-tmpfiles --create $BASENAME" in a %post script to ensure the
necessary dirs are created. If it was all "built in" to the service this
would be fine.

So I see a few options.

1. Bake it into systemd unit syntax and handle it internally.
2. Bake it in as a noop directive and have a generator parse it out and
then write out /run/tmpfiles.d/ snippets and let systemd-tmpfiles work
with that.
3. Keep the status quo.

I don't really like option 2 there - seems unnecessary overhead. But
then option one (which presumably would see the tmpfiles code being
libified and linked to from systemd itself) doesn't seem amazing too.

I guess I don't really have a major problem with either 1 or 3 to be
honest. I can see arguments for both.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/