[systemd-devel] binding tmpfiles.d to unit startup

[Colin Walters]

Hi,

So for OSTree I am trying to move to a model where services populate 
the contents of /var on *start*.  See previous discussion here:

https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg07859.html

The really great part about this is that one is then able to totally 
reset OS state at any time by simply just doing a shutdown of services, 
then "rm -rf /var/*", then  reboot.  (You can also reset /etc, that's a 
separate discussion)

Now while patching the service code itself got me pretty far, 
ultimately there are a lot of RPMs and such out there...so what I ended 
up doing for rpm-ostree was to generate tmpfiles.d snippets from the 
/var content:

https://github.com/cgwalters/rpm-ostree/commit/f8ddf38aa2dce207399d5e485842168eb2540e5f

Basically we end up with a gigantic 
/usr/lib/tmpfiles.d/rpm-ostree-autovar.conf that has stuff like:

d /var/spool/mail 0775 0 12 - -
d /var/lib/dnsmasq 0755 0 0 - -
...

The problem with this is it all happens on boot, and it doesn't really 
scale.  I want the RPMs (and packages in general) to do this by default.

So what's the problem with patching the world to do mkdir() on bootup?

1) Lots of work
2) Loss of association between package data and directory.  While this 
is
    pretty minor, it *is* useful to be able to do rpm -qf /var/kerberos
    and see that it comes from the "krb5-libs" package.
3) SELinux labeling - any service that creates a directory like this 
will
    have to be sure it labels it correctly.  While the latest SELinux 
does have
    support for doing this automatically, it'd still be better if it was
    done at a more trusted level.

What I really want is an easy way to bind tmpfiles.d snippets to unit 
startup.
Something like:

StateDirectory=/var/kerberos 0755 0 0

(Why not full tmpfiles.d syntax?  Well I can't think of a good reason 
to make
 a *file* on startup.  There are packages that ship plain files in /var 
but
 I'd say they're broken.)

With this, it's easy to do without patching the service.  It retains the
association (if a bit indirect) between the service and its state 
directory,
because you can query ownership of the .service file.  And systemd 
ensures
SELinux labeling happens correctly.

Thoughts?  Should be a pretty easy patch.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140301/55a00487/attachment-0001.html>