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 the

[Felipe Sateler]

Hi,

On Sun, Jun 17, 2018 at 12:39 PM Niels Thykier  wrote:

> On Wed, 16 May 2018 09:50:28 -0400 Felipe Sateler 
> wrote:
> > [...]
> >
> >
> >> 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?
> >
>
> Any updates on this part?
>

I think we can take the silence as "no objections" :)

Please file a bug so this does't get forgotten. I have not been super
active lately but this seems like relatively low hanging fruit that can be
done relatively quickly.


>
> > 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
>
> All the more reason to put the check into invoke-rc.d as fixing that
> corner case will be non-trivial if deployed in generated maintscripts. :)
>

Agreed.

-- 

Saludos,
Felipe Sateler

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 the

[Niels Thykier]

On Wed, 16 May 2018 09:50:28 -0400 Felipe Sateler 
wrote:
> [...]
> 
> 
>> 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?
> 

Any updates on this part?

> 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

All the more reason to put the check into invoke-rc.d as fixing that
corner case will be non-trivial if deployed in generated maintscripts. :)

Thanks,
~Niels

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 the

[Felipe Sateler]

On Wed, May 16, 2018 at 8:34 AM Niels Thykier  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 " 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

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 the

[Niels Thykier]

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 " from
dh_installsystemd to run before the snippet below for the same service,
correct?

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.

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

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

Thanks,
~Niels

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 the

[Felipe Sateler]

On Sun, May 13, 2018 at 1:54 PM Niels Thykier  wrote:

> Control: tags -1 -patch
>
> Felipe Sateler:
> > On Sun, May 13, 2018 at 11:34 AM Niels Thykier 
> wrote:
> >
> > [...]
> >
> > There is one case where I think things go wrong (but I haven't tested): A
> > package including only an init script will not run invoke-rc.d but it
> won't
> > have a dh_installsystemd snippet either, so the service won't get started
> > on installation.
> >
> >
> >
>
> That sounds like it is true.  However, it also seems to imply that
> dh_installsystemd and dh_installinit must forever be tangled some how.
> If true, that is very much unfortunate as it makes the interaction a lot
> more complicated than it should be (case in point, this bug is caused
> exactly by these two commands being tangled).
>
> Do you see a solution for this, where dh_installsystemd and
> dh_installinit can become independent/unaware of each other?
> Alternatively, should we merge them into a single helper instead?
>

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

Step one is needed in case the compatibility symlink is created at
systemd-enable time (via Alias)
-- 

Saludos,
Felipe Sateler

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 the

[Niels Thykier]

Control: tags -1 -patch

Felipe Sateler:
> On Sun, May 13, 2018 at 11:34 AM Niels Thykier  wrote:
> 
> [...]
> 
> There is one case where I think things go wrong (but I haven't tested): A
> package including only an init script will not run invoke-rc.d but it won't
> have a dh_installsystemd snippet either, so the service won't get started
> on installation.
> 
> 
> 

That sounds like it is true.  However, it also seems to imply that
dh_installsystemd and dh_installinit must forever be tangled some how.
If true, that is very much unfortunate as it makes the interaction a lot
more complicated than it should be (case in point, this bug is caused
exactly by these two commands being tangled).

Do you see a solution for this, where dh_installsystemd and
dh_installinit can become independent/unaware of each other?
Alternatively, should we merge them into a single helper instead?

Thanks,
~Niels

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 the

[Felipe Sateler]

On Sun, May 13, 2018 at 11:34 AM Niels Thykier  wrote:

> Control: tags -1 patch
>
> On Sun, 21 Jan 2018 16:45:47 +0100 Michael Biebl  wrote:
> > [...]
> >
> > See the generated postinst script.
> >
> > The more I think about these ordering issues, the more I'm convinced
> > that for services which ship both a native service file and a systemd
> > service file, we should leave the start/stop/restart of the service to
> > dh_installsystemd/deb-systemd-invoke and only use the  invoke-rc.d call
> > on sysvinit systems.
>
> I have created a patch that ensures that dh_installsystemd's snippet are
> used for start/stop/restart iff the system is running systemd.
> Otherwise, the dh_installinit version handles start/stop/restart.
>
>  * I would welcome a review of this branch before I merge it, so we do
>not end up with another "incomplete split" like we had with compat
>11.
>

There is one case where I think things go wrong (but I haven't tested): A
package including only an init script will not run invoke-rc.d but it won't
have a dh_installsystemd snippet either, so the service won't get started
on installation.



-- 

Saludos,
Felipe Sateler

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 the

[Niels Thykier]

Control: tags -1 patch

On Sun, 21 Jan 2018 16:45:47 +0100 Michael Biebl  wrote:
> [...]
> 
> See the generated postinst script.
> 
> The more I think about these ordering issues, the more I'm convinced
> that for services which ship both a native service file and a systemd
> service file, we should leave the start/stop/restart of the service to
> dh_installsystemd/deb-systemd-invoke and only use the  invoke-rc.d call
> on sysvinit systems.

I have created a patch that ensures that dh_installsystemd's snippet are
used for start/stop/restart iff the system is running systemd.
Otherwise, the dh_installinit version handles start/stop/restart.

 * I would welcome a review of this branch before I merge it, so we do
   not end up with another "incomplete split" like we had with compat
   11.

 * Branch at:
https://salsa.debian.org/nthykier/debhelper/tree/dh_installinit-dh_installsystemd-isolation-c12

The end goal is that dh_installinit and dh_installsystemd's snippets are
completely independent and will have complete control of their own parts
without having to "synchronize" with the other tool.


Known issues:
=

 * Documentation has not been updated (e.g. changelog, manpages and
   notably the "changes in compat 12").

> 
> [...]
> 
> This would be a change of behaviour, so I'm not sure if this should be
> in compat 11 or deferred to compat 12. But afaics, the current
> dh_installsystemd in compat 11 is not actually working due to these
> ordering issues which are a result of no longer having two separate
> helpers which ran befor and after dh_installinit.
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?

I have opted for a compat 12 change; I intend to release compat 12 as
stable before buster is released.

Thanks,
~Niels