dh_installinit/dh_systemd_start restart-after-upgrade

[Daniel Black]

Thank you Michael for your insights.


On Mon, Sep 21, 2020 at 10:31 PM Michael Biebl <biebl at debian.org> wrote:
>
> Am 21.09.20 um 02:16 schrieb Daniel Black:
> > Hi,
> >
> > I wrote https://jira.mariadb.org/browse/MDEV-23321 from a former
> > experience as a DBA when I stopped a mariadb service, needed to
> > upgrade, and needed to do a few other things before starting the
> > service again.
> >
> > I was rather surprised when a stopped service was auto started after
> > an upgrade when it was stopped. I certainly understand the usefulness
> > in starting a server on fresh install.
>
> If you disable the service (in addition to stopping it), it should not
> be started. This has been the behaviour in Debian for as long as I can
> remember.

ack.

> > I'm wondering has this scenario been considered from a generic
> > packaging standpoint? Would I be going against policy to try to do
> > this?
> >
> > MariaDB (upstream) packages on compat 9 use:
> >
> >   dh_systemd_start --restart-after-upgrade
> >
> > note: I did fine the compat 11 notice that dh_installsystemd is the
> > new way (https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2018-September.txt)
> >
> > As I understand it, if dh_systemd_start/dh_installsystemd
> > --restart-after-upgrade doesn't consider the previous state an
> > implementation would look like:
> >
> > preinst install - would save the running states (some variant of
> > systemctl --list-units)
> >
> > (at some point later) - if there's a state recorded, only start the
> > listed service(s).
> >
> > So where could states be saved?
> >
> > Does any other package that you know of attempt to do this?
>
> I guess what you are looking for is "try-restart".
> It seems we only use that though, when used in combination with
> --no-start in dh_installsystemd:
> https://salsa.debian.org/debian/debhelper/-/blob/master/dh_installsystemd#L420

This is looking pretty good.

I like how the systemctl takes patterns rather than complete service
names for this.

I'm going to find a work around for wanting a start upon a fresh
service however that seems an easier problem.

> For a regular restart-after-upgrade, we use a "restart":
> https://salsa.debian.org/debian/debhelper/-/blob/master/dh_installsystemd#L423
>
> Maybe it would make sense to use try-restart for "restart" as well,
> dunno. We didn't use that in dh_systemd_start, as this was more
> entangled with sysvinit, which doesn't support "try-restart".

makes sense.

> > Do you know of an existing package that handles the restart of
> > multi-instance systemd services?
>
> You might have a look at openvpn. I think they have a master/dummy
> openvpn.service which the instanced services bind to (via PartOf).

The mariadb ones would be independent services so not as relevant.

If I try:

dh_installsystemd --restart-after-upgrade 'mariadb@*.service'

I'm going to get stuck on:

https://salsa.debian.org/debian/debhelper/-/blob/master/dh_installsystemd#L366-368

because the file doesn't exist and a -f doing glob expansions (which
it doesn't - in my limited testing) isn't going to catch anything more
complicated than '*'.
Is a test actually necessary or can systemctl cause the error?
If it's a check of an instance that is within the package can
unit@[...].service  -> unit at .service for this check?

https://salsa.debian.org/debian/debhelper/-/blob/master/dh_installsystemd#L370-373
is also incorrect, a glob of the multinstance with try-restart is
useful. We've replaced the binaries
for the multi instances so restarting those ones seems sane.