Messages in this thread | | | Date | Wed, 23 Feb 2000 14:49:16 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Shared library problem |
| |
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/
| |