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

[Lennart Poettering]

On Tue, 16.07.13 18:34, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> 
> On Tue, Jul 16, 2013 at 05:08:12PM +0100, Colin Guthrie wrote:
> > 'Twas brillig, and Lennart Poettering at 16/07/13 17:01 did gyre and gimble:
> > > Anyway, does that RPM macro sound good to you?
> >
> > Sure, seems close enough :)
> >
> > 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 am not too concerned about unused runtime directories. After all this
> > is not something that would (or even could) grow without bounds. There
> > will never be more than O(n) runtime directores for n being the number
> > of packages you have installed (or had installed).
> Sure, but this n can be around a couple hundred I'd image when debian
> is fully converted and installed. For efficiency this is probably
> unmesurable, but as an admin I'd prefer not to have hundreds of empty
> dirs in /run.

On my (pretty much fully converted) Fedora I currently have 20 tmpfiles
snippets around. I doubt on an everage Debian machine this would grow
much larger. May 40 or so, but that's still not much.

> > However, I am not convinced that allowing tmpfiles to be denoted in unit
> > files would be a good thing though, because it sounds unnecessary. It
> > really sounds as if the daemons which need that should rather create the
> > directories on their own before making use of them. This should
> > generally be the most robust solution. And in such a case there's no
> > need to denote anything about this in the unit files at all...
>
> Well, we seem to be using the tmpfiles mechanism quite a lot. And
> there are good reasons for that: we get a lot of flexibility with a
> powerful syntax, and actually there's significant downsides to putting
> all this logic in daemons, e.g. support for various xattr
> mechanisms. We want to simplify daemons. Also, as you mentioned, some
> stuff runs unpriviledged.

I want daemons to be robust. So if possible I think daemons should do
these things on their own. This also has benefits for systems like selinux
where the label for files can be determined using the normal security
transitions, rather then databse checks like we currently need to do
it...

> Also, we could grow a mechanism to *remove* dirs after the daemon is
> stopped. Putting it in rpm specific mechanism removes this possibility.

I can see how this could be nice but it kinda reminds me of the
situation regarding removing UIDs from /etc/passwd after package
deinstallation, which is soemthing that is simply very hard to ever get
rid, and which is why Fedora is not doing this at all...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.