On 01/26/15 23:46, Lennart Poettering wrote: >> But independently of the PrivateDevices thing, would you think >> tmpfiles.d could be extended to be usable for unit specific cases >> instead of just one global setup? I think there could be more uses, for >> example, creating directories and links inside a unit's >> RuntimeDirectory. > > I am not sure how this could work and what kind of integration you > precisely are looking for there? > > Note that tmpfiles exists mostly for two reasons: a) to deal with old > software that wasn't capable of creating its own subdirs/stuff below > its runtime directory; and b) to deal with software whose main program > was running unpriviliged all the time (for example by using User=), > and hence lacked the priviliges to set up its subdir in /run.
a) was exactly my case, auditd doesn't have a way to specify where to put the pid file yet, so it ends up in /run/auditd.pid. > > Now, to deal with case b) we nowadays have RuntimeDirectory=. And for > a) I think the long story must be to make it set up its own stuff in > /run, and I don#t see how tmpfiles could break any benefit there... > > Lennart > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
