Mon, July 18, 2005 4:55:13 PM EDT
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.