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?
No.
formatting link
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'[1] 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 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 you reboot).
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 cleanly.
[1] 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 is firefox.
--
To ban Christmas, simply give turkeys the vote.
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.
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ Fight low-contrast text in web pages! http://contrastrebellion.com
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.
I wouldn't worry about restarting init (on sane systems it's static linked anyway) it doesn't do much on a running system. I wouldn't touch systemd with a bargepole for this kind of reason.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
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 started.
Errm, I think you meant "upgrade and reboot AFTER taking your next backup".
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 runnable system.
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.
Burton Hillis (William Vaughn, American columnist)
The only current operating system I know of with general process check-pointing is DragonFlyBSD which only runs on x86_64 and so not on any version of a pi.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
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.