> I learned this that hard way when I tried to install a new copy
> of libc.so over the old one. Hard crash. Repeated it, same result. I
> think if a shared library is busy, any attempt to modify it should return
> ETXTBSY, right?
Oh, the joys of learning system administration on your own . . . .
If you have 'root' access then you are expected to use it wisely and
not do dumb things such as that. (I am not saying that you are dumb. I
am saying that it is a dumb mistake. It is like doing "cd / ; rm -rf
junk *" with the extra space. You do this only once. You learn. You
don't do it again.)
No. There is no checking on the library. The /lib and /usr/lib
directories should be secured so that only root may write to them. In
this fashion only the administrator account may damage the system.
Shared libraries are simply mapped into the process' address space by
the loader in the same manner as an executable is. There is no locking
on executables either.
If you need to replace a version of a library with a new copy OF THE SAME
REVISION, then do the following from the root account:
1. Copy the new file into the /lib directory UNDER A DIFFERENT NAME,
such as /lib/new_library_name. Do not attempt to use the same name or
you will destroy the existing library.
2. COPY (DO **NOT** move) the existing library to a different name in
the directory so that you can get it back if you need to do that.
3. Cross your fingers and do the following:
mv -f /lib/new_library_name /lib/libc.so.5.4.2
or whatever your name is currently. This will run the 'mv' program and
it will then remove the old library and move your new library into
place. The '-f' parameter says "Yes, do the deletion." Without it you
will get an error that the file exists.
The existing file will be removed from the directory, but the blocks
will not be returned to the free list until you stop all processes
which are using the old library. At that time, the file usage count
will go to zero and the file system will delete the old library from
the disk.
4. Run the ldconfig program.
Things are much easier if you are simply updating the library. In this
case only put the library with the revision information (the one like
libc.so.5.4.2) rather than "libc.so.5" or "libc.so") into the /lib
directory and then run ldconfig. It will do what is needed.
There is a problem with some distributions (Caldera 1.0/RedHat 2.x and
Slackware 3.0) in that they have the wrong data in the soname field
when they built the libc.so.5.0.9 library. In that case, you need to
become more inventive when you update the libraries for those systems.
Trying to expunge these bad libraries usually involves booting from
diskettes and doing the steps manually.
RedHat's 3.0.3 release is correct.
p.s.: I am so critical of this error only because I did the same thing
one day! As I said, you learn from your mistakes and hopefully don't repeat
them.
-- Al Longyear longyear@sii.com longyear@netcom.com Finger longyear@netcom.com for a public PGP key