[systemd-devel] binding tmpfiles.d to unit startup

Lennart Poettering lennart at poettering.net
Sun Mar 2 15:03:15 PST 2014


On Sat, 01.03.14 21:01, Colin Walters (walters at verbum.org) wrote:

> On Sat, Mar 1, 2014 at 2:46 PM, Colin Walters <walters at verbum.org>
> wrote:
> >
> >RuntimeDirectory=/run/mydaemon
> >PersistentStateDirectory=/var/lib/mydaemon
> >
> Btw, see also this thread:
> 
> https://lists.fedoraproject.org/pipermail/server/2014-February/000843.html
> 
> Putting these together (and how about we just go ahead and mandate
> /run and /var/lib), we could have something like:
> 
> RuntimeDirectory=yes
> 
> That would auto-instantiate /run/$SYSTEMD_UNIT_NAME.

Would $SYSTEMD_UNIT_NAME according to your suggestion map to %n or to %p
or to %i, followign systemd's specifier notation? (see systemd.unit(5)).

> Notably, this would help administrators move away from the package
> being the central naming unit and more towards systemd being the
> basis for names.
> 
> (It is confusing that one has to deal with package names, systemd
> unit names, and process names, which can all be the same, closely
> related, or wildly different)

So far we stayed out of the business of being normative on how to name
things. Which I figure is something we can get away with as long as we
focus on building an OS. I wonder though whether unit files like this
would be the right place to start enforcing naming rules for 3rd party
apps...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list