3

This question is mainly aimed at shared libraries (.so files) compiled for Linux platforms. Would the new library file automatically be loaded the next time a program depending on it is launched? If not, is there a different way to do achieve this silent, self-contained library updating?

Karthik
  • 403
  • 3
  • 14
  • 1
    See some of the replies to my [question][1] [1]: http://stackoverflow.com/questions/10001013/update-shared-libraries-without-restarting-processes – Manohar Apr 06 '12 at 01:02

3 Answers3

6

Many Unix-based OS have filesystems allowing this kind of stuff if you remove and then recreate the same file. As far as Vlad Lazarenko and I know, Windows & DOS are the only OS which can NOT do that.

As long as a file is opened, it's kept until nothing needs it. When you remove it, it's not viewable in the fs, but it's still present. It works for all kind of files.

But you will probably need root rights in order to do this on a library. And you should take care about synchronisation and dependencies between multiple libraries. You can quickly run h into a situation where liba v1.0 can work only with libb v1.0 and when you auto-update liba, it will fail.

There are at least two well-known programs which are using this technique : apt and rpm.

EDIT: There's really no problem if you update your library following the remove/recreate patterns. Your old but in-use library still exists both in memory and on disk. Your OS is able to reload a part of your library on disk if necessary.

Your library is still on disk as long as all the program using it are closed. It's the case even for libc. That's why when you update your libc, you are invited to restart nearly all services using it, in order to update them to the new binary code.

And that's also the main reason why you can hot-update a linux system without restarting it for years.

Coren
  • 5,517
  • 1
  • 21
  • 34
  • 2
    It is not only Linux, it is basically OS except a broken MS-DOS aka Windows. –  Apr 05 '12 at 19:36
  • Thanks for the answer. As a follow-up question, would it cause a potential crash in the program running the old library after the file on disk has been updated? Is it possible that the OS pages out some of the library in memory and then tries to reload those pages later from disk? – Karthik Apr 05 '12 at 21:58
  • 1
    @VladLazarenko I agree with you, so I have updated my answer accordingly :). – Coren Apr 06 '12 at 07:32
  • 1
    @Karthik There's really _no_ problem with doing that. See my edit. – Coren Apr 06 '12 at 07:32
4

If on Linux, with a good Linux file system (e.g. ext3 or ext4 or btrfs), you could update a shared library (e.g. libfoo.so) within a process and program (e.g. bar) using it (e.g. dlopen-ing that libfoo.so)

You'll have preferably

  1. to rename(2) the old libfoo.so to e.g. libfoo-old.so
  2. to dlopen(3) the new version of libfoo.so
  3. to dlsym what you want inside it
  4. to perhaps dlclose(3) the old dlopen-ed handle to the old version; you can only do that if no active call frame points into the libfoo-old.so (otherwise your program will crash when returning into such call frames).
  5. to unlink(2) the libfoo-old.so if needed

(you could avoid rename and you could even unlink an active dlopen-ed library; the kernel would remove it if no further directory entry or process file descriptor points to it; I won't recommend that, e.g. to ease the debugging of potential core dumps).

A simpler, but more "leaking" alternative, is to never dlclose. In practice, a program can dlopen many dozen of thousands *.so without fear. See my old manydl.c example.

Read also about dynamic software updating.

To better understand shared libraries on Linux, read Drepper's paper How to write shared libraries

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Hmm, this requires the program to have knowledge of the update right? I want a much more low-tec solution: Library checks if there is newer version, downloads it, rewrites itself. – Karthik Apr 05 '12 at 22:00
  • It can be the library itself. But then, I don't think it can replace itself in each occurrence of running processes using that library. The replacement would be effective only for the next run of the programs. – Basile Starynkevitch Apr 06 '12 at 04:36
  • segmentation fault will occur on calling dlclose if the dynamic library is directly replaced by new version without renaming. – ZFY May 20 '18 at 16:33
1

You have received some excellent answers (especially Coreen's), so I thought I'd ask a question. Do you really WANT to do this? Unless you are bug fixing, and guaranteed to not alter function signatures...it might be a better idea to bump the version number, and deploy a new version, no?

user590028
  • 11,364
  • 3
  • 40
  • 57
  • No, i don't *want* to do this :P But it's a situation where deploying a new release through a conventional channel might take months...and the changes are guaranteed to not break contractually defined interfaces. Basically a way to save our own asses if something critical breaks, can push a hotfix. – Karthik Apr 05 '12 at 21:36