[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Survey answers part 3: systemd is not portable and what this means for our ports



On Mon, Jul 15, 2013 at 03:38:57PM +0200, Helmut Grohne wrote:
> 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
Hi,

in Type=forking, forking is used to notify the init system that the
service is ready to serve requests. In Type=simple, it is assumed that
the service is ready immediately. But both Type=simple and Type=forking
services can do further forking at will. So tracking processes is still
needed — to reliably shut down the service, killing the main process and
all children.

> 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.
This would only work if all those services were ready (sockets opened
and whatever other changes are visible to other processes performed)
immediately at exec. Since this is not possible, Type=simple only works
for services which do not open sockets or mount stuff or write anything
to disk for other processes to read, etc.

Zbyszek


Reply to: