On Tue, 16.07.13 18:53, Lennart Poettering (lenn...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
