Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Mon, Jul 15, 2013 at 03:32:42PM +0300, Arto Jantunen wrote:
> In addition to that the wrapper also needs to be able to track the
> processes started by the systemd service (the admin might want to stop
> or restart services in addition to starting them), which systemd does by
> using cgroups. Either you need the systemd unit files to have additional
> info (how to make the daemon produce a pid file, or force it to never
> fork, or what have you), or you need to implement reliable process
> tracking without cgroups, at which point you have ported the essential
> non-portable part of systemd.
This could use some data. Download all .service files. Grep the Type.
Count occurances. Drop those with count <= 2.
6 Type=notify
8 Type=simple
10 Type=forking
20 Type=dbus
42 Type=oneshot
For 42 services no process tracking is necessary at all, because we can
simply wait for them to complete. Most of them likely originate from
systemd itself, so this number is to be considered exagerated.
Then Type=simple means that the daemon does not fork. Again no process
tracking is needed. We can write a pid file and be happy with it. If we
work towards making more services "simple", this will benefit upstart as
well, as it maps to the absense of an "expect" stanza. Note that
Type=simple is also the default so the number of services actually using
it is likely higher.
I omitted Type=dbus so far, because it is a variant of Type=simple. Here
too, no process tracking is needed as the daemon is expected not to
fork. All we need to do now is connect to dbus and wait for the declared
busname to appear.
Indeed we are out of luck with Type=forking. In the presence of a decent
init system daemonizing is the job of the init system. It is uselessly
duplicated code. Let's rip that code out of daemons and turn them into
"simple" ones.
Type=notify is similar to Type=dbus except that the notification happens
over $NOTIFY_SOCKET instead of dbus. Again no process tracking is
needed.
>From these numbers I conclude that the issue of process tracking is a
non-issue for the majority of .service files. Solving the majority of
cases is just enough here.
> Considering that we are still ignoring all of the difficult systemd
> features (socket activation, network and fs restrictions, etc), it seems
> to me that the wrapper isn't easy at all.
By far the more severe issue is socket activation, because it removes
the need to spell out service dependencies. We cannot infer these
dependencies later on. Instead such a wrapper must implement socket
activation in order to work correctly. This is the non-trivial problem.
The most prominent example here is that services should not longer
declare After=syslog.target. All syslog implementations supported by
systemd must[1] implement socket activation. Any of the 14 occurances in
.service files shipped by Debian simply is a bug. The syslog.target unit
will vanish at some point in the future.
Helmut
[1] Since version 35, see
http://www.freedesktop.org/wiki/Software/systemd/syslog/
Reply to: