Say I am running a software, and then I run package manager to upgrade the software, I notice that Linux does not bring down the running process for package upgrade - it is still running fine. How does Linux do this?


The reason is Unix does not lock an executable file while it is executed or even if it does like Linux, this lock applies to the inode, not the file name. That means a process keeping it open is accessing the same (old) data even after the file has been deleted (unlinked actually) and replaced by a new one with the same name which is essentially what a package update does.

That is one of the main differences between Unix and Windows. The latter cannot update a file being locked as it is missing a layer between file names and inodes making a major hassle to update or even install some packages as it usually requires a full reboot.

  • 10
    To clarify, under Linux you can't modify an executable file while it's running. But you can unlink the file and replace it with a new file of the same name. – cjm Apr 30 '13 at 6:11
  • Under Linux, you might modify an executable file while it is running. The result would likely be unpredictable though unless you really know what you are doing. Added the "same name" point which wasn't explicitly stated. – jlliagre Apr 30 '13 at 6:41
  • 4
    @jlliagre Unless I'm misunderstanding, you can't as far as I'm aware: sprunge.us/egiR – Chris Down Apr 30 '13 at 6:44
  • 2
    One neat thing about NFTS though - if you perform a rename from the command line or another program, then you can place a file of the same name back there, and it will not affect programs that have the original file open. (the rename command in explorer doesn't work for this) – Steffan Donal Apr 30 '13 at 8:52
  • 1
    @cjm You are correct about the "file text busy" protection under Linux, answer updated. There is no such restriction under Solaris which with I'm more familiar with. You can still modify shared libraries with both OSes though. – jlliagre Apr 30 '13 at 14:39

Executables are generally opened once, attached to a file descriptor, and do not have a file descriptor to their binary reopened during a single period of execution. For example, if you execute bash, exec() generally only creates a file descriptor for the inode pointed to by /bin/bash once -- on invocation.

This often means that for simple binaries that do not attempt to re-read themselves during execution (by using the path by which they were invoked), the content that is cached stays valid as a dangling inode. This means that there is essentially a replica of the previous version of the executable.

In more complex cases, this can cause problems. For example, a config file may be upgraded and subsequently re-read, or the program may re-exec itself via the path it was executed from. There can also be problems if programs are interconnected, and one is executed before the upgrade, and one after (possibly by the first program). This is also true for some libraries.

For simple use cases, though, it is safe to upgrade without restarting the process.

  • 1
    The other danger, even in simple cases, is that because the running application is using a cached copy of the binary, that until you manually restart the application it's still running the old version of the code. While this shouldn't matter most of the time; if the upgrade included security fixes, despite the patch being installed your system is still vulnerable because the old version is still running. – Dan Neely Apr 30 '13 at 12:41
  • 1
    I'm afraid your first paragraph is inaccurate. Unix/Linux kernels don't load executable programs at once but memory map them. That means only pages actually used eventually make it to the RAM. This is the whole point of the "Text file busy" protection under Linux. There is no guarantee some part of an executable won't be read long after it has been launched. Moreover some pages will never be loaded for large enough programs and this is even more true for dynamically loaded libraries. For example bash binary is around 200 4K pages, not sure they are all used in an average session. – jlliagre Apr 30 '13 at 15:09
  • @jlliagre I was talking about ialloc()ing to a kernel struct on read, not the memory mapping of the pages themselves. Am I not right in thinking that on modern ext* filesystems, the inode is eventually consistent in-kernel (and inside the VM subsystem)? – Chris Down Apr 30 '13 at 16:27
  • There is no guarantee parts of the executable content won't be read a long time after it is run, and there is no guarantee either that the same pages won't be read again after a while during the execution time. – jlliagre May 1 '13 at 14:55
  • @jlliagre Right, but that's not what I meant. Perhaps I minced my words a bit in my answer, I'll try to make what I meant clearer. – Chris Down May 1 '13 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.