Re: Shared library problem

From: Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Date: Wed Feb 23 2000 - 15:49:16 EST


Mark Stanford <mark@orville.yi.org>:
>Lately I've been doing some work with some shared libraries, and I noticed
>what seems to me to be a bit of an inconsistency. When programs are
>running that are using a shared library, and that library is deleted, the
>programs continue running without a hitch (I assume that some copy of the
>library is made into memory). However, when I replace the library with
>another version of that library (a basically different file) without
>deleting the original first, the programs running that use the library
>die. This indicates to me that in general shared libraries are accessed
>from disk, but when they are deleted they are cached in RAM. It seems to
>me that if they are overwritten they should also be cached in RAM in the
>same way, for consistency's sake--and the result of not doing this is
>clear from my experience.

I don't think so, and it's partially true.

When the file is deleted, it is removed from the directory. The file blocks
are not yet deallocated because a running process still has it open, so the
link count isn't zero yet. This allows the processes to continue to use
the library.

When you over write the files, the process page mapping are still valid, but
the data underneath is suddently replaced. On the next page fault to the
library, that page (as mapped by the original library) is loaded and started.
This causes (usually) a fault since the alignment of instructions/constant data
etc. are not valid - causing a nearly immediate abort.

The problems with replacing shared libraries are:

1. deletion is not good: the file reference to the library is removed and
   may be needed by the next process started.
2. over write is very bad: current processes will abort immediately

The best way to update active shared libraries:

1. load the new libraries - usually they will have a new version number
2. add the libraries to the cache list - ld.so.conf - if necessary.
3. re-run ld.so to rebuild the cache to include the new files
4. rename the old files. Do not delete since active processes may
   be using them - unless you are in the process of rebooting.

Sometimes there are symbolic links that have to be set -
   libc.so -> /lib/libc.so.5sv4/lib/libc.so.1
for instance. Changing versions to /lib/libc.so.5sv4/lib/libc.so.2
then requires changing the symbolic link libc.so.

I have found that the best way to do this is to boot an install system
and do the delete/rename steps there. When the system reboots it will
run ld.so using the updated (if necessary) ld.so.conf file.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:34 EST