needrestart: bump the debconf severity to medium

[Simon Chopin]

Currently, by default needrestart is installed on Server installs and kicks in at the end of apt commands changing the state of the system (e.g. upgrades). In its default configuration, it will send a notification through debconf if the user needs to reboot (e.g. kernel upgrade, microcode update), and will use a multiselect debconf prompt to restart services selectively.

The default selection of services *not* to be restarted is based upon a configurable blacklist (see /etc/needrestart/needrestart.conf, it is fairly extensive by default), as well as a cgroup-based heuristic to differentiate services vs user sessions. From the upstream README:

> If needrestart detects systemd it will assume that libpam-systemd is used and relies on cgroup names to detect if a process belongs to a user session or a daemon

I'm assuming we're only considering scenarios where libpam-systemd is used?

The issue here is that the debconf prompts used by needrestart have a 'critical' severity, which means they'll block the process if debconf is in interactive mode. To avoid this, there are two possibilities:

1/ configure needrestart to use the stdout backend by default. This means the services will *not* be restarted (needrestart defaults to not doing anything when using a non-interactive backend)
2/ reduce the debconf severity to 'normal' or below so that its prompts don't appear by default, and the default choices are used instaed.

I'd rather have the services restarted by default, but the issue is that users would lose the reboot notifications altogether.

[Simon Chopin (schopin)]

I attached my proposed debdiff for reference, but I'm mostly looking for opinions on the matter :)

[Simon Chopin (schopin)]

Here's an example of the tail output of an upgrade touching libc6, with the patches applied:

Processing triggers for initramfs-tools (0.142ubuntu19) ...
Scanning processes...
Scanning candidates...

Restarting services...
 /etc/needrestart/restart.d/systemd-manager
 systemctl restart console-getty.service cron.service polkit.service snapd.service systemd-journald.service systemd-networkd.service systemd-resolved.service systemd-udevd.service udisks2.service
Service restarts being deferred:
 /etc/needrestart/restart.d/dbus.service
 systemctl restart systemd-logind.service
 systemctl restart unattended-upgrades.service

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.

[Steve Langasek (vorlon)]

We should absolutely NOT be overriding the debconf frontend on a per-package basis; this deprives the user of control over where these messages are sent, and also (in this case) deprives the user of the ability to interact with the debconf questions at all. If the intention is to display messages without user interaction, debconf should NOT be used at all.

Changing debconf question priority is fine, it's perfectly appropriate to make decisions about which questions should be presented to the user by default and which should only be shown to the user who wishes to micromanage.

However, it looks to me like the proposed implementation would change the priority of ALL questions to medium? I think this is a flaw in the need restart internal APIs that need addressing, the priority of a debconf is not a global property of the calling application.

[Steve Langasek (vorlon)]

>> If needrestart detects systemd it will assume that libpam-systemd is used and relies on cgroup names to detect if a process belongs to a user session or a daemon

> I'm assuming we're only considering scenarios where libpam-systemd is used?

Those are the situations today where the behavior is definitively buggy. In particular, I have witnessed needrestart asking me REPEATEDLY, on SUCCESSIVE apt commands in a container, whether or not to restart the same set of services that I declined to restart after the initial apt upgrade. Please let me know if you would like me to together a sample reproducer. But the right solution is that I should never have been prompted at all which services to restart: I'm in an apt transaction, services are supposed to be restarted as needed, and the helper tool should not bother me but default to ask which services I want to restart or not.

This says nothing about whether "restart required" notifications should use the same debconf priority (or, whether they should be debconf prompts at all).

[Steve Langasek (vorlon)]

> needrestart defaults to not doing anything
> when using a non-interactive backend)

Then that is also a bug which must be fixed. The debconf frontend is always non interactive when running under unattended-upgrades; failing to restart affected services when auto applying security updates is critically BROKEN BY DESIGN

[Simon Chopin (schopin)]

> We should absolutely NOT be overriding the debconf frontend on a per-package basis

Not exactly what I was talking about. needrestart has two UIs by default, debconf and stdout. The former is considered interactive, not the latter.

>>> If needrestart detects systemd it will assume that libpam-systemd is used and relies on cgroup names to detect if a process belongs to a user session or a daemon

>> I'm assuming we're only considering scenarios where libpam-systemd is used?

> Those are the situations today where the behavior is definitively buggy. In particular, I have witnessed needrestart asking me REPEATEDLY, on SUCCESSIVE apt commands in a container, whether or not to restart the same set of services that I declined to restart after the initial apt upgrade.

To clarify, are you complaining about the heuristics, or about the fact that it doesn't remember your choices? Because if we generate a "temporary override" to avoid the latter, it brings in another set of questions: how long do we keep it? Until the user session closes? Until next reboot? For X hours?

> But the right solution is that I should never have been prompted at all which services to restart: I'm in an apt transaction, services are supposed to be restarted as needed, and the helper tool should not bother me but default to ask which services I want to restart or not.

> This says nothing about whether "restart required" notifications should use the same debconf priority (or, whether they should be debconf prompts at all).

Agreed, it would make sense to split the reboot prompts from the service restart issues.

>> needrestart defaults to not doing anything
>> when using a non-interactive backend)

> Then that is also a bug which must be fixed. The debconf frontend is always non interactive when running under unattended-upgrades; failing to restart affected services when auto applying security updates is critically BROKEN BY DESIGN

Sorry, that's my fault, I expressed myself poorly. needrestart considers debconf as interactive regardless of the debconf frontend.

[Steve Langasek (vorlon)]

Should this bug be closed now? AIUI we no longer have debconf prompts by default.