On Tue, Jul 16, 2013 at 08:26:23PM +0200, Lennart Poettering wrote: > 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.
There are daemons which do, in order: 1) start as root 2) open some root-only resources, like network sockets 3) change to less priviledge user 4) if all OK, write PID file or some state in /run 5) do the work Those daemons can't have User= specified, because 2) would fail. And because they must start as root, systemd can't know what chown() to do on runtime dir. So what's the solution? a) declare those daemons incompatible with RuntimeDirectory* stuff - nothing changes, they continue to use separate tmpfile .conf b) fix the daemons? -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
