Is ExecStop executed when service terminates by itself?

[Andrey Borzenkov]

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?

[Lennart Poettering]

Post by Andrey Borzenkov
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
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
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.

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

Lennart

[Frederic Crozat]

Post by Lennart Poettering

Post by Andrey Borzenkov
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
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
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.

Post by Lennart Poettering
(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..

[Kay Sievers]

Post by Frederic Crozat

Post by Lennart Poettering
(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.
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).

Hmm, you cannot rely on a header variable Fedora has used, but you can
invent your own ones? I don't understand that.

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

This should and will some day be replaced by a generator which creates
unit files at startup. All the built-in initscripts logic will go
away.

(The problem is that we do not have any iniscripts left, so we kind of
have forgotten about that and cannot really test it.)

Kay

[Frederic Crozat]

Post by Kay Sievers

Post by Frederic Crozat

Post by Lennart Poettering
(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.
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).

Hmm, you cannot rely on a header variable Fedora has used, but you can
invent your own ones? I don't understand that.

The Fedora one doesn't follow LSB rules for naming (X-...). And it isn't
even parsed when a LSB header is read: look at my patch, I had to alter
systemd code so it accepted to read PidFile when a LSB header is
detected (I initially didn't added this part but since there are some
upstream which are using it, let's keep it). Moreover, the PIDFile
header doesn't fix all possible cases (ie when a service might not
create a PIDFile). For instance, network initscript might have process
still running (dhcpcd, etc..) or none (if configured to use static IP).

Post by Kay Sievers

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

This should and will some day be replaced by a generator which creates
unit files at startup. All the built-in initscripts logic will go
away.

It will just move the issue from core systemd code to a generator but
won't fix it, unfortunately.

[Colin Guthrie]

Post by Lennart Poettering
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.
(Meh, such sysvinit script extensions are just evil shit, I wish suse
wouldn't do such nonsense...)

This patch seems quite reasonable to me TBH, and IIRC Fred did post them
to the list at the time. I almost adopted it to in my package but didn't
think we had a need for it and was saving it until someone complained :)

That said, it seems the bug report has moved on since Andrey's message
here and it seems that the custom LSB header does actually solve the
problem by controlling the RemainAfterExit stuff explicitly which is
good and perfectly justifies Fred's patch!


Ultimately I agree the extensions are evil but this is still a
transitional phase and such things take time - users simply do not
rewrite all their initscripts after upgrading.

I suspect you'll get similar reports once RHEL switches over and
(paying!) users find their custom initscripts are now broken...

Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/