GNOME Bugzilla – Bug 645593
main: Use --replace semantics for org.gnome.Shell DBus name
Last modified: 2011-03-23 21:47:22 UTC
Previously (because I suck) we were ignoring the return value of RequestName, and so we'd totally ignore the fact that we failed to acquire the DBus name. Make this consistent by using meta_get_replace_current_wm() and if we're in --replace, actually replace immediately.
Created attachment 184151 [details] [review] main: Use --replace semantics for org.gnome.Shell DBus name
The backstory on this is that if we skip this, then we'll end up connecting to XSMP, which when we then later exit, makes gnome-session think we crashed. If we simply exit(), gnome-session will ignore this.
Comment on attachment 184151 [details] [review] main: Use --replace semantics for org.gnome.Shell DBus name looks right to me. blah blah freeze break request
Attachment 184151 [details] pushed as c91b716 - main: Use --replace semantics for org.gnome.Shell DBus name
Timeline: 1) gnome-session starts 2) gnome-session reads gnome-shell.desktop as required component, execs /usr/bin/gnome-shell 3) gnome-session notes X-GNOME-Autorestart key 4) gnome-shell grabs org.gnome.Shell name (but does *not* check if anothe process has this) 5) gnome-shell connects to XSMP We have a running gnome-shell process, OK. Next, suppose a developer does ./gnome-shell --replace (without this patch). We have *two* processes now. Call "gnome-shell-orig" and "gnome-shell-replacing". For gnome-shell-replacing, repeat steps 1-5, now: 6) gnome-shell-replacing claims the WM selection 7) gnome-shell-orig loses the WM selection and exit(1) 8) gnome-session gets XSMP disconnection from gnome-shell-orig 9) gnome-session attempts to auto-respawn gnome-shell-orig, call this gnome-shell-respawn1 10) gnome-shell-respawn1 runs through steps 1-5, but since it was *not* invoked with --replace, it bombs on the WM selection. A **key** point here is that because of the bug, gnome-shell-respawn1 got as far as making a new XSMP connection. 11) gnome-session attempts another respawn, which fails. Two consecutive failures trigger the fail whale. The basic idea with the way things currently are is that re-executed binaries treat the state where another process has claimed their DBus name as "OK". This is how gnome-panel works.
To be clear, if gnome-session doesn't see a new XSMP connection, it's fine. It doesn't care about whether its child exits (or with which code). Yes, this is broken, but it's behavior we need to rely on until gnome-session becomes sane.
Created attachment 184175 [details] [review] main: Allow replacement of org.gnome.Shell name This was an oversight in the previous commit; if we don't do this, then we just can't --replace.
Review of attachment 184175 [details] [review]: This was the only thing I noticed in review, and I checked with Colin that he's tested it in a range of cases. Since this doesn't change the overall scope of the changes since the previous release-team signoff, I'm considering this doesn't need a new sign-off. I'd appreciate a new bug being filed for a correct fix for 3.2. We're basically exploiting a bug in gnome-session - if it tries to run gnome-shell and it exits with an failure exit status but not a signal (this also is what happens when main.js throws an exception; one of the most common "broken" modes of gnome-shell), then it considers no error to have occurred.
Attachment 184175 [details] pushed as 090d545 - main: Allow replacement of org.gnome.Shell name