A recent "event" on my machine caused the ownership of a few files to be flipped fairly randomly. One file that happened to be hit was: /usr/lib/dbus-1.0/dbus-daemon-launch-helper It saw its group change from "messagebus" to a random different group. This meant that dbus could not launch any helpers which led to random and hard-to-diagnose misbehavior[*] on the system. I would have loved it if dbus would have made some obvious noise in my syslog about the problem, but it was silent as far as I could tell. I ended up having to do more strace-ing and reverse-engineering than I really felt like doing. Thanks, -Carl [*] Specifically, network-manager failed to launch the nm-systems-settings daemon, which led to it being unable to ask for the current hostname, which in turn caused it to set my hostname to "localhost.localdomain" every time a device connected. All of this combined meant that if I plugged in a network cable, then suddenly I couldn't talk to my X server anymore, (since the hostname had change the Xauthority tokens were no longer valid).
(In reply to comment #0) > I would have loved it if dbus would have made some obvious noise in my > syslog about the problem Colin added system-bus activation logging to syslog for Bug #35705, which was released in 1.4.10. Here's what I get for a similar failure mode: Jul 21 13:31:38 reptile dbus[1570]: [system] Activated service 'org.freedesktop.SystemToolsBackends.SMBConfig' failed: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success For some reason the errno for execve() failing (which should be EACCESS) is apparently getting lost somewhere, but other than that, it works...
(In reply to comment #1) > (In reply to comment #0) > > I would have loved it if dbus would have made some obvious noise in my > > syslog about the problem > > Colin added system-bus activation logging to syslog for Bug #35705, which > was released in 1.4.10. Here's what I get for a similar failure mode: > > Jul 21 13:31:38 reptile dbus[1570]: [system] Activated service > 'org.freedesktop.SystemToolsBackends.SMBConfig' failed: Failed to execute > program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success > > For some reason the errno for execve() failing (which should be EACCESS) is > apparently getting lost somewhere, but other than that, it works... Still a bug, the errno (EACCES) was recorded, but then overwritten. Related logs like below. [dbus-spawn.c(1000):do_exec] Child process has PID 15253 15230: [dbus-spawn.c(560):handle_babysitter_socket] Reading data from babysitter 15230: [dbus-spawn.c(496):read_data] recorded grandchild pid 15253 15230: [dbus-spawn.c(576):handle_error_pipe] Reading data from child error 15230: [dbus-spawn.c(471):read_data] recorded exec errnum 13 15230: [dbus-spawn.c(532):close_error_pipe_from_child] Closing child error 15230: [dbus-watch.c(418):_dbus_watch_list_remove_watch] Removing watch on fd 10 15230: [dbus-watch.c(629):dbus_watch_set_data] Setting watch fd -1 data to data = (nil) function = (nil) from data = (nil) function = (nil) 15252: [dbus-spawn.c(1069):check_babysit_events] reaped child pid 15253 15230: [dbus-spawn.c(560):handle_babysitter_socket] Reading data from babysitter 15230: [dbus-spawn.c(459):read_data] recorded child status exited = 1 signaled = 0 exitstatus = 1 termsig = 0 15230: [dbus-spawn.c(560):handle_babysitter_socket] Reading data from babysitter 15230: [dbus-spawn.c(511):close_socket_to_babysitter] Closing babysitter 15230: [dbus-watch.c(418):_dbus_watch_list_remove_watch] Removing watch on fd 12 15230: [dbus-watch.c(629):dbus_watch_set_data] Setting watch fd -1 data to data = (nil) function = (nil) from data = (nil) function = (nil)
OK, so the bug as reported has been fixed: failure to start dbus-daemon-launch-helper is logged. The remaining bug is errno being lost, and I can see why now.
Created attachment 106123 [details] [review] dbus-spawn: do not forget the exec() errno when the grandchild exits As is already noted in a comment in _dbus_babysitter_set_child_exit_error(), if the grandchild fails to exec() the desired process, we get both CHILD_EXEC_FAILED (with an errno) and CHILD_EXITED (with a status), and we want to report the former, since it is more informative. However, clearing sitter->errnum meant we lose the errno value. --- I haven't tested this in a live system yet, but I believe it should address the missing errno.
Comment on attachment 106123 [details] [review] dbus-spawn: do not forget the exec() errno when the grandchild exits I've tested this with a dbus-daemon-launch-helper chmod'd to be non-executable, and it does work as intended.
*** Bug 85171 has been marked as a duplicate of this bug. ***
Fixed in git for 1.9.2
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.