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

Frederic Crozat fcrozat at suse.com
Thu Sep 12 04:01:38 PDT 2013


Le jeudi 12 septembre 2013 à 12:50 +0200, Kay Sievers a écrit :
> On Thu, Sep 12, 2013 at 8:57 AM, Frederic Crozat <fcrozat at suse.com> wrote:
> > Le jeudi 12 septembre 2013 à 01:22 +0200, Lennart Poettering a écrit :
> 
> >> (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).
> 
> 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).

> > 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.


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



More information about the systemd-devel mailing list