Bug 24821 - errno is lost if activation fork() or exec() fails
Summary: errno is lost if activation fork() or exec() fails
Status: RESOLVED FIXED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: 1.5
Hardware: All All
: medium normal
Assignee: Simon McVittie
QA Contact: D-Bus Maintainers
URL:
Whiteboard: review?
Keywords: patch
: 85171 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-10-30 13:54 UTC by Carl Worth
Modified: 2014-10-29 16:23 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dbus-spawn: do not forget the exec() errno when the grandchild exits (2.49 KB, patch)
2014-09-11 10:01 UTC, Simon McVittie
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Carl Worth 2009-10-30 13:54:13 UTC
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).
Comment 1 Simon McVittie 2011-07-21 05:44:44 UTC
(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...
Comment 2 Chengwei Yang 2013-12-07 12:20:53 UTC
(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)
Comment 3 Simon McVittie 2014-09-11 09:47:05 UTC
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.
Comment 4 Simon McVittie 2014-09-11 10:01:26 UTC
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 5 Simon McVittie 2014-10-16 18:29:34 UTC
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.
Comment 6 Ross Lagerwall 2014-10-21 19:20:16 UTC
*** Bug 85171 has been marked as a duplicate of this bug. ***
Comment 7 Simon McVittie 2014-10-29 16:23:27 UTC
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.