On 01/27/15 21:35, Lennart Poettering wrote: > On Tue, 27.01.15 21:32, Topi Miettinen (toiwo...@gmail.com) wrote: > >> On 01/27/15 20:48, Lennart Poettering wrote: >>> On Tue, 27.01.15 19:04, Topi Miettinen (toiwo...@gmail.com) wrote: >>> >>>> 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. >>> >>> Hmm, but that's fine, no? What would you put in tmpfiles for auditd? >> >> I'd want it to put the pid file somewhere else, like RuntimeDirectory. >> >> L /run/auditd.pid - - - - /run/auditd/auditd.pid >> >> This is probably a bad example as pid files could be deleted by the >> daemon at exit. > > I think it would be better to fix this in auditd itself and make it > use a proper dir below /run, rather than store its stuff in /run > itself...
Fully agree. -Topi > > Lennart > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
