On Wed, Oct 20, 2004 at 07:49:01PM +0100, D. D. Brierton wrote:
>
> This is a question about the correct procedure when updating any major
> component of ones underlying desktop environment, and not specifically
> glib or gtk: after the update should you log out and log back in again
> (assuming you are running the desktop environment in question at the
> time)?
>
> With desktop applications I would almost always quit the application in
> question before installing the update and then restart it afterwards. If
> X itself is updated I would certainly log out and log back in again. But
> what about things like glib or gtk or other underlying parts of ones
> desktop environment? After the update should you log out and log back in
> again, or will applications just automagically start using the new
> versions of the libraries with no intervention on my part?
This is an interesting question. I think I understand how to look at this.
Others may jump in with stuff I do not know.
A new instance of an application that dynamically links to a library
with get linked to the new library. A fork/clone of an existing
application will continue to be linked to the old already running
runtime linked shared objects.
You might be able to notice references to old and deleted files with
"lsof". Example:
In a spare window
# cat > /tmp/gone
In a second terminal window....
# lsof | grep gone
cat 1224 root 1w REG 3,3 0 11616395 /tmp/gone
# rm /tmp/gone
rm: remove regular empty file `/tmp/gone'? y
# lsof | grep gone
cat 1224 root 1w REG 3,3 0 11616395 /tmp/gone (deleted)
I need to tinker a bit more but on the surface this tells me that you
can look for old references to updated files but shared objects need
more looking. Shared libraries are slightly difficult as this
fragment of lsof on an updated FC3t3 box shows.
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
bash 3929 root mem REG 253,0 1373673 /lib/tls/libc-2.3.3.so (path inode=376098)
bash 17271 root mem REG 253,0 1506848 376098 /lib/tls/libc-2.3.3.so
For common files the old inode and data persists until the last open()
of the inode, close(es). Looking at the above 'bash' case tells me
that the initial instance of bash uses one version of the
libc-2.3.3.so library and a newer exec of bash links to the new. The
one with (path inode=...) on the end is the old one. The "(path
inode=)" clue is lsof's way of telling me that the open inode and the
associated file name no longer match. i.e. the running code is not
the code in the files system.
Of interest some rpm packages (like ssh) will attempt restart the
service in an attempt to eliminate this interaction. A "Port already
open" messages tells me that a copy of the original daemon is still
active and the code paths in the new libraries are not yet in play.
inetd, xinetd, init will do the right things quick enough for most things.
Clearly 'init' as the first mother of all process requires a reboot to
change. /sbin/init will link to /lib/libselinux.so.1,
/lib/ld-2.3.3.so and /lib/tls/libc-2.3.3.so.
So I think that this one liner can let you look an see if something
"interesting to you" still needs to be restarted or a system reboot
scheduled.
lsof | egrep "deleted|path inode" | less
Perhaps there are other tricks to this interesting topic. Almost
nothing requires a reboot but some may take a swift kick in the pants.
As far as risks go most attacks will connect to the new binary so
risks are low, but non zero. Exit operations in rpm packages will restart
most services. If you find a long running daemon/service that is not
given a swift kick bugzilla it.
--
T o m M i t c h e l l
May your cup runneth over with goodness and mercy
and may your buffers never overflow.
