[systemd-devel] Is ExecStop executed when service terminates by itself?

[Frederic Crozat]

Le jeudi 12 septembre 2013 à 01:22 +0200, Lennart Poettering a écrit :
> On Fri, 26.07.13 17:44, Andrey Borzenkov (arvidjaar at gmail.com) wrote:
> 
> > The https://bugzilla.novell.com/show_bug.cgi?id=830675 describes a
> > problem where vbox initscript apparently stopped working under systemd.
> > Script is supposed to start VMs on system boot. As long as I can tell,
> > script actually does work - but when it finishes, systemd interprets it
> > as service has finished and starts ExecStop script which in this case
> > stops VMs again:
> > 
> > jul 26 18:30:08 linux-mh9j systemd[1]: Child 11556 died (code=exited, status=0/SUCCESS)
> > jul 26 18:30:08 linux-mh9j systemd[1]: Child 11556 belongs to vboxes.service
> > jul 26 18:30:08 linux-mh9j systemd[1]: vboxes.service: control process exited, code=exited status=0
> > jul 26 18:30:08 linux-mh9j systemd[1]: vboxes.service got final SIGCHLD for state start
> > jul 26 18:30:08 linux-mh9j systemd[1]: About to execute: /etc/init.d/vboxes stop
> > ...
> > jul 26 18:30:08 linux-mh9j vboxes[11580]: Shutting down Virtualbox machines: suse_12.3 (user: root)
> > ...
> > 
> > I do not see this behavior actually documented anywhere so my question
> > is - is it intentional?
> > 
> > This is openSUSE 12.3 with systemd 195.
> > 
> > P.S. note proper unit will lose very useful functionality - actual
> > status output of running VMs. Any news about ExecStatus support?
> > _______________________________________________
> > systemd-devel mailing list
> > systemd-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> The "X-Systemd-RemainAfterExit" stuff suggests that there are Suse
> patches to systemd's core involved here which play games with
> RemainAfterExit=. Please direct any questions to the Suse folks
> regarding this.

It doesn't play "game", it just allows to set/unset RemainAfterExit flag
to a initscript, which is not possible otherwise. 

> (Meh, such sysvinit script extensions are just evil shit, I wish suse
> wouldn't do such nonsense...)

Well, sometime, we don't have a choice, specially once a release is out
and we can't start adding .service on the fly.

The patches are pretty simple:
https://build.opensuse.org/package/view_file/Base:System/systemd/remain_after_exit-initscript-heuristic-and-add-new-LSB-hea.patch?expand=1
https://build.opensuse.org/package/view_file/Base:System/systemd/service-flags-sysv-service-with-detected-pid-as-RemainAfte.patch?expand=1

It is the only way I found to have some coherent state for initscripts
(systemclt status) between those which are "forking" type and those
which are "oneshot" type (and we can't rely on PIDFile: header, since it
is not a LSB header but a RH only one).

If you have a better solution which doesn't involve creating .service
file as a workaround, I'd be happy to drop those patches..

-- 
Frederic Crozat <fcrozat at suse.com>
SUSE