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.

...

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

On Thu, Aug 30, 2012 at 5:52 PM, Rashif Ray Rahman wrote:

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"?

I'd say we should treat it as we always do: follow upstream whenever possible and only patch critical bugs. -t