Timer Disabling on Package Update? (is: #922031)

[Michael Biebl]

Am 10.03.19 um 17:54 schrieb Michael Biebl:
> Am 10.03.19 um 17:36 schrieb Harlan Lieberman-Berg:
>> On Sun, Mar 10, 2019 at 12:29 PM Michael Biebl <biebl at debian.org> wrote:
>>> Can you provide the output of
>>> systemctl status certbot.timer
>>> journalctl -u certbot.timer
>>
>> The output of `systemctl show certbot.timer` is at
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=922031;filename=systemctl-show-certbot.timer.txt;msg=20
>> .  One of the reporters will have to follow up with the output of
>> journalctl -u certbot.timer, as I can't replicate the problem.
>>
>>> Is certbot.timer restarted as part of the package update?
>>
>> Not unless dh_installsystemd is doing it automagically, no.
> 
> I had a quick look, it's a bug in your package.
> What happens is roughly this:
> 
> 0.12 used and older compat level where
> dh_systemd_start defaults to stop in old/prerm, and start in
> new/postinst. So during the upgrade, certbot.prerm stops certbot.timer.
> 
> Your newer certbot package uses a newer compat level which defaults to
> restart after upgrade.
> If you check /var/lib/dpkg/info/certbot.postinst, you'll see a
> systemctl try-restart certbot-timer.

So, I need to clarify this a bit.
dh_systemd_start (or dh_installsystemd) is supposed to use
"systemctl restart" for --restart-after-upgrade (the default action with
compat 10 and above).
In your case, dh_systemd_start generated code which uses
"systemctl try-restart", which is an important difference.
"try-restart" is a nop if the unit is not already running, "restart"
will start the unit in such a case.

Now, dh_systemd_start is only supposed to use "try-restart" as action
when used in combination with "--no-start". You only use that for
certbot.service though and not for certbot.timer.

It seems dh_systemd_start in stable get's confused by

override_dh_systemd_start:
       dh_systemd_start --package=certbot certbot.timer
       dh_systemd_start --package=certbot --no-start certbot.service


and generates this imo faulty code.
I also checked  dh_systemd_start in buster which does the expected thing
here.

This doesn't really change anything regarding that the best fix is to
simply roll back the compat level to 9 in certbot for the stable upload.

The takeaway here is, that it helps to check the generated maintainer
scripts code, especially when you do a compat level bump.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20190311/2ef0ab36/attachment-0001.sig>