Extremely Strange, Strange Problem with Bonobo
I did some updating of a Red Hat Linux Enterprise Edition (rhel-i386-ws-3) box a couple weeks ago, and hosed X windows. I got the following errors in the log when running startx:
** (gnome-panel:1735): WARNING **: Extremely strange, strange object directories (0)registered with the activation context ** (nautilus:1737): WARNING **: Extremely strange, strange object directories (0)registered with the activation context
And the following three dialog boxes would appear on screen:
Nautilus can't be used now, due to an unexpected error.
There was a problem registering the panel with the bonobo-activation server. The error code is: 3 The panel will now exit
There was an error starting the GNOME Settings Daemon
Some things, such as themes, sounds, or background settings may not work correctly.
The Settings Daemon restarted too many times.
GNOME will still try to restart the Settings Daemon next time you log in.
This problem, while not urgent, has sucked up all of my spare time at work for weeks. Finally, I decided to peek at the source code that generated the log error messages.
Deep in the bowels of bonobo-activation-init.c, I discovered the meaning of "Extremely strange, strange object directories (0)registered with the activation context".
It means: "NO object directories registered with the activation context". Apparently the programmer considers 0 to be a strange number. In fact, according to the code, he considers any number that isn't 1 to be a strange number.
Not that he indicated the problem was with the number of object directories, or that he was expecting exactly one, or anything as helpful as that. In fact, he didn't even indicate that the problem was with bonobo; at an earlier stage, I was just getting the panel one, and assumed the problem was there. Using his usage, I'd say he has a strange idea how to write error messages.
I'd like to say that, armed with this knowledge, I immediately found the problem, but that's not true: it would have saved me a few hours, though.
What eventually fixed it was that I compared the list of installed packages (using "rpm -q --all") on the broken machine with the list from a new install on another machine. And discovered the following discrepancy:
Broken: ORBit2-2.8.2-1 Good: ORBit2-2.6.2-1
So I tried downgrading the ORBit2 package from 2.8 to 2.6:
[17:18:48 /tmp]$ sudo rpm -e ORBit2 --nodeps [17:23:41 /tmp]$ sudo up2date --install ORBit2 Invalid group id server-cfg Invalid metapkg id emacs-nox Fetching Obsoletes list for channel: rhel-i386-ws-3... Fetching rpm headers... Name Version Rel ---------------------------------------------------------- ORBit2 2.6.2 1 i386 Testing package set / solving RPM inter-dependencies... ORBit2-2.6.2-1.i386.rpm: ########################## Done. Preparing ########################################### [100%] Installing... 1:ORBit2 ########################################### [100%] [17:24:37 /tmp]$ ps -ef |grep X root 2226 2225 0 17:23 ? 00:00:00 /usr/X11R6/bin/X :0 -auth /var/g [17:24:44 /tmp]$ sudo kill -1 2226
And, without even rebooting, everything worked again. Fixed. Problem solved.
Why, oh why, didn't up2date warn me that I had packages that were newer than the rest of the channel? Grr.