Le jeudi 12 septembre 2013 à 12:50 +0200, Kay Sievers a écrit : > On Thu, Sep 12, 2013 at 8:57 AM, Frederic Crozat <fcro...@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 <fcro...@suse.com> SUSE _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel