Nixos-needsreboot: Determine if you need to reboot your NixOS machine

Hello everyone!

You might have encountered a situation where on a particular day, you might not know if you actually need to reboot or not. You might want to reboot if a newer generation has a newer version of Linux/Systemd. It is currently limited only to Linux and Systemd since I think those are the only two pieces of software critical enough worth rebooting :wink:.

This is a hacked together program that checks the versions (not binaries) of current and whatever the newest generation is and creates a file called /var/run/reboot-required (superuser privileges required, of course) if you do need to reboot.

A handy trick I employ is to check for this file from my bashrc, that way, whenever the prompt updates, I am reminded of updating at the earliest.

ā€œDoesnā€™t this already exist with system.autoUpgrade.allowReboot?ā€

Yes and no.

If I understand the system.autoUpgrade.allowReboot script correctly, it determines that based on path mismatch. Sometimes, thatā€™s not the case. Maybe this is just me but I have sometimes noticed duplicate kernel paths in /nix/store with no real difference (that I could find). Like the following:

$ nvd diff $(readlink /nix/var/nix/profiles/system/kernel) $(readlink /run/booted-system/kernel) 2>&1 | tee nvddiff
<<< /nix/store/m2ilvardlmn0gw9nlbd6r65pn6swilg4-linux-6.7.6/Image
>>> /nix/store/asazm97mz1zzi1cyw2x9cgdy35dgzcw6-linux-6.7.6/Image
No version or selection state changes.
Closure size: 1 -> 1 (1 paths added, 1 paths removed, delta +0, disk usage +0B).

In this case, you donā€™t really need to reboot. The versions are same, only difference is in the kernel image itself, not even the DTBs and modules.

An advantage of this program over that script is that all it does is read, and then only if you need to upgrade, create an empty file called /var/run/reboot-required. It doesnā€™t actually reboot. This is perfect for when you want to be ā€œnotifiedā€ instead of reboot at night after the auto-upgrade.

For several months, Iā€™ve been the sole consumer but thought of uploading it to GitHub today and might as well do it properly, so here you go.

Happy to accept any issues/[critical] feedback/PRs! :)

20 Likes

Would honestly be cool to have this just print a message after nixos-rebuild switch upstream.

I also wonder if a more generic implementation is possible by inspecting systemd.service.restartIfChanged.

4 Likes

I have done just that @TLATER :+1:

Hereā€™s the commit that added it:

Thank you, @thefossguy for this little tool :bowing_man:

6 Likes

I too would love to have it in upstream and have everyone take benefit of this. However, Iā€™m not sure if my approach would get accepted. Worth a try? Should I send a PR to nixpkgs for including this?

I believe thatā€™s for reloading a service after a nixos-rebuild switch. My intention with nixos-needsreboot is to check if I need to reboot, as I rebuild with nixos-rebuild boot and almost never switch (because OCD).

1 Like

Maybe! I donā€™t see any harm doing so, at least, nixos-rebuild isnā€™t exactly high-tech or particularly challenging from an architectural perspective, so little additions like this probably arenā€™t too controversial.

Iā€™d expect some discussion around the exact details of the feature to arise though, itā€™s quite possible we would need configurability and an exact definition of what it means for you to ā€œneedā€ a reboot.

I donā€™t quite get this, doesnā€™t that mean you always need to reboot to get any changes, so the script is effectively just telling you whether the kernel or systemd will update? Wouldnā€™t it be more efficient to build those two and check if there will be differences and not even nixos-rebuild boot at all? Hell, you could just keep track of their release cycles.

Incidentally, this is getting into that topic of defining ā€œneedā€.

Personally, most of the value of this tool for me would be from finding out if there is stale code from before the upgrade still running after a switch. That includes the kernel and systemd of course, but other pretty critical services might not restart until a reboot either (e.g. nginx, sshd, etc.).

While itā€™s perfectly reasonable for those things not to restart to preserve functionality, itā€™s kind of catastrophic if the entire point was to update sshd because there was some high profile vulnerability (heartbleedā€¦) or such.

Not all updates include changes to services that canā€™t restart, so itā€™s nice to know when I donā€™t need to reboot a server (or a desktop computer for that matter) to get full functionality from the update.

2 Likes

Oh, okay! I was a bit hesitant in this approach since this is a compiled program and maybe something scripted or in Python would have been better for faster iteration.

What I meant is, ā€œHmm, is there anything critical in the newer generation that I need to update right now? Or is it something ā€œminorā€ which can wait after Iā€™m done working for the day?ā€

I usually never switch but thatā€™s something I can see being helpful. Iā€™ll look into checking for critical, internet facing services.

Thank you for the feedback, Iā€™ll see what I can come up with!

1 Like

In my switch-to-configuration wrapper, GitHub - viperML/nh: Yet another nix cli helper I use nvd for every switch/boot command and it is quite nice to have. Perhaps I could also integrate your needs-reboot tool

1 Like