On Tue, 10 Jul 2018 12:02:06 +0000, Alister wrote:

> On Mon, 09 Jul 2018 04:08:03 +0000, bob prohaska wrote:
>
>> 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?
>>
>> Or, does it just expect me to reboot after upgrading?
>>
>> Thanks for reading,
>>
>> bob prohaska
>
> for a kernel upgrade the raspberry will continue running with the
> existing Kernel until it is rebooted.
>
... 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:

#!/bin/bash
grep 'regex' mydirextory/* >mydata.txt
myprog results.txt &
rm mydata.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
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.


--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05