The subject says it all. I have always been wondering how it is possible to install a new version of a program while the old version is still running. It cannot be so easy as to just exchange the binaries - the old version would probably crash, have a lot of page faults and bad references, wouldn't it?

Greetings,
d.

When something is running, it's in memory; you can update or replace the disk file without causing a problem (a file on disk is not a process executing in RAM).

Hope this helps some.

Hmmm, I always thought that Linux does "demand paging", that is, it only loads the parts or chunks of the program into physical memory pages when they are needed (in opposition to Windows NT, e.g., which wants to have the whole binary in physical memory before it starts executing).

So when you exchange the binary (the disk file), the new parts (chunks, pages) will not fit with the ones already in memory. Where is my reasoning wrong here?

Greetings,
d.

So think of this -- what happens when you have a running system and install updates or patches? Works fine, right? You can compile and install a new kernel on a running box (then reboot and the new kernel is available). You can install an upgrade of, oh, glibc, say, and everything keeps working?

I stop something like Firefox, Thunderbird and other applications before installing a new version but I've never had a problem with upgrades or patches.

So, I dunno, seems to have worked for me lo these many years.

You name it: You have to reboot!

This is exactly what I doubt or what I do not understand. If libc (after 40 years or so) suddenly changes the semantics of something so fundamental as gets() or printf(), I ask myself whether there are now 2 shared libraries in memory, one for the programs already running and using the old libc, one for the ones to be newly started.

D.

I have been upgrading firefox and thunderbird while they are running with no problem at all. The running process is from the old binary. If you restart it, you get the new. That's also the case with the kernel. You need to reboot to use the new kernel, but your system keeps running fine with the old one loaded into memory. I have also upgraded glibc and the system never complained. All this on Gentoo. Once I tried upgrading glibc on Slack, and I totally screwed my system, so you need to follow the proper instructions when upgrading system libs.
Now, if there was a major change in a lib's API, such as a major change in gets() or whatever system call, all the binaries using the old one should be re-written and re-compiled to use the new one.

If you are concerned about it then you can upgrade outside of X as recommended by aptosid:

http://manual.aptosid.com/en/sys-admin-apt-en.htm

While I do not always practice this myself, it certainly seems sensible.

Yes, but the old binary is (probably) not completely in memory. That's what I cannot understand. I just can imagine a scheme such as the following:

1) There is a startup script S for Firefox, which never changes. This is what is run whenever you start Firefox.
2) An update first copies a new version A' of the real binary into some fixed location
3) On every (re-)start, S first looks into this location to see whether there is a new version A', and copies it over the old version A.
4) S starts A.

BTW, under Windows, you always have to close the program that you are upgrading. (?)


I have no explanation how this is possible.

Yes, that's clear, but another story.

Greetings,
Duplex

An important concept in Linux file systems is there actually is no system call to remove a file. What you have is the unlink() system call to remove a link to a file from a directory. The file is not actually removed from disk until the link count goes to zero and no running process still has the file open.

When you install a new version of, say, /bin/cat, the new file is first written to a temporary name, then the old file is unlinked and the temporary file renamed to /bin/cat. The reason this works is that the old file still exists on disk (with no link from any directory) as long as any running process has a reference to it. So, any currently running /bin/cat process continues to use the old data blocks, and any newly started /bin/cat will run the new version. The same thing holds for library files. When you update glibc, all the old files are unlinked and replaced by new versions, while all currently running processes continue to use the old (unlinked) glibc files. Only when the reference count goes to zero will the kernel return the data blocks used by those files to the free list.

This is why a reboot is recommended for any update of things like glibc that are used by many running processes. You will still have processes using the old version (and that old glibc will still occupy space on the disk) until every one of those processes has been restarted.

The reason Windows doesn't do this is that its file system is unable to keep an unlinked file's contents available to processes that are currently using it, and so you cannot unlink a file that is currently in use.

Incidentally, programs that open new libraries and plugins by name during execution will get the new version, and that can (and sometimes does) cause the process to crash.

1 members found this post helpful.

I also like the fact that you can simply restart a service after upgrade, such as xorg, without restarting the entire machine. The only thing you can't avoid a reboot is with running a new kernel, although kexec will cut down the reboot time.