Bonobo-activation-server sometimes is not killed after session restart, leading to many unexpected problems

[Óscar Rodríguez Ríos]

I edit the description of this bug to reflect recent discovery.

After the first sucessfull login, X is restarted using Ctrl+Alt+Backspace or due to a crash, or sometimes even due to normal logout, then either logins don't work anymore, or you can login, but popups warn you that the settings daemon cannot be reached, and the overall aspect of the session changes.

In the first case, the login name/password are accepted by gdm but gnome hangs on load after the login. This does not affect TTY or SSH logins. Restarting X again with Ctrl+Alt+Backspace, but the issue persists. All the users that have logged in at least once can't start the graphical session anymore. In both cases, killing bonobo-activation-server manually from a tty before login, solves the problem.

[Óscar Rodríguez Ríos (ingorr01)]

I've been investigating more and i think the problem is gconfd. I enter the system by ssh (with X forwarding) and can execute graphical apps like gftp and others but can't exec nautilus or evolution , applicactions of the gnome project. I start nautilus (in background) and it hangs and i list the process:

12909 pts/1 S 0:00 /usr/lib/libgconf2-4/gconfd-2 11
12912 ? Sl 0:00 /usr/lib/gnome-vfs-2.0/gnome-vfs-daemon --oaf-activate-iid=OAFIID:GNOME_VFS_Daemon_Factory --oaf-ior-fd=26
12929 pts/1 Sl 0:00 nautilus --browser
12932 pts/1 S 0:00 /usr/lib/nautilus-cd-burner/mapping-daemon

/var/log/syslog

Jun 13 22:16:32 oradio gconfd (radio-12909): comenzando (versión 2.14.0), pid 12909 usuario «radio»
Jun 13 22:16:32 oradio gconfd (radio-12909): Se resolvió la dirección «xml:readonly:/etc/gconf/gconf.xml.mandatory» a una fuente de configuración de sólo lectura en la posición 0
Jun 13 22:16:32 oradio gconfd (radio-12909): Se resolvió la dirección «xml:readwrite:/home/radio/.gconf» a una fuente de configuración escribible en la posición 1
Jun 13 22:16:32 oradio gconfd (radio-12909): Se resolvió la dirección «xml:readonly:/etc/gconf/gconf.xml.defaults» a una fuente de configuración de sólo lectura en la posición 2Jun 13 22:16:32 oradio gconfd (radio-12909): Se resolvió la dirección «xml:readonly:/var/lib/gconf/debian.defaults» a una fuente de configuración de sólo lectura en la posición 3
Jun 13 22:16:32 oradio gconfd (radio-12909): Se resolvió la dirección «xml:readonly:/var/lib/gconf/defaults» a una fuente de configuración de sólo lectura en la posición 4

I don't know what's up.

[Rouben (rouben)]

Seems like a messed up Gnome configuration to me that's causing it to hang. Can the users log in to a failsafe session? If so, tr y removing (or backing up just in case) any .gnome* or .gconf* directories in the home directories of the users that are having these issues, then restart X (Ctrl+Alt+Backspace) and then try logging in.

[Marius Gedminas (mgedmin)]

This happens to me often:

  1. I boot the machine, log in
  2. after some time I press Ctrl+Alt+Backspace to log out quickly
  3. I get a gdm login screen and log in again
  4. I get a blank desktop and nothing happens.

If I use ps at point 3, I see a number of processes left over from my previous session:

  - bonobo-activation-server
  - gconfd
  - evolution-data-server
  - several applets (netspeed, battstat, gweather, mixer, multiload, cpufreq)
  - esd

I can only log into gdm after logging into a text console and killing these processes manually.

neuromancer, what did you mean by "restarting"? Restarting X, or rebooting the computer? If rebooting, then what I see is a different bug.

[Marius Gedminas (mgedmin)]

Looks like bonobo-activation-server is at fault here. If I kill bonobo-activation-server but leave gconfd running, I can log in.

[Rouben (rouben)]

Does the same problem happen when you log out *properly*? :) If this only happens when you forcefully kill X, I doubt the Gnome developers would be interested in looking into this issue, because recent versions of gnome depend on a whole whack of background processes that don't get killed off properly when X is killed using the emergency "Control+Alt+Backspace" key combination. That's because that key combination is not really for normal use...

[Marius Gedminas (mgedmin)]

I do not know whether the same thing happens if I use logout properly, because I was unable to use logout properly until very recently -- bug 80343.
I'll check this soon.

Another thing: the same problem apparently occurs if the session crashes (bug 70618). Breaking logins after a crash is not good.

[Marius Gedminas (mgedmin)]

No processes are left if I use the GNOME menu to log out. This problem only occurs when the session crashes.

[Rouben (rouben)]

It would seem like a quick workaround for this would be to have some sort of "sanity check" script that kills hanging process(es) left over after a crash. At the very least bonobo-activation-server, since killing it seems to resolve the issue.

[Vincenzo Ciancia (vincenzo-ml)]

Rouben, you asked:

"Does the same problem happen when you log out *properly*? :) If this only happens when you forcefully kill X, I doubt the Gnome developers would be interested in looking into this issue, because recent versions of gnome depend on a whole whack of background processes that don't get killed off properly when X is killed using the emergency "Control+Alt+Backspace" key combination. That's because that key combination is not really for normal use..."

This does not happen when normally logging out, except that gnome does not allow you to log out or interact any way with the session for at least a minute after first login. So if you want to logout before that time you have to press ctrl+alt+backspace. Moreover, server grabs have locked the x session in many situations in front of my eyes. It is sad to say so, but we don't yet have the necessary stability to say that ctrl+alt+backspace is for exceptional situations. If my session deadlocks, and I press ctrl+alt+backspace, I am already upset. If I can't login and get back to work immediately, guess what will I say :) We *have* to unbreak this "session does not go away, session does not allow you to logout" thing that has been broken since the first release of gnome2 - and that, by the way, works in kde and xfce, and used to work in fvwm, afterstep and windowmaker.

[Jim Bailey (jim-freesolutions)]

Feisty 7.04

Sorry just quick notes

I am experiencing a similar problem after a power outage of my desktop. I can not use fail safe also user created with the gnome user creation tool work and lots of other stuff can not mess about too long as I have deadlines from hell backing up and going for a reinstall.

Just want to add a desktop that can not survive random reboots and power cycles of life hasn't really got a place in the office eco-system. IMHO Gnome devs need to address this issue with some urgency.

[Vincenzo Ciancia (vincenzo-ml)]

I have already written this comment, probably in the wrong LP form :) Hope to find that soon and edit it. Hoewever I have an important update:

this bug just happened to me *without* pressing ctrl+alt+backspace. I just logged out normally. Please raise the priority of this bug, I can solve this but it's a showstopper for new users. Please don't take this as the usual "vote for my bug" thing, I have more than 50 open bugs, but I think this is really important for the popularity of ubuntu. It's been affecting gnome since the beginning. Please let's kill this old beast all together.

[Vincenzo Ciancia (vincenzo-ml)]

And I would like to add that, with the addition of compiz in gutsy, it can sometimes happen that X crashes. In this situation, this bug happens, you get a warning from nautilus saying that you should kill a process that you never heard of. And many users don't even know what killing a process means. Could bonobo-activation-server be killed at login if it's running and not reachable? Is someone following this bug at all? It's really old, grave, and still unconfirmed. Priority should be raised.

[Vincenzo Ciancia (vincenzo-ml)]

Message given by nautilus at startup after compiz crash:

"Nautilus can't be used now, due to an unexpected error from Bonobo when attempting to locate the factory. Killing bonobo-activation-server and restarting Nautilus may help fix the problem."

[Peter Würtz (pwuertz)]

I experienced a problem that looks related to your report. When starting a gnome session for the second time, the gnome-panel fails to load several applets. Instead, I'm getting a error message for each applet. I tried deleting .gnome, .gnome2, .gconf, .gconfd and killing gconfd-2, but only a complete reboot fixed the panel applets. When gracefully logging out from the gnome desktop or just killing X, the problem occurs on the next session again.

Recently I discovered the bonobo-activation-server running in the background. After killing this service, the broken panel loads just fine again.

I assume this is the same kind of bug, although the problem arises in a different way.

[Peter Würtz (pwuertz)]

My bug seems to be related to #90258. Since Marius Gedminas reported a residual evolution-data-server running after a terminated X session, it could be possible that this is the very same problem as stated in #90258.

[oliver (olivertwilson)]

i'm a newbe and i would like to know how to kill a process so the panel can load properly. what are the exact command line instructions? this is the displayed error message on my screen after login:"Nautilus can't be used now, due to an unexpected error from Bonobo when attempting to locate the factory. Killing bonobo-activation-server and restarting Nautilus may help fix the problem."

[Chow Loong Jin (hyperair)]

The command:
killall bonobo-activation-server

To restart nautilus:
killall nautilus
nautilus & disown

[oliver (olivertwilson)]

thank you for your quick response. this is the solution to the problem: ctrl-alt-f1
[login as me]
sudo date --set 01/08/2007
sudo killall gdm
sudo /etc/init.d/gdm start

the problem originated from a dead PRAM battery(i think), well anyway the os is up and running now.
thanks again...oliver

hyperair <email address hidden> wrote: The command:
killall bonobo-activation-server

To restart nautilus:
killall nautilus
nautilus & disown

--
Bonobo-activation-server sometimes is not killed after session restart, leading to many unexpected problems
https://bugs.launchpad.net/bugs/49594
You received this bug notification because you are a direct subscriber
of the bug.

[Anton Shestakov (av6)]

Could this bug:
https://bugs.launchpad.net/ubuntu/+bug/179722
be related?

The symptoms are quite similar, though a bit different.

[tomaszko (kossut)]

hardy affected, gnome doeas not load- just hangs. No matter what kind of a session you choose.

[tomaszko (kossut)]

fix form me:
sudo apt-get update
sudo apt-get upgrade

(optionally check if your card have acceleration on)

regards,

tom

[Cyrille Bieuzent (bieuzent)]

fix form me too :

sudo dpkg-reconfigure -all

cyrille

[Albert Y. C. Lai (trebla)]

I consistently see bonobo-activation-server not killed after *proper* logout. Using:

hardy beta LiveCD
hardy beta fresh install, with or without updates.
hardy beta upgraded over gutsy, with or without updates.

I cross-reference this bug with #207761:

https://bugs.launchpad.net/ubuntu/+bug/207761

where the trash can becomes invisible and consistently correlated with this.

I have also observed an instance when this does not occur. Use "user switching" to login to another account, then logout from it. That one's bonobo-activation-server doesn't persist.

Here is my personal temporary workaround: create text file named ".xprofile" in home directory. Its content is this line:

killall -u $USER bonobo-activation-server

This kills the leftover process at the time of next GUI login.

[Ric Flomag (ricflomag)]

Thanks Albert, your workaround does fix the problem for me.

[LavianoTS386 (lavianots386)]

I'm having this same problem on my Asus EEE, every time I try to log into gnome when I try to run on battery. The moment I plug in the power cord gnome loads.

[theLawman (billieboy)]

This is a big problem for me on a Hardy fresh Install and effects me even after a "normal" shutdown. I have however noticed that sometimes a "normal" shutdown doesn't go as smoothly as it did in Gutsy etc.

Sometimes I get into the Desktop and have a programme (E.g. Gnucash up and working) and the error message hits when I try another programme from the panel

What I try to do to fix it short terms is Ctrl- Alt-F2 then kill bonobo-activation-server then back to desktop with Ctrl-Alt-F7 and then Ctrl-Alt-Backspace and sometimes that works. I have also tried Albert's workaround but I still had the problem.

There do seem to be a lot of instances of this problem and it is adversely effecting the way I can work - can I use Hardy for mission critical work now? I am not sure.

Can and should this be elevated to a High level of importance.

[Vincenzo Ciancia (vincenzo-ml)]

At least can we know why it is useful to have bonobo-activation-server left over when getting out of X? Is it just a plain bug or should it be reused at next login?

[Sebastien Bacher (seb128)]

this is not a gnome-session bug

[Sebastien Bacher (seb128)]

it's not useful to have it still running, that's clearly a bug, it means a software in the universe is not unreferencing something clearly, there is no obvious way to know which one though which makes the issue quite difficult to track

[Vincenzo Ciancia (vincenzo-ml)]

Sebastien, thanks for your (prompt, as usual) reply. A first solution
that comes to mind to be sure to avoid this is to run
bonobo-activation-server synchronously from an X child, so that it gets
killed by the operating system when X dies. However, I imagine that two
different gnome sessions would share the bonobo-activation-server
daemon. Is this the case? If not, then a patch might be easier than it
seems.

Vincenzo

[Sebastien Bacher (seb128)]

the server is ran by user but it's not specific to an xorg session so that would not be right, the real fix would be to find what software is not cleaning ressources correctly

[Gonzhauser (gonzhauser)]

I had a similar problem:
Adding a Google Calendar to evolution makes my system hang
when clicking the clock in the gnome panel.
After killing bonobo and removing the calendar everything works again.
It seems to me that the google calendar in evolution is flaky.

[toobuntu (toobuntu)]

Discussed here with a workaround: http://www.bxlug.be/en/articles/74 (Cleaning of GNOME processes at logoff)

Problem is, that workaround will kill ALL bonobo processes for ALL USERS. Not the result we're looking for...

BTW, that article is dated 2004, and this is still an issue. Wow.

[crazybrit4967 (crazybrit4967)]

I think I had this bug before with an earlier version of Ubuntu. What had caused it was that I had taken out the lines
auto lo
iface lo inet loopback
from my /etc/network/interfaces file. Adding those lines back in fixed the problem for me. Hope this helps.

[toobuntu (toobuntu)]

those lines are present in our /etc/network/interfaces files and we still see processes running after a user logs out.

$ ps U <user-who-logged-out>

most of the time bonobo is listed there; sometimes others as well.

[antonioni (antonioni-rocha)]

The problem of the trash applet occurs here, too.

[crjackson (crjackson)]

I'm having the issue of the trashcan icon going invisible on one computer, and wireless almost never working on another. This happend on the most recent 06/02/2008 batch of updates for Hardy 32-bit.

There were kernel updates that required a restart and many gnome updates. After rebooting, I lost the trash can icon (it's there, just invisible, so adding another one does no good), and the wireless on my laptop is almost impossible to get working after a reboot. I have to leave the stupid thing turned on all the time in order for wireless to work.

[ollie (ollie-ollie)]

I can confirm the bug on Hardy intel 32bits, up to date and using the "proposed" repositories.

In my case the affected symptom is a few applets (most notably the trash icon) disappearing from panels. The problem persists even after several reboots. But, if I manually kill bonobo-activation-server and then restart the panels (killall gnome-panel) the affected applets are displayed again.

[Tito's (rcarrasco)]

Same problem here. Using previously AVM and now using a bottom panel. The trash icon disappears after adding it

8.04 latest updates running on Compaq v3117la

[Alexander Jones (alex-weej)]

There are two problems here for applets -- one is that b-a-s launches with the first gnome-session and seems to stick around way too long.

The second is that it inherits a Session Bus socket address that is only actually valid for one session. Bonobo has mechanisms for allowing its activated objects inherit specific environment variables from the launching process, rather than b-a-s. PLEASE direct all bugs for applets falling in this case to new reports. The fix is outlined in https://bugs.launchpad.net/ubuntu/+source/gnome-applets/+bug/211604/comments/11 - try it.

[jdelima (jdelima307)]

it seems i have the same problem. but i still don't know how to work around it after browsing through all the comments, which are too technical for me. e.g., what exactly does the following "Bonobo has mechanisms for allowing its activated objects inherit specific environment variables from the launching process, rather than b-a-s." mean?

or the fix outlined in https://bugs.launchpad.net/ubuntu/+source/gnome-applets/+bug/211604/comments: "Edit: /usr/lib/bonobo/servers/GNOME_Panel_TrashApplet.server

Add this inside the <oaf_server location="/usr/lib/bla/trashapplet"> element
(NOT the one with the location="OAFIID:bla")

    <oaf_attribute name="bonobo:environment" type="stringv">
        <item value="DBUS_SESSION_BUS_ADDRESS"/>
    </oaf_attribute>"

what exactly should i do to solve the problem?

thanks!

[ollie (ollie-ollie)]

The fix suggested above doesn't work. GNOME_Panel_TrashApplet.server already has the suggested oaf_atrribute (bonobo:enviroment) inside the correct oaf_server location and the trash applet still doesn't work.

But not only that, bonobo-activation-server now is affecting my eog. I've noticed in every session eog starts to behave erratically (sometimes works, sometimes silently drops) until it simply stops working. Launching it from the command line (ie, "eog picture.jpg") works, but trying to open the same file via nautilus default association doesn't work. After a while, "ps ax | grep eog" shows all the stuck eog processes stuck cluttering the memory, and they need to be killed.

This bonobo bug evolved from being an annoyance (panel applets) to being a productivity killer and major show stopper (eog not working). I'm now considering some form of rollback.

[Alexander Jones (alex-weej)]

File a bug against EOG. And open a new bug about whatever problem you're
having with the Trash applet. I'm certain it's not the same problem, even if
it is the same symptoms.

[ollie (ollie-ollie)]

I appreciate your help, my friend, and I'm happy you're -certain- this isn't the same problem. Indulge me, however. EOG (ie "eog picture.jpg") works via command line, but then it doesn't work while being called via nautilus (ie double-click picture.jpg) when bonobo is on. The EOG process hangs. Kill bonobo momentarily, and EOG resumes working. You know what's funny... if I had a number of failed attempts to open a picture with EOG, and haven't killed their individual processes, the second I kill b-a-s, they all pop up. So that's an EOG bug I should file? Really?

Same with the Trash Applet... "killall gnome-panel; killall bonobo-activation-server" (so gnome-panel is restarted while b-a-s isn't yet running) restores the trash applet, if only for the rest of the current session. Same with the timer applet. Same with weather. I wouldn't go so far as to say I'm certain, but I do have a strong suspicion filing a string of duplicate bugs against each app and applet affected by something bonobo is doing wrong isn't the way to go. And yes, perhaps this isn't the right bug. But all these problems were introduced to me by the last bonobo-activation update, and up in these comments people were discussing bonobo screwing up the applets, so I thought it applied. I'm sorry if it isn't the case, I'll take it elsewhere. By the way, I use the "proposed" repos so I kinda expect minor breakage once every blue moon but this is ridiculous by any standards.

[Alexander Jones (alex-weej)]

Stop arguing and do it, please. None of the information you're adding helps
us to fix THIS bug, which is that b-a-s outlives its welcome.

[toobuntu (toobuntu)]

Here's my workaround that, once set up, requires no further intervention by the sysadmin (me) in our corporate environment (see https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/236210/comments/6):

In short, we are creating a shell script to kill all the remaining user processes after logging out of GNOME, setting that script suid root, and having gdm call that script upon log out.

$ cat /usr/local/bin/kill-stragglers-auto
#!/bin/bash

# takes 1 argument: the username of the user who logged off

USER=$1
sudo kill -9 $( ps U $USER | grep -v TTY | awk '{print $1}' ) 2> /tmp/kill-stragglers-auto.errors.log
sudo /etc/init.d/gdm restart

$ sudo chmod +s /usr/local/bin/kill-stragglers-auto

$ ls -lh /usr/local/bin/kill-stragglers-auto
-rwsr-sr-x 1 root root 213 Aug 27 18:32 /usr/local/bin/kill-stragglers-auto

$ cd /etc/gdm/PostSession

$ ls -lh
total 8.0K
-rwxr-xr-x 1 root root 395 Aug 27 18:30 Default
-rwxr-xr-x 1 root root 305 Aug 27 18:29 Default.080827.orig

$ tail Default
    fi
  done
  IFS=$OLD_IFS
  echo "$OUTPUT"
}

# the following was added by toobuntu on 080827:
/usr/local/bin/kill-stragglers-auto ${USER}

exit 0

Hope this helps someone!

[toobuntu (toobuntu)]

note that we only have user names without spaces or special characters. you may want to use brackets and quotes around the variables to get my workaround working in your environment.

[toobuntu (toobuntu)]

Improvement: Simply add 2 lines to /etc/gdm/PostSession/Default and do _not_ store a backup of Default in the PostSession directory.

$ ls /etc/gdm/PostSession/
Default

$ tail /etc/gdm/PostSession/Default
  done
  IFS=$OLD_IFS
  echo "$OUTPUT"
}

# the following 2 lines were added by toobuntu on 080828:
kill -9 $( ps U "${USER}" | grep -v TTY | mawk '{print $1}' ) 2> /tmp/kill-stragglers-gdm.errors
/etc/init.d/gdm restart

exit 0

-----
FYI- From http://www.gnome.org/projects/gdm/docs/2.14/configuration.html :

When the user terminates his session, the PostSession script will be run. Again operation is similar to Init, PostLogin and PreSession. Again the script will be run with root privileges, the slave daemon will block and the $USER environment variable will contain the name of the user who just logged out and $DISPLAY will be set to the display the user used, however note that the X server for this display may already be dead and so you shouldn't try to access it. Also $X_SERVERS environmental variable is set and this points to a fake generated X servers file for use with the sessreg accounting application.

Note that the PostSession script will be run even when the display fails to respond due to an I/O error or similar. Thus, there is no guarantee that X applications will work during script execution.

[toobuntu (toobuntu)]

2009-01-31 update - I just filed separate bugs about this issue against the following pursuant to the instructions of Sebastien Bacher, who advised: "the issue is not a gdm one, you should rather open bugs for buggy servers which don't have a bug open yet" (https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/236210/comments/10):

libbonobo (Bug #323604)
gvfs (Bug #323606)
evolution-data-server (Bug #323607)
gconf (Bug #323608)

If you still experience this issue with any of these, then please confirm those bugs so this issue can be fixed properly. In the meantime, there is an easy workaround listed in those bug reports that I don't see why it couldn't be adopted by Ubuntu, indeed even GNOME (GDM), as a default. There seems to be no harm done, and it solves this problem for all aberrant processes.

[xteejx (xteejx-deactivatedaccount)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

[jdelima (jdelima307)]

this has long ceased to be an issue.

Teej wrote:
> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. You reported this bug a while ago and there hasn't been
> any activity in it recently. We were wondering if this is still an issue
> for you. Can you try with the latest Ubuntu release? Thanks in advance.
>
> ** Changed in: libbonobo (Ubuntu)
> Status: New => Incomplete
>
> ** Changed in: libbonobo (Ubuntu Hardy)
> Status: New => Incomplete
>
>

[xteejx (xteejx-deactivatedaccount)]

Thank you for updating us. Marking this as Fix Released.