[systemd-devel] PrivateDevices with more than basic set of devices?

Lennart Poettering lennart at poettering.net
Tue Jan 27 13:35:24 PST 2015


On Tue, 27.01.15 21:32, Topi Miettinen (toiwoton at gmail.com) wrote:

> On 01/27/15 20:48, Lennart Poettering wrote:
> > On Tue, 27.01.15 19:04, Topi Miettinen (toiwoton at 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...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list