GNOME Bugzilla – Bug 676167
gdbus doesn't autostart session bus and outputs warnings when SIGCHLD is set to be ignored by program
Last modified: 2012-05-17 17:58:48 UTC
Some people reported that error messages like the one below occur when launching emacs, while there's no session bus: ============================ (emacs:30395): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action. GConf Error: Failed to contact configuration server; the most common cause is a missing or misconfigured D-Bus session bus daemon. See http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to get connection to session: Abnormal program termination spawning command line `dbus-launch --autolaunch=f2e42fa76d380fe9ded6ae94493eec15 --binary-syntax --close-stderr': ) (emacs:30395): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action. ============================ The "Abnormal program termination" message indicates that this is actually happening because of the g_spawn_command_line_sync() call in get_session_address_dbus_launch() (gdbusaddress.c). To me, the issue is that the app is likely setting SIGCHLD to SIG_IGN, which breaks the internal call to g_spawn_command_line_sync() in gdbus. Note that I cannot reproduce the issue anymore in openSUSE 12.1 (I can see it in 11.4). That being said, it's more likely because of a change in emacs, or gconf, than because of a fix in gdbus: I don't see any relevant change to the code spawning dbus-launch since glib 2.28.
Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=654027 openSUSE bug: https://bugzilla.novell.com/show_bug.cgi?id=680106
Ahem, g_bus_get_sync() or whatever is simply returning NULL as it should when we can't connect to the session bus. It's the application that is failing to deal with it. Or in this case, another library, maybe GConf? FYI, this is a well-known problem - the session-bus does not work when running as another user. There's a fd.o bug about it but I can't find it right now. Closing as NOTGNOME.
If the issue is just about the error message, we could potentially remove it by just not reading the exit status, and instead erroring out if we fail to parse the launch address. This is a multiple-middleware problem though. The way Emacs runs subprocesses (and has its own mainloop, etc.) is completely incompatible with GLib (which GTK+ depends on). There's just no good solution other than only using one way to spawn processes, at least until we have kernel facilities for child status notification that aren't process global (as SIGCHLD is).
(In reply to comment #0) > To me, the issue is that the app is likely setting SIGCHLD to SIG_IGN, which > breaks the internal call to g_spawn_command_line_sync() in gdbus. Btw, forgot to reply to that ... yeah.. if the app is messing around with signal handlers like that, then I think it's fair to argue that all bets are off.
Sorry, I wasn't clear: I'm not saying we should make this work fine. What's an issue here is the warning which makes it look like the app is doing something really wrong, but the app has no way to know that gio will call g_spawn_command_line_sync(). And the scary g_spawn_sync() warning makes it look like the app is doing things wrong, while it's really impossible for the app to know that it shouldn't change the SIGCHLD handler.
(In reply to comment #5) > Sorry, I wasn't clear: I'm not saying we should make this work fine. > > What's an issue here is the warning which makes it look like the app is doing > something really wrong, but the app has no way to know that gio will call > g_spawn_command_line_sync(). Well, I don't think apps can assume anything about what GLib does internally ... for example, we may also create our own threads in the background without the app knowing. And tons of other things that is likely to raise at least _some_ eyebrows. Of course, apps may make _some_ assumptions about what the library does ... for example, that we don't crash, that we don't write to stdout/stderr unless requested) and so on. As another example, we _do_ raise SIGTERM (and mention this on stdout) when the message bus disconnects us, but again, that's intentional and the app can opt out of this behavior. Another point is that if an app is using the library incorrectly (e.g. when g_return_if_fail() is hit), pretty much all bets are off - most of the time things work but we really don't guarantee anything ("undefined state"). Whether we should document what kind of expectations apps should have is another question. I think it would probably be worthwhile, at least so we can point developers to it. Then again, a lot of it is sorta obvious but as always, the devil is in the details. > And the scary g_spawn_sync() warning makes it look > like the app is doing things wrong, while it's really impossible for the app to > know that it shouldn't change the SIGCHLD handler.
Created attachment 214185 [details] [review] gio: Avoid warning from g_bus_get_* if application has set SIGCHLD to SIG_IGN
(In reply to comment #6) > (In reply to comment #5) > > Sorry, I wasn't clear: I'm not saying we should make this work fine. > > > > What's an issue here is the warning which makes it look like the app is doing > > something really wrong, but the app has no way to know that gio will call > > g_spawn_command_line_sync(). > > Well, I don't think apps can assume anything about what GLib does internally You're missing my point, really. The warning reads like this: "This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action." This warning leads you to think there is a bug in the app because it's not calling g_spawn_sync() correctly. But it's gio that is calling g_spawn_sync(), and the app writers can't know that.
(In reply to comment #7) > Created an attachment (id=214185) [details] [review] > gio: Avoid warning from g_bus_get_* if application has set SIGCHLD to SIG_IGN I guess we can do that - but it sets a dangerous precedent insofar that any other part of the library will need to do the same checks. But I guess that's fine, sure, please commit. (And we really want a better g_spawn*() function/object anyway, but that's a separate discussion.)
(In reply to comment #9) > (In reply to comment #7) > > Created an attachment (id=214185) [details] [review] [details] [review] > > gio: Avoid warning from g_bus_get_* if application has set SIGCHLD to SIG_IGN > > I guess we can do that - but it sets a dangerous precedent insofar that any > other part of the library will need to do the same checks. But I guess that's > fine, sure, please commit. It's ugly and gross for sure. Actually, this is one of those things we should fix multiple ways: If we put this in GLib - Vincent, can you *PLEASE* change the OpenSUSE login system fixed so that dbus-daemon is spawned even for people who assemble a pile of RPMs instead of using a coherent system like GNOME? For example, in Fedora: http://pkgs.fedoraproject.org/gitweb/?p=dbus.git;a=blob;f=00-start-message-bus.sh;h=582b424386e7b2b2165deb483f8e6c468f1cd10e;hb=HEAD I'm not proud of this hack, but it works. Also, GDM should also be patched to spawn a dbus-daemon by default if it hasn't been already. > (And we really want a better g_spawn*() function/object anyway, but that's a > separate discussion.) See bug 672102
would it make sense for g_spawn_sync() to call pthread_sigmask() to block SIGCHLD until it returns?
(In reply to comment #10) > > If we put this in GLib - Vincent, can you *PLEASE* change the OpenSUSE login > system fixed so that dbus-daemon is spawned even for people who assemble a pile > of RPMs instead of using a coherent system like GNOME? See also bug 546863 for how we launch the session bus in GNOME (if something external i.e. X init scripts or GDM hasn't already done it).
(In reply to comment #11) > would it make sense for g_spawn_sync() to call pthread_sigmask() to block > SIGCHLD until it returns? You mean "unblock"? Hmm....I think the issue here is that if we do that, we'd potentially be getting SIGCHLD for pids *other* than the ones we spawned. Emacs is blocking SIGCHLD to avoid having to call waitpid() at all. But I think we'd start accumulating zombies unless we call waitpid() on them; but we can't do that reliably. If we called wait() to collect any pid, then we'd potentially be breaking any users of G_SPAWN_DO_NOT_REAP in our process.
oh, ugh. I didn't realize that happened when you ignored SIGCHLD. I was thinking the problem was that emacs was reaping the child before we could get to it.