1) Use the upstream service files whenever they exist. This should be a SHOULD and not a MUST. Some service files can be

On Thu, Aug 23, 2012 at 5:32 PM, Tom Gundersen wrote: 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

On 30 August 2012 23:40, Tom Gundersen wrote:

On Thu, Aug 30, 2012 at 5:07 PM, Sébastien Luttringer wrote:

...

...

1) Use the upstream service files whenever they exist. This should be a SHOULD and not a MUST. Some service files can be

On Thu, Aug 23, 2012 at 5:32 PM, Tom Gundersen wrote: 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.

What concerns me is the "overloaded by maintainer" part. For e.g., what if the maintainer disagrees with one single approach that appears to come from our distribution? Do we then have to keep our own service file "fork"? -- GPG/PGP ID: C0711BF1

On Thu, Aug 30, 2012 at 5:40 PM, Tom Gundersen wrote:

On Thu, Aug 30, 2012 at 5:07 PM, Sébastien Luttringer wrote:

...

On Thu, Aug 23, 2012 at 5:32 PM, Tom Gundersen wrote: 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. That was I think we should underline in our wiki.

It is important that systemd is able to tell when a service is started, so that other services can order themselves After= it. Sure.

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