Fails to run lib/dbus-1.0/dbus-daemon-launch-helper: not owned by the messagebus group

Bug #295405 reported by David on 2008-11-08
This bug affects 17 people
Affects Status Importance Assigned to Milestone
dbus (Ubuntu)

Bug Description

Nothing happens when I select the "Hardware Drivers" from the System/Administration window.

I am using the latest vesion of Ubuntu 8.10 (Intrepid) Server AMD64
uname -a: Linux CERTIBY-DEV1 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux

david@CERTIBY-DEV1:~$ apt-cache policy jockey-gtk
  Installed: 0.5~beta3-0ubuntu5
  Candidate: 0.5~beta3-0ubuntu5
  Version table:
 *** 0.5~beta3-0ubuntu5 0
        500 intrepid/main Packages
        100 /var/lib/dpkg/status

When I run the program from the command line I get:
david@CERTIBY-DEV1:~$ jockey-gtk
Traceback (most recent call last):
  File "/usr/bin/jockey-gtk", line 377, in <module>
  File "/usr/lib/python2.5/site-packages/jockey/", line 412, in run
  File "/usr/bin/jockey-gtk", line 98, in ui_show_main
  File "/usr/bin/jockey-gtk", line 245, in update_tree_model
    for h_id in self.get_displayed_handlers():
  File "/usr/lib/python2.5/site-packages/jockey/", line 719, in get_displayed_handlers
    return self.backend().available(self.argv_options.mode)
  File "/usr/lib/python2.5/site-packages/jockey/", line 88, in backend
    self._dbus_iface = Backend.create_dbus_client()
  File "/usr/lib/python2.5/site-packages/jockey/", line 642, in create_dbus_client
    obj = bus.get_object(DBUS_BUS_NAME, '/DeviceDriver')
  File "/var/lib/python-support/python2.5/dbus/", line 244, in get_object
  File "/var/lib/python-support/python2.5/dbus/", line 241, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/var/lib/python-support/python2.5/dbus/", line 183, in activate_name_owner
  File "/var/lib/python-support/python2.5/dbus/", line 281, in start_service_by_name
    'su', (bus_name, flags)))
  File "/var/lib/python-support/python2.5/dbus/", line 607, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /lib/dbus-1.0/dbus-daemon-launch-helper: Success

Martin Pitt (pitti) wrote :

Do you actually have the package "dbus" installed? I guess that's the reason why it fails. jockey-common depends on python-dbus, but that doesn't depend on "dbus" itself, just on the client libraries.

Changed in jockey:
status: New → Incomplete

Ah, no; jockey-common depends on policykit, which depends on dbus. So unless you manually forcefully removed it, you should have dbus installed. Can you please give me the output of

  ls -l /lib/dbus-1.0/dbus-daemon-launch-helper


David (david-kahn) wrote :

ls -l /lib/dbus-1.0/dbus-daemon-launch-helper
-rwsr-xr-- 1 root messagebus 47704 2008-10-07 07:26 /lib/dbus-1.0/dbus-daemon-launch-helper

Martin Pitt (pitti) wrote :

That looks correct. Can you reproduce this, or was it an one-time glitch? If it happens every time, please try this:

  sudo killall jockey-backend
  sudo /usr/share/jockey/jockey-backend 2>&1 | tee /tmp/jockey.log

then try to start jockey from the menu. Does that work now? After you close the window, press Control-C in the terminal where you started jockey-backend.

If anything fails, please attach /tmp/jockey.log.

Is that a normal local session, or are you working over ssh, VPNC, or anything like that?

David (david-kahn) wrote :

1. sudo killall jockey-backend
    jockey-backend: no process killed
2. sudo /usr/share/jockey/jockey-backend 2>&1 | tee /tmp/jockey.log
3. Ran the "Hardware Drivers" application, and nothing happened.
4. Entered ^C in terminal window
5. cat /tmp/jockey.log showed that the file was empty, so I didn't upload it.

I have been using gnome-terminal locally in all cases.

The problem with not being able to run the "Hardware Drivers" application is not a one-time glitch. I have never been able to run it since upgrading to Intrepid.

The computer has been flaky in other respects since I upgraded:
1. The Update Manager no longer runs automatically daily, even though configured to do so. Fortunately, I can run it manually.
2. Can't start the Services manager application. There is a pop up "You are not allowed to access the system information" and when I run services-admin from the command line there is a message:
    ** (services-admin:18805): CRITICAL **: Failed to execute program /lib/dbus-1.0/dbus-daemon-launch-helper: Success
3. Cannot mount a USB memory disk drive
4. I had to set YPBINDARGS=-no-dbus in /etc/default/nis to get nis to run

I have another computer with the same hardware (other than one extra disk), that also started at Feisty and also upgraded to Gutsy, Hardy, Intrepid, and has virtually the same software setup that works perfectly.

Martin Pitt (pitti) wrote :

OK, seems you have a much more general problem with D-BUS then. To be honest I don't really know what to look for now, but let's first make sure the other packages are correct. What's the output of

  dpkg -l dbus policykit consolekit


David (david-kahn) wrote :

david@CERTIBY-DEV1:/etc/default$ dpkg -l dbus policykit consolekit
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
ii consolekit 0.2.10-1ubuntu9 framework for defining and tracking users, sessions and seats
ii dbus 1.2.4-0ubuntu1 simple interprocess messaging system
ii policykit 0.9-1ubuntu3 framework for managing administrative policies and privileges
david@CERTIBY-DEV1:/etc/default$ ck-list-sessions

** (ck-list-sessions:1262): WARNING **: Failed to get list of seats: Failed to execute program /lib/dbus-1.0/dbus-daemon-launch-helper: Success

Martin Pitt (pitti) wrote :

Right, that again. Can you please try

  strace -o /tmp/trace -f ck-list-sessions

and attach /tmp/trace here?

David (david-kahn) wrote :

david@CERTIBY-DEV1:~$ strace -o /tmp/trace -f ck-list-sessions

** (ck-list-sessions:14000): WARNING **: Failed to get list of seats: Failed to execute program /lib/dbus-1.0/dbus-daemon-launch-helper: Success

However, it did generate the attached trace.

Martin Pitt (pitti) wrote :

OK, thanks. Unfortunately that didn't give me any insight yet. Let's try something else:

  sudo strace -s 4096 -f -o /tmp/trace -p `ps h -o %p -U messagebus`

This will block. Open a second terminal, and do


Then go back to the first one, press Control-C, and attach /tmp/trace here. Thanks!

David (david-kahn) wrote :

I really appreciate the interest you are taking in solving this.

Martin Pitt (pitti) wrote :

Ah, that revealed something more interesting:

9568 execve("/lib/dbus-1.0/dbus-daemon-launch-helper", ["/lib/dbus-1.0/dbus-daemon-launch-helper",
9568 <... execve resumed> ) = -1 EACCES (Permission denied)

So apparently /lib/dbus-1.0/dbus-daemon-launch-helper isn't executable for the user "messagebus". That' s a bit weird, since in comment 3 the actual program permissions are correct, and since (I presume) you ran "ls" as normal user the directory permissions should be okay, too. However, please check/give me the output of

  ls -ld /lib
  ls -ld /lib/dbus-1.0

They should both be drwxr-xr-x root:root. Also, please try to manually run it as user messagebus:

  sudo -u messagebus /lib/dbus-1.0/dbus-daemon-launch-helper

What's the output?

Let's also check integrity of the binary:

  (cd /; md5sum -c /var/lib/dpkg/info/dbus.md5sums )

Any line which doesn't say "Ok"?

Finally, do you get anything interesting in dmesg if you do this? If you aren't sure, and it's just technobabble to you, please attach /var/log/kern.log after those tests.


David (david-kahn) wrote :

You comment that "apparently /lib/dbus-1.0/dbus-daemon-launch-helper isn't executable for the user "messagebus"" caused me to look at /etc/passwd and /etc/group on the computer with these problems, and I found a major problem.

The entry in /etc/passwd was:


which put the messagebus user in group 112.

But the entry in /etc/group was:


I checked the computer that wasn't having the problems, and the messagebus user was in the expected group. Therefore, I hand edited the user messagebus entry to be a member of the messagebus group, and as far as I can tell all of the problems I listed on 11/25 are fixed -- though I won't know until tomorrow in the cron job to run the update manager is working. I also was able to reinstall network-manager, which had be previously unmounting my primary disk during startup.

I can think of no reason why I would have ever edited the messagebus entry in /etc/passwd, and it would be out of character for me to mis-edit/mis-configure the user. Someone might want to investigate whether this mis-configuration of the messagebus user is prevalent, as I have heard that many people had trouble with the network-manager after upgrading to Intrepid, and the bug which many people encountered was fixed by this as well.

QUESTION: Is there a chance of files existing where the group permissions are for the wrong gid?

In any case. Thank you very much for your patience and persistence.

Martin Pitt (pitti) wrote :

Ah, that would indeed be it. Now, the interesting question is indeed how that happened. I believe you that you didn't hand-edited that, it would be a very unusual thing to do. Did you ever use sytem -> admin -> users and groups? (the program "users-admin"). In earlier releases it had a grave bug which removed users from groups, but that was fixed around the dapper to feisty timeframe. But it's entirely possible that it has another bug which scrambles group IDs. It's the first time I see it, though.

> QUESTION: Is there a chance of files existing where the group permissions are for the wrong gid?

Yes, that's technically possible. Create a user or group, chmod/chgrp the file, remove the user/group.

David (david-kahn) wrote :

I have never used the program "users-admin". However, an odd thing just happened. When I tried to start users-admin to see if it looked familiar, I got the massage that I didn't have permission to run it. So I checked the messagebus user in /etc/passwd, and it was okay. I then retested all of the symptoms, reported in earlier postings, and they all were failing once again However, rebooting the computer fixed everything. So there's still an unexplained lingering intermittent problem, which is very troubling.

When the entry in /etc/passwd was:
which put the messagebus user in group 112. There was already a valid group with a gid of 112: ssl-cert

I didn't know an easy to find all of the files on my disk which were owned by that group, so I ran:

     sudo ls -l -R * | grep ssl-cert > ~/ssl-cert

(results attached) and didn't find any suspect files that were created by the messagebus user while its default gid was 112. Therefore, it looks like this wasn't a problem.

Martin Pitt (pitti) wrote :

So you are saying that on your system, both the ssl-cert and the messagebox group shared the same group ID? Eww... Any idea how this could have happened?

Your command certainly works, although "find / -uid 112" is the canonical, and probably more efficient, incantation.

As for your attached output, this is strange:

  l-wx------ 1 david admin 64 2008-11-28 15:00 1 -> /home/david/ssl-cert

the rest looks okay to me.


This really looks like something removed the messagebus group and caused it to be recreated with a new gid

Changed in dbus (Ubuntu):
status: Incomplete → Invalid

I think it's something wrong in the dbus setup package.
I have had the same issue as the OP - the dbus executable file has permissions set up improperly. I also have most of the system groups < 1000 exported out from a common NIS server. ( need common administrators across various computers, admin and adm being one of those groups < 1000 ). Unfortuantely, this also pushes out the messagebus group across to the various computers ( again, it's a system group < 1000 ).

This screws up whatever sets up the permissions in the dbus package, leaving the file with permissions pointing to the REMOTE dbus group instead of the local group, giving us this sort of broken permissions.

Fixes? Either rewrite the dbus setup thing to change ownership to the right GID, or put the admin, adm groups > 1000, because in a networked environment with a need for common administrators, they really OUGHT not to be system/computer groups.

Either that, or we add a new module to nsswitch to merge NIS+local groups in a way that is better than the one right now [check NIS, then check local], so we don't have 2 database, and thus, problems like this....

It's a somewhat-bug in the setup package...

Changed in dbus (Ubuntu):
status: Invalid → Confirmed

On Wed, 2009-07-15 at 21:05 +0000, Fish wrote:

> I have had the same issue as the OP
While you may have the same issue, it is unlikely you have the same bug.
Please do not hijack somebody else's report, and instead file a new bug
for your problems.

Scott James Remnant
<email address hidden>

Changed in dbus (Ubuntu):
status: Confirmed → Invalid

Fair enough, but I'd say the chances of the two issues being related are fairly likely (messagebus user points to wrong messagebus group in both cases). I'll file another bug report, but I'm pretty sure it'll be marked as a duplicate of this one.

hobel (hobel) wrote :

Same here with 9.04 kubuntu... kdm drops out, I see problems launching the dbus helper.
This worked before upgrading to 9.04, with 8.10 I had no problems.

$ grep messagebus /etc/passwd

$ grep 115 /etc/group

no idea how that can happen...

gpk (gpk-kochanski) wrote :

Also for me. I upgraded from a working 8.10 system to 9.04 ubuntu,
and the greeter didn't show any user names. Logs (syslog and gdm/*.log)
showed errors executing dbus-daemon-launch-helper and the
UID and GID of messagebus didn't match.

I fixed the GID of the messagebus user in /etc/passwd and the
system rebooted properly.

So, it's a clean test: working before upgrade, failed after upgrade.

Reopening. Duplicate 475503 has several reporters confirming that this still happens when upgrading to Karmic. We should find out whether this comes from the d-bus package of from another part of the system that recreates the group with a wrong GID. Seems really strange.

Changed in dbus (Ubuntu):
importance: Undecided → Medium
status: Invalid → Triaged
Dennis Sledge (dennis-sledge) wrote :

First, let me thank everyone across the web that has been posting information about this bug. It gave me a serious headache for a couple days until I finally figured out a fix that worked. Here is what I did to permanently alleviate the problem:
Delete (or comment) the messagebus line from /etc/group.
Delete (or comment) the messagebus line from /etc/passwd.
Reinstall the dbus package: sudo apt-get install --reinstall dbus

/etc/passwd should have a something similar to:

and /etc/group should have something similar to:

The main idea is that the user/group id need to be the same and cannot exist as the same number for another group/user.

See for another discussion about this bug.

Maik Holtkamp (s-y-l) wrote :

Sorry for the noise, seem that the root of evil is found after reading The gid for user messagebus from /etc/passwd was different from the gid of group messagebus in /etc/group. Edited manually and everything seems to work like a charm again, except the things I tried to fix be various workarounds in the meantime :(

Gerry Reno (greno-verizon) wrote :

Dennis, the bug you pointed to does not say that the user and group id need to be the same. It says that there are two groups using the same id which causes the error. It is perfectly allowable to have a user id and group id be different from each other.

Gerry, does the procedure explained here fixes your probem? Of course, this feels wrong, but one explanation can be that some files on the system still have the GID corresponding to the messagebus UID, and going back to that value fixes the problem. You could also find those files and fix their GID, but that's harder.

Gerry Reno (greno-verizon) wrote :

Seriously, a user cannot be expected to get into a terminal and go searching their entire system trying to fix up GIDs that were incorrectly set by some package. That isn't even a possible general workaround.

This bug is a SHOWSTOPPER for Ubuntu Lucid. The majority of users are not going to know how to properly setup a user or group account from the command line and get /etc/skel files copied and anything else that needs set. Most users are going to use the menues and go System | Administration | Users and Groups and hit the error which prevents them from doing anything with Users or Groups.

There is an underlying bug here in some package that is incorrectly setting the wrong GID or looking at the wrong GID in /etc/group.

The bug I opened, Bug #598909, right now does not appear to be a duplicate of this bug. All the other cases seem to be centered around duplicate GID's. That is not the case with Bug #598909. If you want them linked then forget about duplicate GID's entirely. There is something else going on here.

Gerry: your bug doesn't present duplicate GIDs, but the problem here is not about them. Be GIDs duplicate or not, the real issue is that the launcher program is not owned by the 'messagebus' group. The fact that it's using a GID used by another group is a coincidence that doesn't change anything (just messes things a bit more).

But please - this bug is serious, but the fact that you ran into it doesn't mean everybody is experiencing it at all. Nobody is assuming users are able to fix it by running terminal commands, but please explain us how to fix it, and we surely will! ;-)

This bug must come from some program changing by mistake the GID for the messagebus group. But this kind of bug is very hard to tackle, since it affects a limited parts of users (only a handful of reporters so far), and we don't know what's the common denominator to all of them.

If you want to help, you have to find what's in common to all these cases. So:
- what's the first Ubuntu version reporters have installed, and how/when did they upgrade until Lucid?
- is there something noteworthy that isn't standard on their systems - whose nature is hard to guess beforehand?

A hint: as Scott said, "This really looks like something removed the messagebus group and caused it to be recreated with a new gid."

Another solution would be to force changing the owner group of the launcher when installing package, which wouldn't be too hard.

Changed in dbus (Ubuntu):
importance: Medium → High
summary: - fails to run lib/dbus-1.0/dbus-daemon-launch-helper
+ Fails to run lib/dbus-1.0/dbus-daemon-launch-helper: not owned by the
+ messagebus group
Gerry Reno (greno-verizon) wrote :

It did not seem to matter that the launcher was group as 'messagebus'. It still generated the error even after I changed the group.

In my case it was a fresh install of Ubuntu Lucid server and followed by an install of ubuntu-desktop. Those were the main packages.

Gerry Reno (greno-verizon) wrote :

I reinstalled 'dbus' and this cleared the error but I'm seeing strange behavior.

Logged in as a regular user.

Time and Date: all greyed out and "you are not authorized...", no prompt to enter root password.

Users and Groups: can only change Password for current user, the other Change buttons do nothing and can do nothing with any other users.

I posted more details in my original bug: Bug #598909

Michał Borsuk (michal-borsuk) wrote :

I have the same problem as David on 2008-11-28. Instead of an update, I had major, hardware-induced series of crashes. After hardware repair I saw identical problems, i.e. all D-BUS dependent applications refusing to run, all the earlier-reported symptoms, including this:

# cat etc/passwd |grep messagebus

#cat etc/group |grep messagebus

I have now hand-edited /etc/passwd, results will follow.

Kaulbach (mystic-scientist) wrote :

Natty with all updates applied as of 15 minutes ago today started generating this same error for me, may be some regression
mike@acer64:~$ grep messagebus /etc/passwd
mike@acer64:~$ grep messagebus /etc/group

Michał, Kaulbach: edit /etc/passwd and replace 108 with 107 in the messagebus line, that should fix it.

KIAaze (zohn-joidberg) wrote :
Download full text (68.4 KiB)

As a followup to Milan's request in bug 750468 :

> did the bug appear after a mere upgrade?
Yes, after a sudo apt-get upgrade and a reboot (Everything was fine before the reboot).

> Without anything weird (crash...)?
Well, I did have problems with autofs not starting as well after the upgrade. But it was fixed by adding "service autofs start" to /etc/rc.local.

> Can you list the packages that were upgraded on the other report (again :-)?
This is the part of /var/log/dpkg.log corresponding to the day I ran apt-get upgrade:
2011-03-30 09:17:49 startup archives unpack
2011-03-30 09:17:52 install ffmpeg2theora <nenio> 0.24-2build2
2011-03-30 09:17:52 status half-installed ffmpeg2theora 0.24-2build2
2011-03-30 09:17:52 status triggers-pending man-db 2.5.7-2ubuntu1
2011-03-30 09:17:52 status half-installed ffmpeg2theora 0.24-2build2
2011-03-30 09:17:54 status unpacked ffmpeg2theora 0.24-2build2
2011-03-30 09:17:54 status unpacked ffmpeg2theora 0.24-2build2
2011-03-30 09:17:54 trigproc man-db 2.5.7-2ubuntu1 2.5.7-2ubuntu1
2011-03-30 09:17:54 status half-configured man-db 2.5.7-2ubuntu1
2011-03-30 09:17:55 status installed man-db 2.5.7-2ubuntu1
2011-03-30 09:17:56 startup packages configure
2011-03-30 09:17:56 configure ffmpeg2theora 0.24-2build2 0.24-2build2
2011-03-30 09:17:56 status unpacked ffmpeg2theora 0.24-2build2
2011-03-30 09:17:56 status half-configured ffmpeg2theora 0.24-2build2
2011-03-30 09:17:56 status installed ffmpeg2theora 0.24-2build2
2011-03-30 17:10:02 startup archives unpack
2011-03-30 17:10:02 install seahorse-plugins <nenio> 2.30.0-0ubuntu2
2011-03-30 17:10:02 status half-installed seahorse-plugins 2.30.0-0ubuntu2
2011-03-30 17:10:03 status triggers-pending hicolor-icon-theme 0.11-1
2011-03-30 17:10:03 status half-installed seahorse-plugins 2.30.0-0ubuntu2
2011-03-30 17:10:03 status triggers-pending desktop-file-utils 0.16-0ubuntu2
2011-03-30 17:10:03 status half-installed seahorse-plugins 2.30.0-0ubuntu2
2011-03-30 17:10:03 status triggers-pending python-gmenu 2.30.0-0ubuntu4
2011-03-30 17:10:03 status half-installed seahorse-plugins 2.30.0-0ubuntu2
2011-03-30 17:10:03 status triggers-pending man-db 2.5.7-2ubuntu1
2011-03-30 17:10:03 status half-installed seahorse-plugins 2.30.0-0ubuntu2
2011-03-30 17:10:03 status triggers-pending shared-mime-info 0.71-1ubuntu2
2011-03-30 17:10:03 status half-installed seahorse-plugins 2.30.0-0ubuntu2
2011-03-30 17:10:05 status unpacked seahorse-plugins 2.30.0-0ubuntu2
2011-03-30 17:10:05 status unpacked seahorse-plugins 2.30.0-0ubuntu2
2011-03-30 17:10:05 trigproc hicolor-icon-theme 0.11-1 0.11-1
2011-03-30 17:10:05 status half-configured hicolor-icon-theme 0.11-1
2011-03-30 17:10:07 status installed hicolor-icon-theme 0.11-1
2011-03-30 17:10:07 trigproc desktop-file-utils 0.16-0ubuntu2 0.16-0ubuntu2
2011-03-30 17:10:07 status half-configured desktop-file-utils 0.16-0ubuntu2
2011-03-30 17:10:08 status installed desktop-file-utils 0.16-0ubuntu2
2011-03-30 17:10:08 trigproc python-gmenu 2.30.0-0ubuntu4 2.30.0-0ubuntu4
2011-03-30 17:10:08 status half-configured python-gmenu 2.30.0-0ubuntu4
2011-03-30 17:10:09 status installed python-gmenu 2.30.0-0ubuntu4
2011-03-30 17:10:09 status ...

Indeed, the log shows D-Bus was upgraded during the process, so maybe it's the install script that messes with GIDs...
upgrade libdbus-1-3 1.2.16-2ubuntu4.1 1.2.16-2ubuntu4.2
upgrade dbus 1.2.16-2ubuntu4.1 1.2.16-2ubuntu4.2
upgrade dbus-x11 1.2.16-2ubuntu4.1 1.2.16-2ubuntu4.2

Jonah Bron (jonahbron) wrote :

I found some of the related bugs when I experienced several of the mentioned symptoms (restart button doesn't work, Ubuntu Software Center doesn't work, can't open users-admin, etc). I'd just like to report that #26 fixed all the problems.

I was experiencing said problems on a fresh install of Natty. I'm not sure when the problem started, but I think it was from the beginning. If there's any more information I can provide, let me know.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments