mvo5 / unattended-upgrades

Automatic installation of security upgrades on apt based systems
GNU General Public License v2.0
278 stars 78 forks source link

`Automatic-Reboot-With(out)Users` or as soon as possible #335

Open kousu opened 1 year ago

kousu commented 1 year ago

I've been using unattended-upgrades to great effect for a couple years now to keep a small lab of Debian/Ubuntu systems up to date. My users don't like losing their batch jobs when the automatic reboot happens though, so I set it to only happen once a week:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "19:00";
Unattended-Upgrade::Update-Days {4};

and in practice this really means once every two weeks, because it only really triggers when the kernel gets an update. This two week cycle has reduced the friction with my users but it still means an occasional unlucky batch job dies overnight and has to be re-run.

Today I learned about Automatic-Reboot-WithUsers (by reading the code, the debian wiki doesn't mention it). That seems like it would be ideal! It would mean batch jobs could block the shutdown. However, if I add it to my current config

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "19:00";
Unattended-Upgrade::Update-Days {4};
Unattended-Upgrade::Automatic-Reboot-WithUsers "false"; 

it goes too far in the other direction, meaning the required reboot can't happen until at least the next week.

Code Trace If I understand this correctly: https://github.com/mvo5/unattended-upgrades/blob/5f979a25fda0f399a6c426e9972ed4c2a0e15cf0/unattended-upgrade#L2107-L2109 plus this default: https://github.com/mvo5/unattended-upgrades/blob/5f979a25fda0f399a6c426e9972ed4c2a0e15cf0/unattended-upgrade#L650 plus https://github.com/mvo5/unattended-upgrades/blob/5f979a25fda0f399a6c426e9972ed4c2a0e15cf0/unattended-upgrade#L2060-L2065 Means it can't try to reboot unless it's an update day. In fact it won't try unless it gets all the way through `run()` -- any error will throw it off, jamming up the reboot cycle (probably making the system state more fragile). ---

I'm hoping I can arrange it so that if /var/run/upgrade-required exists but Unattended-Upgrade::Automatic-Reboot-WithUsers "false", then unattended-upgrades will reboot as soon as (or close to) everyone logs out. Is this possible?

I could drop the weekly schedule

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "19:00";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";

and then it run once a day, but only once a day, so it's likely it will miss its window of opportunity -- a single stray idle connection will block the reboot.

An alternate solution, though I haven't tested, is to instead set

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::InstallOnShutdown "true";

and then write a separate, more aggressive, cronjob that reimplements the Automatic-Reboot-WithUsers logic:

# /etc/cron.d/automatic-reboot
*/15 * * * *     root      [ -f /var/run/reboot-required ] && [ "$(users)" = "" ] && reboot

but I'd rather keep everything tidy inside unattended-upgrades.

Is there a canonical way to configure unattended-upgrades on multiuser systems? Thank you in advance for taking the time to read through this and any pointers you can toss back my way. :cherry_blossom:

a-detiste commented 10 months ago

I did this feature back then... your problem is interresting, I'll have a look