-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please don't list unattended-upgrades.service as restartable #211
Comments
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. |
Maybe one could write a custom restart script in |
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: mvo5/unattended-upgrades#308 . |
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/
|
1 similar comment
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/
|
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.
The text was updated successfully, but these errors were encountered: