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.

Thanks for reading, and any guidance

bob prohaska
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Re: When to reboot after upgrade
By: bob prohaska to All on Mon Jun 28 2021 06:06 pm

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.

Thanks for reading, and any guidance

bob prohaska

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).



--
gopher://gopher.richardfalken.com/1/richardfalken
--- SBBSecho 3.14-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

On Mon, 28 Jun 2021 14:10:38 +1200, Richard Falken wrote:

Is there a way to determine if an impending upgrade will need a
reboot to place the changes in effect?

There is no automated way to my knowledge. At least in the wild.

Well …

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.

… that's what the needrestart package does :)


gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Bruce Springsteen: Atlantic City
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Mon, 28 Jun 2021 18:06:14 +0000, bob prohaska wrote:

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.

What Richard said,

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.


--
Martin | martin at
Gregorie | gregorie dot org
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska <bp@www.zefox.net> wrote:

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.

On Ubuntu you can run:

/etc/update-motd.d/98-reboot-required

which simply runs
/usr/lib/update-notifier/update-motd-reboot-required
if it exists.

I don't know if those translate across to Raspbian / RPi OS at all.

Theo
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)