[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