My original post:
Drew Kramer writes:
> I'd like to be able to query the system for shared library information.
> Specificly, I need to know if a particular shared library is in use by any
> processes in order to facilitate replacement of the library (i.e. with a new
> version) I've read the man pages for loader, ld, and a bunch of other stuff,
> but they all seem to be process specific. I've poked around in kdbx a bit, but
> without knowing the name of the structures I'm kinda lost. Any pointers would
> be appreciated.
>
> Another way to phrase this question might be: What is the preferred method of
> replacing shared libraries on the fly?
>
> Thanks.
>
> -drew
I got four responses, included below. I'll summarize for those that don't have
time to read the gory details. In essence, the answer is the same as for Andrej
Panjkov's <matap_at_LURE.LATROBE.EDU.AU> question (& summary) entitled: "SUMMARY:
compiling a file crashes its running executable" (see the archives...). All you
have to do is "mv" the existing shared library before putting the new one in
place. You can then delete it, or whatever. There will be a "hole" after you
"mv" the old file and before you "cp" the new one in, Spider Boardman's
<spider_at_Orb.Nashua.NH.US> solution takes care of this problem as well. Happy
"mv"ing!
-drew
-------
USMail: OTA Limited Partnership E-mail: drew_at_ox.com
1 Manhattanville Road Phone: +1 914 694 5800
Purchase, New York 10577 FAX: +1 914 694 5831
"Welcome, to the machine..."
The four responses:
Andrew Gallatin <gallatin_at_isds.Duke.EDU> said:
The best I can figure, its a multi-step process. Get lsof (not sure
where I got it from, but I'm sure you can find it) which lists what
files are open by filesystem & inode.
Then run odump -D on an executable to find out what libs it depends
on. Then run ls -li on the lib & look for the inod number. Then run
#lsof | grep <inode number>
this should tell you if a lib is held open & what process is holding
it open.
lowell_at_quarry.zk3.dec.com said:
I do not know if there is a way to determine what libraries
are currently in use. I've seen references to utilities
which list open files for a system, but I don't know if
this would include mmap'd files. The loader closes a shared
library file after it mmaps it.
I could give you a program which can be run for each process
that lists the shared libraries loaded by that process. But
you would have to iterate over every process, and by the time
your done more processes may have started up.
I do replace shared libraries and loaders on the fly. The key
is not to overwrite the existing file with the new file. This
method will always work as long as you have enough disk space
to keep old copies of the libraries you're replacing.
For example, to replace libc.so with libc.new:
su
cd /usr/shlib
/sbin/mv libc.so libc.orig; /sbin/mv libc.new libc.so
rm libc.orig (or save it if you prefer)
It is safe to delete the original libc.so after it's been
moved out of the way. The system will not delete the inode
until there are no more processes that are using it.
Obviously, with this method, there is a short time between the
two "mv" commands when there is no libc.so on the system and
shared processes loaded in that time period will fail.
-Randy
Spider Boardman <spider_at_Orb.Nashua.NH.US> said:
From the patch instructions that always come with the patches, it
would seem to be
# cp -p /tmp/new-libc.so /usr/shlib/libc.so.new
# cd /usr/shlib
# ln libc.so libc.so.old
# mv libc.so.new libc.so
# : from here on is optional
# ln libc.so libc.so.patchYYYYMMDD
# rm libc.so.old
That way, there's no overwriting involved, and you don't need to
know whether anyone is still using the library. In the case of
libc.so, that's a big win, since *somebody* IS still using it.
<bgk1142_at_bggfu2.nho.hydro.com> said:
Hello !
'lsof' (list open files) might solve your problems. Get it from
gatekeeper.dec.com.
Received on Tue Feb 14 1995 - 09:33:25 NZDT