[systemd-devel] runtime directories for services vs. tmpfiles
lennart at poettering.net
Tue Jul 16 11:26:23 PDT 2013
On Tue, 16.07.13 18:53, Lennart Poettering (lennart at poettering.net) wrote:
> > > I can do a mass update to all our packages anyway so the slight change
> > > in syntax isn't a problem.
> > Hm, can we take a step back for a moment? It seems that the rpm macros
> > are a fairly complicated solution, and they also don't carry over into
> > debian or arch. User mode sessions also will not work with rpm macros.
> Well, it's easy to come up with similar macros for debhelper or arch...
> User session don't really need this, as there as user daemons usually
> create the dirs they need on their own and there are no privileges
> involved which might forbid this.
> I have commite the RPM macro fro now, since either way we will need it
> for the packages where the dirs need to exist all the time.
I discussed this a bit more with Kay on the phone. Here's what we'd propose:
I'd be very conservative regarding adding full tmpfiles support into
unit files directly. Instead, I'd suggest adding two very minimal, very
specific new unit file settings:
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.
We'd even allow multiple runtime directories to be specified.
I want this to be specific to the purpose of running daemons so I would
even go es far as generating a parse error if the specified directory is
not within /run. We wouldn't do any of the fancier things that tmpfiles
does, because we want people to use tmpfiles for that. For example, if
automatic clean-up needs to take place this information needs to be in
tmpfiles, not in a service unit.
We would hook this up with the same logic that currently handles
PrivateTmp= and remove the the runtime directory when the service goes
With this in place we could probably cover 60% of the current users of
tmpfiles or so.
Putting this all together we'd recommend:
a) in the best case make your daemon create all runtime dirs as
b) if that's not possible (for example, due to rpivs), then use
c) If that's not enough (for example, because you need your dirs around
even if the daemon is not running) , then drop in a tmpfiles snippet
instead, and hook it in via the new RPM macro (or counterparts for
non-RPM distributions) so that it is executed at package
More specific to Fedora, there's still the question whether these dirs
in /run should be tracked by RPM or not. For this I think I am leaning towards:
d) List the runtime dirs you have in the RPM spec file, but %ghost
them. This is nice so that the directory can be easily traced back to
the package that created them.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel