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

[Sébastien Luttringer]

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.

Of course we want to push it upstream, like I've done with sslh, and
now people add improvments upstream.

> 2) Don't do anything Arch-specific, if possible. This will maximize
> our chances of not having to change behavior in the future once the
> service file is provided by upstream. In particular avoid
> EnvironmentFile= especially if it points to the Arch-specific
> /etc/conf.d/*.
>
> Not using an EnvironmentFile= is ok if:
I agree. I will gradually fix my packages.

> 3) If your service requires the network to be configured before it
> starts use After=network.target. Do not use
> Wants/Requires=network.target.
I agree.

> 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.

Advantage to avoid forking can be read here [1] and in many others
places. In short:
- Disable forking may save each process to fork, setsid, wirte
pidfiles, close stdin/stdout/stderr.
- Save systemd logic to find main pid.

At first sight there is only pro but some peoples suggest to use
forking for daemons which support foreground mode.
The reason seems to be : systemd consider a unit started once launched
when type=simple, whereas it consider a unit started when program exit
when type=fork.

This can be useful *IF* daemon proceed in a specific order. In other
words, it starts all it has to do and dameonize (double fork, etc)
after.
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.
An example is fcron[3] (We discuss of this with Dave on IRC last time).

So I think use Type=Forking is not the better recommendation. I would
says : Try to use all other method before Type=Forking.

> 5) Our rc scripts do not support dependencies, but with systemd we
> should add them where necessary. The most typical case is that A
> requires the service B to be running before A is started. In that case
> add Requires=B and After=B to A. If the dependency is optional then
> add Wants=B and After=B instead. Dependencies are typically placed on
> services and not on targets (see 3).
>
I agree too.

[1] http://0pointer.de/blog/projects/systemd.html
[2] It's a feeling not based on statistics.
[3] https://bugs.archlinux.org/task/31248

--
Sébastien "Seblu" Luttringer
www.seblu.net