Bug#887904: RFR: Make dh_installinit and dh_installsystemd debhelper autoscript snippets independent in c12 (Was: Re: Bug#887904: dh_installsystemd will unmask services *after* an attempt to start them)

[Felipe Sateler]

On Wed, May 16, 2018 at 8:34 AM Niels Thykier <niels at thykier.net> wrote:

> Felipe Sateler:
> > [...]
> >
> > I think the entanglement can be removed by runtime checking of the unit.
> >
> > 1. Swap the order of installinit and installsystemd so systemd acts
> first.
>
> (Moved related argument up)
> > Step one is needed in case the compatibility symlink is created at
> > systemd-enable time (via Alias)
> >
>
> Just to confirm, we just need "d-s-h enable <service>" from
> dh_installsystemd to run before the snippet below for the same service,
> correct?
>

That's what I had in mind, yes.


> If so, then we have an alternative method for handling that besides
> re-ordering the helpers.  That would have the advantage of also working
> if people call dh_installinit and dh_installsystemd in a different order
> than we expect.
>

Well, dh helpers are already order dependent so I wouldn't loose much sleep
over it.


>
> > 2. Have the installinit snippet do:
> >
> > if [ -d /run/systemd/system ] && [ "/etc/init.d/#SCRIPT" != "$(systemctl
> > show --value --property SourcePath #SCRIPT#.service)" ] ; then
> >   # do nothing
> > else
> >   invoke-rc.d #SCRIPT# start || #ERROR_HANDLER#
> > fi
> >
> > This checking could also be moved into invoke-rc.d via some flag. What do
> > you think?
> >
>
> I think it would be best if that logic was handled by invoke-rc.d.  In
> case that logic need to be updated for some reason, then it is a lot
> easier to just update update-rc.d than thousands of maintscripts.
>

Agreed.


> Can you handle the update-rc.d side or should I file a bug against
> init-system-helpers?
>

I'd like opinions from the rest of pkg-systemd first. Michael, what do you
think?

Another thing that came to mind is that the above check won't work in a
chroot. But invoke-rc.d already denies chroot execution without
policy-rc.d, and systemd execution has no chance of working either
(systemctl rejects calls when it detects it is chrooted), so perhaps this
is enough of a corner case to be pushed into the future when someone bumps
into it.


-- 

Saludos,
Felipe Sateler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180516/1c004da4/attachment-0002.html>