It recently dawned on me that I've never, ever been prompted to
> reboot my Pi3 after an upgrade, even when the system tells me it's
> unpacking a new kernel over the old one.
> I suppose it might be possible slip a new kernel into memory without
> disturbing userland processes, but it does not seem easy. Mac OS X
> explicitly requires rebooting after upgrade, Windows requires rebooting
> routinely 8-), is Raspbian so much more clever?
can do that up to a point, but
(apparently) not on ARM.
Or, does it just expect me to reboot after upgrading?
for a kernel upgrade the raspberry will continue running with the
existing Kernel until it is rebooted.
for all other upgrades a reboot should not be required, although it may
be necessary to stop and restart any Daemons that are upgraded (this may
be done by the upgrade process I am not 100% certain).
"The following is not for the weak of heart or Fundamentalists."
-- Dave Barry
... a seemingly little-known fact, applicable to all Unices, Linuxes and
(IIRC) BSD derivatives, is that you can delete an open file while a
program is using it without any bad effects. The same applies to the
executable file itself.
How it works: a file consists of an inode, which holds access permissions
and ownership details, and the set of data blocks containing the file's
contents. Directory entries hold just two things: the file name and a
link to the inode. There's no reason why the same file can't be linked to
from more than one directory and under a variety of names: these are so-
called 'hard links' and can only point at inodes in the same
partition. The inode and data blocks exist as long as there is a link
pointing to it. IOW, if you run a shell script like this:
grep 'regex' mydirextory/* >mydata.txt
myprog results.txt &
grep will be run first and write data into mydata.txt. Next, 'myprog'
will be forked to run independantly of the the shell script, reading
mydata.txt and writing its output to 'results.txt. Once it has started,
the shell script continues to run, deleting the 'mydata.txt' directory
entry and exiting, leaving 'myprog' still running because its got a lot
of data to process.
At this point the directory entry for mydata.txt has been removed but
there is still a link to the inode representing the open connection from
'myprog', so it continues reading mydata.txt and writing its output to
results.txt until it get to the end of its input, at which point it
closes all files and exits.
When 'myprog' ends its run and closes its link to mydata.txt there is no
longer any link to the mydata.txt inode, so the OS erases the inode and
the data blocks are returned to the free space pool.
A consequence of this is that, if a program (or the kernel) is running
when you do a system upgrade that replaces them, the upgrade will
complete normally after installing replacements for the program and kernel
and deleting their directory entries. The system continues to run as
normal BUT IS STILL RUNNING THE OLD PROGRAM AND KERNEL. The program will
be removed as soon as it finishes so the next time it is run its
replacement will be used. However, the old kernel will continue to run
until you reboot the system (and will continue to occupy disk space until
So, if an upgrade replaces the kernel you MUST reboot immediately after
the upgrade ends if you want to run the new kernel. Similarly, the same
logic applies to long-running system programs (systemd, sshd, and all the
other daemons that start at boot time and continue to run until shutdown).
Good practise says you should reboot after any system upgrade to make
certain you're running all the latest programs and library code and, for
the mildly paranoid like myself, to check that the system will reboot
 symbolic links (symlinks) are different: these are small files with
special permissions that contain a single piece of data - the name of the
file or directory they reference. Unlike hard links, symlinks can
reference files on any partition and can also exist after the file they
pointed to has been deleted.
I think it is STRONGLY recommended to reboot when replacing other core
files like the C library that just about everything else on the system uses.
I think there are ways around this, but they are cumbersome and error
prone. Their failure will end up in a crash followed by a reboot. So
it's just best to plan for the reboot when doing the update that
modifies the kernel and / or core OS libraries.
AIUI any program that uses the core libs will run on, on the old libs
until its repoened,. so there is no need to shutdown the mnachine, just
the apps using the libs, and then there is no hurry.
The only app Ive ever seen go unstable after an upgrade unless restarted
To ban Christmas, simply give turkeys the vote.
Remember that the core C library is used by just about everything on the
system. Either directly or indirectly by using other libraries that use it.
IMHO the core C library is only one degree less important than the
kernel. But it's still exceptionally important.
This makes it trivially easy to update a running program. On the other
hand, one of the most FA'd of Qs in Windows discussion groups is how
to update a running program. Answers tend to go through horrendously
convoluted explanations, invariably involving a reboot, before generally
settling on the simplified answer: you can't. It's a total pain in the ass.
/~\ email@example.com (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
Ok, thanks to everybody for some well-written explanations. Clearly I should
have been rebooting all along and just didn't.
Maybe this is a more sensible question:
Is there a command that will save the present state of the system, reboot
and then pick up where it left off? Most network sessions will persist over
at least a brief outage, so web and ssh-sessions should survive if the
downtime doesn't last too long. At one time I encountered the notion of
"checkpointing" long running jobs which could then be restarted where they
left off after system maintenance was done, but that was 30+ years ago.
Thanks again for all your help!
In addition to the excellent advice, you should upgrade and reboot
before taking your next backup. An upgrade may break something, such as
overwriting a set-up file, which you may not find out about until you
next reboot. As long as you haven't overwritten the backup of the config
file, you can restore the previous copy.
"shutdown -r NOW" or "reboot" - run as root or via sudo.
But note that rebooting will stop all processes and close all network
sessions. There's no way round that.
Nossir. Its not the duration of the gap but killing restarting the Linux
kernel that stops programs and closes network connections. Some daemons,
such as postfix or postgres, have a 'reload' command that do the sort of
very fast shutdown and restart. These can be run without a kernel reboot,
but are specific to the service they provide.
This is why I never leave system updates to run on autopilot: I turn
automatic updating off. This way I control what's happening and do a
weekly system update this involves these steps:
1) Stop whatever you're using the machine for - this includes shutting
down the web browser and mail reader, though I usually leave my
mail server running.
2) Do a system backup. I backup onto a pair of USB drives, using them in
strict rotation so one is always offline. I use rsync for this because
it is fast, only copying new material to the backup disk and
removing files from the backup that no longer exist on the system
being backed up.
3) Do the system update using apt_get and friends on the RPi and
dnf on Fedora systems.
4) reboot the system.
Programs that do this are still around, e.g. mailservers, DNS, the NTP
server if you use it, and database servers. These generally use
configuration options to determine how often they checkpoint themselves
and/or provide a control system (like the 'reload' commands described
above) to force a checkpoint, so reloads don't mess up the data.
Others, e.g. databases like PostgreSQL or MariaDB, provide methods that
their client programs can use to split the sequence of operations they
request up into 'commitment units'. These are logical chunks of work that
the server guarantees will be processed in their entirety or, in cases of
software or hardware failure, by rolled-back as if they'd not been
Errm, I think you meant "upgrade and reboot AFTER taking your next
If this is a full backup, done with something like rsync, it pretty much
guarantees that none of your stuff will be lost if the upgrade breaks
something vital *and* that restoring the backup will leave you with a
All of the Gentoo and FreeBSD systems that I've upgraded across major
versions of the C library over the years beg to differ with you. }:-)
Seeing as how you can't always know ahead of time if a library update
will need a reboot or not, I tend to plan for a reboot to be on the safe
If it's obvious that core libraries are not being updated, i.e.
libmilter.so, I don't bother rebooting, and instead just restart the
In this machine, teh uodate deamon tells me when an update needs doing,
and I run it in background. I never exit out of anything.
Theowrst that has happened is that Firefox has crashed sometimes because
I didnt shut it down and restart it.
Nothing else has.
OTOH at one pont I got an unstable kernel upgrade that would not boot
after I restarted..I had to select a VERY old lernel and boot in
recovery mode. And uninstall several kernel versions
Rebooting has its downsides.
Admittedly this is a desktop INTEL machine not a pi...
There?s a mighty big difference between good, sound reasons and reasons
that sound good.