It's years I use Linux systems on a daily basis, and I never had major problems by updating a system when it was running, but I still wonder why this is possibile.

Let me make an example.

Suppose a program "A" from a certain package is running on a system. This program, at a certain point, needs to open another file ("B") from the same package. After that, program "A" closes "B" because it doesn't need it anymore. Suppose now I update the package "A" and "B" belong to. "A" is not directly affected by this operations, at least for the moment, since it is running in RAM and the update just replaced "A" on the hard disk. Suppose "B" has been replaced on the filesystem, too. Now "A" needs to read "B" again for some reason. The question is: is it possible that "A" could find an incompatible version of "B" and crash or malfunction in some other way?

Why nobody update their systems by rebooting with a live CD or some similar procedure?

  • I tend to prefer avoiding such updates, not because of the mechanics of updating (this can be done just fine), but rather because a preference to test my applications and configuration against the changes, first. Then I would have a separate now-updated system to just switch to. But aside from that, updating in userland is generally not a problem, and for small or security fixes, I'd just do it. – Skaperen Sep 8 '12 at 19:55

Updating Userland is Rarely a Problem

You can often update packages on a live system because:

  1. Shared libraries are stored in memory, not read from disk on each call, so the old versions will remain in use until the application is restarted.
  2. Open files are actually read from file-descriptors, not the file names, so the file contents remain available to the running applications even when moved/renamed/deleted until the sectors are over-written or the file descriptors are closed.
  3. Packages that require reloading or restarting are usually handled properly by the package manager if the package has been well-designed. For example, Debian will restart certain services whenever libc6 is upgraded.

Generally, unless you're updating your kernel and aren't using ksplice, then programs or services may need to be restarted to take advantage of an update. However, there's rarely a need to reboot a system to update anything in userland, although on desktops it's occasionally easier than restarting individual services.

See Also


  • But what will happen, if you need all the cache-memory? In that case the share-libraries will have to be loaded again from disk... – Nils Sep 8 '12 at 19:36
  • 3
    Actually the description of #1 was not so clear. The old library file contents remains under a separate (original) inode, even if all the names linking to it are gone, as long as some process has the file opened, or its contents mapped, the data is kept distinct (and the filesystem cannot be remounted r/o until the unlinking of the file completes). The process that mapped the original file still has memory mappings to the original contents. – Skaperen Sep 8 '12 at 19:51
  • @Nils I'm no expert, but if you run out of cache, wouldn't it be written to swap and reread from there? If that was full then some process would probably be blocked before it could take memory away from another process that is already using it. – Joe Sep 14 '12 at 23:22
  • @Joe no - swap is ram, too. Skaperen describes what happens: the file-handle is being held intact. So basically the program has an one hadle to the old (gone) library, which will not be deleted until that handle is free again - this is all on filesystem-level - not on RAM-level. – Nils Sep 15 '12 at 21:57

Yes, what you described is possible, but most of the time if the file is included with the package, it's going to be a library or other file which is read once and only once (since it doesn't change, there's no reason to read it multiple times). Also if the file is needed long term, the application will likely leave the file handle open, in which even if it does get replaced on the actual filesystem, the open file handle will keep the old version open.

In most cases, any data which is read multiple times during the life of the process is user/variable data, and this wouldn't change during a package upgrade. Plus since the data is variable, any programmer in their right mind would make sure the program can handle it changing from one read to the next.

  • The file can still be re-read as "backing store" if the mapping of it made no changes in memory (which would otherwise shift backing store to swap if available), and the in memory copy gets discarded because of other demand pressure to use memory. But this is no issue because the original file is still open or mapped. The replacement library is a new and different file which the old process has not opened. – Skaperen Sep 8 '12 at 19:59
  • 1
    @Skaperen I'm assuming you're talking about memory-mapped files. These are not issues when upgrading packages. All package managers create new files to replace the old ones instead of overwriting them. In fact this is the only way to do it as a running executable can't be modified, it can only be unlinked. – Patrick Sep 8 '12 at 23:13

Suppose "B" has been replaced on the filesystem, too. Now "A" needs to read "B" again for some reason. The question is: is it possible that "A" could find an incompatible version of "B" and crash or malfunction in some other way?

This is possible, but unlikely in most cases. If "B" is a code library, then the original version would usually not be closed. "A" would continue to use the original version of "B". If you run "A" after the update, the new version of "B" would be used. During the update, there is some risk that incompatible versions could be loaded. However, due to the way code libraries are loaded this should only be a problem if "A" need functionality not present in the versions of "B" that it loaded.

Good coding practice keeps the interface to functions the same. As a result it doesn't matter much which version is loaded, other than if there were bugs fixed in the newer version.

Configuration files are a slightly different matter, but are usually read during startup. In this case, "A" would not read "B" unless a reload of the configuration was changed. Again, it would be bad coding practice to change the format or meaning of the configuration file. An incompatible version of the configuration file should have a different name, so it wouldn't cause a problem.

Why nobody update their systems by rebooting with a live CD or some similar procedure?

Shutting down and rebooting from a different version would lead to a service outage. For servers, this is generally not desired. In any case, the package manager on the running system is aware of the software and versions it has installed. Live CDs have there own list of installed software, possibly with different versions. This makes it difficult to reliably upgrade the running system from the live CD.

Live CDs are sometimes used when a new release of the O/S is being installed. In this case, the a clean installation of the O/S is usually done. This can limit the amount of unused files from the previous version being retained. It can be more effort than upgrading the live system. However, if different root partitions are used, it can limit the risk of being stuck with an unbootable partially updated system.


There are some cases where this IS a problem:

  • JDK upgrade while a java-VM is running: I asked myselv the same question that you got - I had a running tomcat that uses java. Now after a patch-update of the JDK it still ran without problems - so it seemed.

Now the explanation is cache-memory. OK - I started a memory-hog-program to use up all available RAM - and then tomcat crashed (after I accessed the applicaton running there).

  • Kernel-Upgrade on SuSE-systems: On SuSE the old-kernel and its modules get deleted right after patch-upgrade of the kernel. If you then want to use something new, that requires a kernel-module, that was not loaded up until now, the service will fail.
  • 2
    Sounds like some piece(s) of Tomcat got restarted, or dynamic libraries were used below the Java level (e.g. dlopen() and such) which could end up with a mix of live APIs. – Skaperen Sep 8 '12 at 20:06
  • @Skaperen even when using shared libraries - if they get closed after use any program should have troubles if cache is getting sparse... – Nils Sep 8 '12 at 20:13
  • 1
    An open file descriptor has the same power to retain the data on disk as an name for the file in a directory. The original inode will not be deleted as long as there is a hard-link on disk or a open file descriptor. Cache has nothing to do with it. Now, some programs close their file descriptors when they are not using them and that can let the data go away. – dmckee --- ex-moderator kitten Sep 8 '12 at 23:53
  • @dmckee Right. We are getting nearer to the core. So what is normal for a "normal" program: open the library and keep it open, or load the library and close it afterwards? – Nils Sep 9 '12 at 20:15

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.