Le jeudi 12 septembre 2013 à 01:22 +0200, Lennart Poettering a écrit : > On Fri, 26.07.13 17:44, Andrey Borzenkov (arvidj...@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@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 <fcro...@suse.com> SUSE _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel