restore reboot notification so that users are notified after unattended-upgrades

[Nick Rosbrook]

[Impact]

There is not currently a user-friendly way to be notified that a reboot is required as a result of a package that was upgraded during unattended-upgrades. The reboot notification in update-notifier that was removed long ago would serve this purpose.

The main rationale for this is that we needed to enable this for a special jammy-based customer and we do not want this functionality to regress whenever a new update-notifier is released. We think that this change will benefit all Ubuntu users. It does change the behavior, but we think it's a change that is acceptable.

We're open to discussion with the SRU team about this.

[Test Plan]

1. Install update-notifier from jammy-proposed.
2. Reboot
3. Install a package, or install updates, so that /var/lib/dpkg/info is updated.
4. If needed, touch /var/run/reboot-required (this might actually happen depending on what you install/update).
5. Wait 3 hours for the reboot notification to appear.
6. Click on the notification icon to show the option to reboot, and click on that.

[Where problems could occur]

Bringing back old code may reveal bugs in the old code that would have been found if it was maintained all this time. Besides that, if we saw regressions introduced by this it would likely be related to the monitoring of other files.

[Other information]

We are mainly interested in SRU'ing to Jammy because that's where the use case exists, but we can keep Lunar up-to-date as well.

[Launchpad Janitor (janitor)]

This bug was fixed in the package update-notifier - 3.192.65

---------------
update-notifier (3.192.65) mantic; urgency=medium

  [ Nick Rosbrook ]
  * reboot: restore reboot required notification (LP: #1998947)
  * debian/update-notifier.install: ship reboot-dialog.ui
  * reboot: wait 3 hours since last /var/lib/dpkg/info update

  [ Michael Vogt ]
  * reboot: also check for a running unattended-upgrades

 -- Nick Rosbrook <email address hidden> Wed, 05 Jul 2023 11:04:50 -0400

[Łukasz Zemczak (sil2100)]

Updated the Impact slightly. I'd like to get this uploaded to Lunar and Jammy to start the discussion with the SRU team. If the SRU team thinks the risk is too high, I'm fine with us investigating other options.

[Robie Basak (racb)]

There seems to be quite a bit of iteration in this area in the stable releases at the moment - see for example bug 1747499 and the subsequent regression report bug 2017401.

So how would this proposed change interact with livepatch?

In principle I think it's OK to SRU this type of thing, but I'd prefer to see a broad specification document that describes how we intend all these different components to interact before considering further individual SRUs.

[Steve Langasek (vorlon)]

With regards to livepatch, the answer is that livepatch prevents /run/reboot-required from being written to when kernel .debs are upgraded; this just restores update-notifier providing a graphical notification that matches what's done in /etc/motd.

[Nick Rosbrook (enr0n)]

Robie, does Steve's response sufficiently address your concerns? Or do you think a specification is still required to move forward with this SRU?

[Robie Basak (racb)]

If I'm going to do an SRU review, I'd first like to understand the big picture of how these various components are supposed to work together, because otherwise I won't be confident that this is an appropriate change to make. I need some documentation for that.

However, if Steve or another SRU team member does already fully understand this, then I have no objection to them doing the SRU review and accepting a change.

[Robie Basak (racb)]

I noticed some behaviour recently that reminded me of this bug.

update-manager on Jammy definitely does provide a prompt to reboot after an update - I've been waiting to see and it just happened on my mostly-defaults Jammy system.

Is this the reason the code was removed from update-notifier in the past? Did unattended-upgrades by default come along later? Will a user using update-manager now get duplicate prompts? Is there a mechanism to suppress the update-manager prompt if the update-notifier prompt is being displayed, and vice versa?

I am reminded of Chesterton's fence. Why was the implementation in update-notifier removed previously?

[Julian Andres Klode (juliank)]

Yes you now get duplicate ones, but you don't get them immediately but with a delay (3 hours). So essentially if you use update-manager, the update-notifier one is more of a reminder which may still be useful because you forgot about the update-manager prompt 3 hours later already.

It was removed due to that prompt yes, but we failed to consider unattended upgrades would not be prompting users.

[Robie Basak (racb)]

What if the user doesn't close the update-manager notification? Will update-notifier then display another one, so the user has to close two when they get back to their computer? Is there a mechanism that suppresses getting more than two, for example in a further 3 hours?

[Steve Langasek (vorlon)]

awaiting information per previous comment

[Nick Rosbrook (enr0n)]

Currently, update-notifier will display the notification even if update-manager's previous notification is still open.

update-notifier will only emit the reboot notification once per qualifying package transaction. And, if the notification is already present/visible, it will not be duplicated. But, if after one reboot notification was shown and then dismissed, a subsequent package transaction that requires rebooting would result in a new notification three hours later.

[Robie Basak (racb)]

> Currently, update-notifier will display the notification even if update-manager's previous notification is still open.

This sounds like a bug to fix in Mantic then? And in that case, should we defer this SRU so that we only have to update stable releases with the final fix?

What do you think?

[Robie Basak (racb)]

> Currently, update-notifier will display the notification even if update-manager's previous notification is still open.

To expand on this, I believe that currently both unattended-upgrades and update-manager run by default on Desktop. I also think it must be fairly common for users to leave their systems for periods of time while they remain logged in, especially for example if a user sets off updates through update-manager before leaving for a break. Therefore, this proposed update will result in two reboot prompts appearing on the screen at once (one from update-notifier and one from update-manager). This seems like a significant UX regression to me that could be expected to affect a wide set of users, while providing relatively little benefit for the majority of users, so doesn't seem acceptable for SRU as-is.

Therefore I'm rejecting this upload from the queue. If after discussion you are able to persuade the SRU team otherwise, then we can accept directly from the rejected queue.

It also seems like this would be a UX regression between Lunar and Mantic given this change is already uploaded into Mantic, so I'll file a bug for that.

> The main rationale for this is that we needed to enable this for a special jammy-based customer and we do not want this functionality to regress whenever a new update-notifier is released.

I suggest using a recipe build against the git-ubuntu branch to keep a PPA updated. This technique can often work with no intervention required to maintain a patched local package, even merging in security updates - though it would still need monitoring and the occasional merge conflict resolving manually.

[Robie Basak (racb)]

I filed bug 2036213 for the Mantic issue.

[Brian Murray (brian-murray)]

Ubuntu 23.04 (Lunar Lobster) has reached end of life, so this bug will not be fixed for that specific release.