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

[Zbigniew Jędrzejewski-Szmek]

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.

I'm sure we can get them to work, but I'd like to explore the idea of
moving that into unit files first.

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

> We will always need setting up of tmpfiles during boot, as many clients
> expect certain directories to be existant in /run without any specific
> daemon running. Thus, we couldn't move this stuff into service files ---
> we could only allow both.
Yes, I'm not arguing for removing boot time tmpfiles.

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

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

> I mean, this is the general recommendation anyway: if possible just fix
> the daemon to create the dirs as it needs it. Use tmpfiles only if
> that's not feasible, maybe because the daemon never runs privileged code
> or because the dirs need to exist at boot already.
> 
> Something I'd love to see though is if we could make it easier to apply
> tmpfiles stuff automatically on package installation. More specifically,
> I'd like an RPM macro to be added that handles this, and which is
> sufficient for packagers to call for their tmpfiles. ALl in order to
> ensure that the user can invoke the services right after package
> installation without requiring a reboot.
>

Zbyszek
-- 
they are not broken. they are refucktored
			   -- alxchk