On Sat, Jan 12, 2008 at 21:27:31 -0500, Zach wrote: > Florian wrote: [...]
> >Make sure that you have the correct version of libglib2.0-0 installed. > >On an up-to-date Lenny system "dpkg -l libglib2.0-0" should show version > >2.14.3-1. Most likely you will find that you have the current version > >installed, because aptitude should have tried to upgrade the package > >otherwise. However, if you do see an older version then we have to have > >a closer look at your apt configuration. > > I think I've discovered another problem. In the past 1-2 months I've > noticed whenever I install a new package or query the dpkg package > database it takes an inordinately long time and sends my CPU up to > 90%-100% utilization while it's working. I timed it and there's no way > it should be taking this long on my 700MHz PIII processor with very > little system load: > > netrek:~# time dpkg -l|grep libglib2 > ii libglib2-ruby 0.16.0-10 > Glib 2 bindings for the Ruby language > ii libglib2-ruby1.8 0.16.0-10 > Glib 2 bindings for the Ruby language > ii libglib2.0-0 2.14.3-1 > The GLib library of C routines > ii libglib2.0-data 2.14.3-1 > Common files for GLib library > ii libglib2.0-dev 2.14.3-1 > Development files for the GLib library That looks OK to me. > real 1m18.728s > user 0m2.344s > sys 0m0.236s > > What could be causing this bottleneck? Did my package database grow > too big? I see libglib2.0-0 as being at the correct version 2.14.3-1. The command itself seems to use only about 2.6 seconds of CPU time (user+sys) and spends the rest of the 1m19s waiting for something, most probably data transfer from the hard drive. You see the CPU at 90-100% during the whole time, so maybe DMA is not working. You can use "hdparm /dev/hda" to check this. (This command is part of package "hdparm" and has to be run as root; replace "/dev/hda" as is appropriate for your system.) However, I don't know too much about such system internals, so the above interpretation might be wrong. > >My guess is that you have an outdated version of libglib-2.0.so.0 in > >/usr/local/lib/ and that this non-Debian version is given precedence > >over the Debian one by the linker. (This kind of problem has popped up > >here a few times recently.) Run this command: > > > >ldd /usr/bin/update-desktop-database > > netrek:~# ldd /usr/bin/update-desktop-database > linux-gate.so.1 => (0xffffe000) > libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7f0c000) > libc.so.6 => /lib/libc.so.6 (0xb7dbf000) > libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb7d99000) > /lib/ld-linux.so.2 (0xb7fcc000) > > Nope I see nothing being loaded from /usr/local/ Yeah, these seem to be fine. [...] > Any other ideas? :) I saw that you filed a bug report (#460532). There seem to be two related older reports (#406709, #396439). In one case the submitter states in a follow-up that a corrupted .desktop file was to blame, but the general problem still seems unresolved to me. (Even if you also have a corrupt data file, the tool should deal more gracefully with such a situation.) I have two more suggestions for you to improve the chances of this bug getting fixed: 1) Just to be sure, check if there are any other stray libraries in /usr/local/lib. Run "ldconfig -pNX | grep /local/" as a normal user. If this comes up empty then your system is OK in that respect. 2) Install the packages libglib2.0-0-dbg, libc6-dbg, and libpcre3-dbg. Then use gdb again to get a better debugging report (with symbols) and send this output as a follow-up to your bug. The following trick should allow you to get your package manager going again: As root, do mv /usr/bin/update-desktop-database /usr/bin/update-desktop-database-HIDDEN ln -s /bin/true /usr/bin/update-desktop-database This moves update-desktop-database out of the way and replaces it with a symlink to /bin/true, a command that is always successful. The problematic installation scripts should complete now and the package manager should work again. (Once the bug is fixed you should remove the symlink and put the original file back in its place, of course. Then run update-desktop-database once as root.) -- Regards, | http://users.icfo.es/Florian.Kulzer Florian | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
