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

[Lennart Poettering]

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:

RuntimeDirectory=
RuntimeDirectoyMode=

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
down.

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
   necessary

b) if that's not possible (for example, due to rpivs), then use
   RuntimeDirectory= instead.

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
   installation time 

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.

Opinions? Suggestions?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.