[arch-dev-public] [RFC] systemd service files policy

Tom Gundersen teg at jklm.no
Thu Aug 30 11:40:13 EDT 2012

On Thu, Aug 30, 2012 at 5:07 PM, Sébastien Luttringer <seblu at seblu.net> wrote:
> On Thu, Aug 23, 2012 at 5:32 PM, Tom Gundersen <teg at jklm.no> wrote:
>> 1) Use the upstream service files whenever they exist.
> This should be a SHOULD and not a MUST. Some service files can be
> poorly implemented or some deps are missing (e.g. your point 5) and be
> overloaded by maintainer.

Makes sense. Like with any other part of the packages, we might need
to patch things until they are fixed upstream.

>> 4) Use Type=forking, unless you know it is not necessary. Most daemons
>> use double-forking to signal that they are ready, so to minimize the
>> chance of problems it is probably safest to use this mode. To make
>> sure that systemd is able to figure out which process is the main
>> process, it is best to tell the daemon to write a pidfile and point
>> systemd to it using PIDFile=. (If the daemon in question is dbus or
>> socket activated, that's a different matter, but I guess that is only
>> the case for the minority of daemons).
> I think we should _not_ use Type=Forking, except when it's the only choice.
> Systemd prefer not use forking type and it would be better to follow this.

I agree that using anything else than Type=forking is preferable when
possible, but correctness must come first. It is important that
systemd is able to tell when a service is started, so that other
services can order themselves After= it. This is achieved in the
following ways:

Type=simple: not at all, it is assumed that this service may be
considered "started" immediately. Either because it does not provide
any communication channels for other services to connect to, or
because those channels are set up using .socket's (the latter requires
the daemon to contain specific code to deal with systemd, so is not so
common yet).

Type=notify: the daemon will send a signal to systemd when it is
ready, this requires systemd-specific code.

Type=dbus: the daemon is considered ready whenever a given dbus
interface appears on the system bus.

Type=oneshot: this is considered started when it exits (so not
applicable to long-running daemons).

Type=forking: this behaves exactly like traditional daemons: it is
considered started when the first process has double-forked and
exited, it might be necessary to use a PIDFile= so systemd knows which
of the remaining processes is the main one.

As you can tell, all the types but "forking" depends on the daemons
being implemented in a specific way, whereas Type=forking will work if
and only if the old rc scripts worked correctly. So use something else
if you know what you are doing, but as a general principle, I'd say
that Type=forking is "safe" and anything else is an optimization we
might leave for upstream to do, or get back to later once we have
finished creating all the services.

> In most situations[2] daemons are not implemented like this and
> daemonize before starting all its services. So there is only cons to
> use Type=forking.

If that is indeed the case, there is no point to using Type=forking.
However, that would be a bug which also affects our old initscripts
(and any other sysvinit-style init), so I would be surprised if it is
very common.


More information about the arch-dev-public mailing list