Comment 13 for bug 1217757

Tyler Hicks (tyhicks) wrote :

This bug is very finicky to reproduce. I've been testing with completely up to date and pristine Saucy virtual machines on both amd64 and i386, *without* the AppArmor mediation dbus package (so I'm testing dbus 1.6.12.0ubuntu2).

These are throw away VMs that I create and trash as needed. I'll create one and it will never hit this bug, hit this bug on some boots, or hit this bug on every boot. I haven't been able to see pattern.

However, I currently have an i386 VM that is hitting this bug on every boot. This is the contents of ~/.xsession-errors:

$ cat ~/.xsession-errors
Script for cjkv started at run_im.
Script for default started at run_im.
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd main process ended, respawning
init: at-spi2-registryd respawning too fast, stopped

I don't know much about at-spi2, but I noticed that this dbus method call hangs until a timeout is reached:

$ sudo dbus-send --session --print-reply --dest=org.a11y.Bus /org/a11y/bus org.a11y.Bus.GetAddress
Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Command exited with non-zero status 1
real 25.02
user 0.00
sys 0.00

There are no AppArmor denials in the syslog and dbus dbus 1.6.12-0ubuntu2 is running, so I think it is completely safe to say that AppArmor and AppArmor D-Bus mediation is not at fault here.