In article ,
 Martin Gregorie  writes:
> ... 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).

Excellent description, but one minor nit - the running kernel is
not demand paged from the kernel image on disk and doesn't hold
the disk kernel image file open, so deleting that happens instantly.
The system only uses the kernel image file during booting when it
copies it into memory.

For programs and libraries, sections of these are paged in when they
are first used (demand paged), and the program keeps the disk file open
(or rather "mapped") while it is running so further sections can be paged
in if needed later. It may be that some sections of a program might
never be used and thus never paged in (things like debug symbols are
typical of this, if you are not using a debugger), but possibly also
sections containing functions which were never called.

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

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

--- SoupGate-Win32 v1.05