Re: When to reboot after upgrade By: bob prohaska to All on Mon Jun 28 2021 06:06 pm
There is no automated way to my knowledge. At least in the wild.
You could in theory run a script to check if any process you are currently using is linked to a library that was recently upgraded. You'd need to restart the processes which are using libraries that got upgraded in order to make sure they start using the new ones.
In practical terms, you only need to reboot for kernel upgrades, libc upgrades, and upgrades for critical security fixes (ie. if openssl is patched for some very nasty security bug, it is in your best interest to reboot the machine after upgrading to ensure the fix becomes applied systemwide, instead of locating and restarting every process that uses the library).
Is there a way to determine if an impending upgrade will need a reboot to place the changes in effect? I tend to check for upgrades at random, but often don't want to quit what I'm doing and reboot unless it's essential.
It's pretty obvious if the kernel is new, but not so obvious if things that look like modules or libraries are changing. Using apt list --upgradable gives a nice list of what's changing, but no explict hint about rebooting. Even after the upgrade is complete, there's no "reboot required" or even recommended hint.
But, as I'm more than a little paranoid about losing data and have used some operating systems that were equally paranoid (think of an OS that automatically backs up all files created or deleted since last backup and it can make backups onto 1 -3 magnetic tapes in parallel every [configurable] number of hours - yes this WAS a long time ago and the tapes were 1/2" tape on 10" reels). I know and have used two OSen that could do that as well as finding and retrieving any file or files from the backups.
So, my house server backs up all filestore changes to a USB-connected 2GB disk at 1 AM every night, but that's just to recover from finger trouble.
I also do a weekly combined backup+update every week to a set of 1GB USB- connected portable disks that are held offline in a firesafe. The only time one of these is outside the firesafe is when its being used to make the next weekly backup se
For each machine:
- 1: get oldest 1 GB USB connected backup disk out of firesafe and shut the firesafe door
- 2: use rsync to back up all changes since last backup to the USB disk I use the same disk to back up all my computers: even so its only 35% full.
- 3: update system software using dnf (Fedora systems) or apt (RPi) from the RedHat and Raspberry Pi package libraries
- 4: put backup dask back in the firesafe.
This way there I know that is always a usable set of backups that are no more than a week old in the firesafe no matter when something bad should happen. I also KNOW that the latest backup disk will restore a runnable system if or when I need to replace a dead or damaged disk on one of my computers.
Using rsync to make backups is the fastest way I know to handle a weekly backup cycle, averaging around 30 mins per system backed up.
The house server's overnight backups are done with rsnapshot, which is even faster: it takes 9 minutes to back up around 250 GB.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.