Please don't list unattended-upgrades.service as restartable

[rbalint]

Unattended-upgrades service does very little that can be affected by a library update, and it's main purpose is delaying shutdown to ensure that package upgrades are not interrupted in the middle. It is listed as a service not to be restarted, but I'd like to propose blacklisting it instead to not even show up in needrestart.

[pabs3]

It is possible to restart unattended-upgrades.service.

When there is no upgrade happening, restarting it is consequence-free. When there is an upgrade happening, if restarting were to fail then the package upgrade could be interrupted. Usually restarting it won't fail though.

Restarting it means that the old libraries/binaries don't need to be kept in RAM and unlinked on disk but still using storage.

@rbalint so I think unattended-upgrades.service should be restarted automatically (when that is enabled) but only when package upgrades are not running.

When package upgrades are running, it would be reasonable to require confirmation before allowing it to be restarted. Or doing some sort of test restart before restarting it properly.

[liske]

Maybe one could write a custom restart script in /etc/needrestart/restart.d which does restart unattended-upgrades only if no upgrade is happening. Is there a reliable way to test if unattended-upgrade is doing an upgrade?

[rbalint]

There is very little point in restarting the service because it is highly unlikely that any change in any of its dependencies would change its behavior. Also @mvo5 please continue the discussion here because I'm not maintaining unattended-upgrades currently just no one made an upload since then: https://github.com/mvo5/unattended-upgrades/pull/308 .

[pabs3]

There is also no reason to not restart unattended-upgrades.service, I lean towards restarting everything even if it not restarting it could never lead to a security issue on the system, simply because not restarting it means that the system has to keep the old deleted files open and their contents available in RAM, which might be always limited or limited sometimes. On some systems that means up to 10MB of RAM could potentially be used for unattended-upgrades. On systems where there is no swap, that are close to RAM being full, this could be the difference between an OOM due to having to keep discarded files in RAM versus the system dropping caches of unattended-upgrades file data and then being able to continue and caching the files again when needed.

A restart.d script seems like a reasonable solution for now, to detect that unattended-upgrades is not currently restartable, but it does seem to conflate restarting with detecting restartability.

It would be great if systemd and individual services would have a way to detect/report restartability, but that seems unlikely, since the systemd maintainers are hostile towards live upgrades, they prefer systems to only be upgraded when no user sessions are being run.

Until the systemd maintainers change their minds, a restartable.d directory containing detection scripts that needrestart would run to determine if a service can be restarted or not seems a better option.

I'm not sure how to do the detection for unattended-upgrades yet, but I'll investigate that next time my unattended-upgrades job runs.

The other problem is that if a service is not restartable at the time needrestart is run, it should still be restarted, just as soon as it becomes restartable. Perhaps needrestart could add a daemon that waits until processes needing a restart are known to be restartable and then restarts them automatically according to the system restart config. This would mean if you upgrade something once, you don't have to manually run needrestart later in order to restart the process needing restart, because the daemon would auto-restart that for you. The daemon would not be run at boot, only when needrestart wants it available and it would exit with success when its job is done.

If user session auto-restart gets implemented, this daemon would also need to be run in user sessions too, since some things like pulseaudio are restartable when there are no audio streams running, but restarting them breaks audio streams that are running.

-- bye, pabs

https://bonedaddy.net/pabs3/

[pabs3]

There is also no reason to not restart unattended-upgrades.service, I lean towards restarting everything even if it not restarting it could never lead to a security issue on the system, simply because not restarting it means that the system has to keep the old deleted files open and their contents available in RAM, which might be always limited or limited sometimes. On some systems that means up to 10MB of RAM could potentially be used for unattended-upgrades. On systems where there is no swap, that are close to RAM being full, this could be the difference between an OOM due to having to keep discarded files in RAM versus the system dropping caches of unattended-upgrades file data and then being able to continue and caching the files again when needed.

A restart.d script seems like a reasonable solution for now, to detect that unattended-upgrades is not currently restartable, but it does seem to conflate restarting with detecting restartability.

It would be great if systemd and individual services would have a way to detect/report restartability, but that seems unlikely, since the systemd maintainers are hostile towards live upgrades, they prefer systems to only be upgraded when no user sessions are being run.

Until the systemd maintainers change their minds, a restartable.d directory containing detection scripts that needrestart would run to determine if a service can be restarted or not seems a better option.

I'm not sure how to do the detection for unattended-upgrades yet, but I'll investigate that next time my unattended-upgrades job runs.

The other problem is that if a service is not restartable at the time needrestart is run, it should still be restarted, just as soon as it becomes restartable. Perhaps needrestart could add a daemon that waits until processes needing a restart are known to be restartable and then restarts them automatically according to the system restart config. This would mean if you upgrade something once, you don't have to manually run needrestart later in order to restart the process needing restart, because the daemon would auto-restart that for you. The daemon would not be run at boot, only when needrestart wants it available and it would exit with success when its job is done.

If user session auto-restart gets implemented, this daemon would also need to be run in user sessions too, since some things like pulseaudio are restartable when there are no audio streams running, but restarting them breaks audio streams that are running.

-- bye, pabs

https://bonedaddy.net/pabs3/