[Techtalk] Bug when upgrading glibc @ RH8

Mandi mandi at linuxchick.org
Fri Mar 21 13:07:08 EST 2003


(this gets kinda long...)

As Maria mentioned, this is an expected (though not always true) behavior.

I have a script that will search the /proc filesystem looking for 
processes that have had libraries deleted out from under them by updates.

(skip to the end of the message for just the script...)

Essentially, in /proc, there is a directory for every process.  Let's take 
"1/" for example, which is init, the initial process that gets started 
when the kernel is in memory...

in this (and every process's) directory are a number of subdirectories and 
files.  some of them are useful; I don't know what all of them are for - 
check the kernel docs for that, i guess.  but the directory will look like

cmdline  cpu  cwd@  environ  exe@  fd/  maps  mem  root@  stat  statm  
status

The part we're interested in, in this particular instance, is "maps".  
This is where the process stores information about the shared libraries it is 
using.

so, right now, my /proc/1/maps looks like:

08048000-0804f000 r-xp 00000000 03:01 297359     /sbin/init
0804f000-08051000 rw-p 00006000 03:01 297359     /sbin/init
08051000-08058000 rwxp 00000000 00:00 0
40000000-40014000 r-xp 00000000 03:01 15652      /lib/ld-2.2.4.so
40014000-40015000 rw-p 00013000 03:01 15652      /lib/ld-2.2.4.so
40015000-40016000 rwxp 00000000 00:00 0
40027000-40159000 r-xp 00000000 03:01 15659      /lib/libc-2.2.4.so
40159000-4015f000 rw-p 00131000 03:01 15659      /lib/libc-2.2.4.so
4015f000-40163000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0


The column I'm looking at is the last one - the list of shared libs and 
other files the process is using.  In this case, init has all the libs it 
needs and they are loaded into memory.  The files still exist on the 
filesystem that match the information loaded into memory.  

Now, let's look at a process that needs to be restarted.  This is my sshd 
process, which was affected by a zlib update Mandrake put out last week.  
I won't paste the whole maps file, as it's huge, but here are two lines of 
interest:

40036000-40043000 r-xp 00000000 03:01 15712      
/lib/libz.so.1.1.3;3e78db4b (deleted)
40043000-40045000 rw-p 0000c000 03:01 15712      
/lib/libz.so.1.1.3;3e78db4b (deleted)


See the "(deleted)"?  Those libraries no longer match what is found on the 
filesystem.  They've been upgraded out from under the running process.

in general, when you update RPMS on a Red Hat or Mandrake box, if there is 
a server program in the RPM, it will be restarted.  If the package is just 
libraries, it will NOT look for all affected programs and restart them.  
(there is talk that this could be incorporated into the RHN client, but 
I haven't heard when that might go into production).  There is some amount 
of inconvenience involved in that - you certainly wouldn't want your 
update mechanism to restart things you're not expecting to be restarted 
(like X when you're on a gui....).

Anyway, the rest of this is the code for a script I wrote to look for 
deleted libraries using the /proc filesystem.  I use 2.4 kernels, so I 
don't know (and don't care ;) ) if it works the same way under 2.2.  You 
can run it as root or a regular user, and it prints out the pid and 
process name of the affected processes.

--mandi

#!/usr/bin/perl
$list = `ls /proc`;

@directories = split("\n", $list);

foreach $dir (sort @directories) {
        next if ($dir !~ /^\d/);  # we only want the process dirs
        if( -d "/proc/$dir" ) {
		# look for deleted libraries noted two different ways
                `grep -i deleted /proc/$dir/maps | grep -v SYSV 2>&1 
>/dev/null`;
                if(! $?) {
                        #print "$dir \n";
			# use ps to find the process that is running under
			# this pid
                        $out = `ps auxwww | grep $dir | grep -v grep | awk 
'{print \$2 "\t" \$11}'`;
                        print "$out";
                }
        }
}



More information about the Techtalk mailing list