dbus is not started by upstart when the machine-id file is empty

[Michael Schmitz]

Binary package hint: dbus

Release: Ubuntu 10.04 LTS
dbus version: 1.2.16-2ubuntu4
Maybe related: #288596

During installation, the /var/lib/dbus/machine-id file presumably was initialized with no contents. After booting, gdm does not start up due to dbus not running.

dbus can be started manually using dbus-daemon --system --fork from a root shell, and gdm starts normally afterwards.

Apparently, the pre-start script in /etc/init/dbus.conf does not properly handle the case where machine-id is present but invalid. The relevant command in the pre-start script is dbus-uuidgen --ensure, my guess is that dbus-uuidgen --ensure exits with error failing to validate the UUID, and this causes dbus not starting from upstart.

Not sure what the correct strategy would be in this case - an empty UUID file is clearly going to fail and hence should be removed before dbus-uuidgen --ensure runs.

[ ! -s /var/lib/dbus/machine-id ] && rm -f /var/lib/dbus/machine-id* might do it, perhaps.

-- Michael

[Chol (chol83)]

Me and another person had the same issue: http://ubuntuforums.org/showthread.php?t=1470506

[Scott Prader (gnea)]

I ran into this problem while attempting to install Ubuntu Desktop 10.04 AMD64 onto a Zotac MCP7A with P4 dualcore CPU. Had to install Ubuntu Server instead and get gdm to work from there. After all of the updates were applied, I had an official 10.04.2 system and the problem still exists.

Everytime /etc/init/dbus.conf called 'exec dbus-uuidgen --ensure' the system would head toward an unstoppable kernel panic that only the reset or power buttons could recover from. To get around this, I followed the directions above. I removed /var/lib/dbus/machine-id* and commented 'exec dbus-uuidgen --ensure' out. The system now boots correctly to tty1, I can login and manually issue:

sudo dbus-daemon --system --fork && sudo service gdm start

and everything comes to life like it should. Have not noticed any problems with this setup as of yet, but I am willing to bet that there's a process somewhere that's not happy with this situation. Attempting to allow 'exec dbus-daemon --system --fork' to run at the tail end of /etc/init/dbus.conf results in a kernel panic as well. It isn't until everything else is loaded will 'dbus-daemon --system --fork' and 'service gdm start' work. It is for this reason that 'exec dbus-daemon --system --fork' is also commented out in /etc/init/dbus.conf

I will write an initscript or some sort of upstart script and post it here as an addendum at some point.