Thank you Michael for your insights.
On Mon, Sep 21, 2020 at 10:31 PM Michael Biebl <bi...@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@.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.