[Bug 232364] Re: dbus-launch hangs at session start waiting on socket output in libxcb

[Bug Watch Updater]

** Changed in: dbus
   Importance: Unknown => High

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/232364

Title:
  dbus-launch hangs at session start waiting on socket output in libxcb

Status in D-Bus:
  Fix Released
Status in libxcb:
  Won't Fix
Status in “dbus” package in Ubuntu:
  Invalid
Status in “libx11” package in Ubuntu:
  Invalid
Status in “libxcb” package in Ubuntu:
  Invalid
Status in “linux” package in Ubuntu:
  Invalid
Status in “xfce4-session” package in Ubuntu:
  Invalid
Status in “xfce4-utils” package in Ubuntu:
  Fix Released
Status in “dbus” source package in Hardy:
  Invalid
Status in “libx11” source package in Hardy:
  Invalid
Status in “libxcb” source package in Hardy:
  Won't Fix
Status in “linux” source package in Hardy:
  Invalid
Status in “xfce4-session” source package in Hardy:
  Invalid
Status in “xfce4-utils” source package in Hardy:
  Fix Released

Bug description:
  Ubuntu 8.04

  It is not reproducible (I don't know when it happens). But it happens often enough.
  dbus-launch can't be killed with SIGTERM (nor it dies when X session is killed, nor after
  Ctrl-Alt-Backspace) when it happens and seem to hang on some synchronization
  routine IIRC from the last time I tried to debug the issue.

  I installed dbgsyms this times and will try to debug dbus-launch next
  time it happens.

  BTW, isn't dbus-launch supposed to exit after dbus-daemon is started
  (for the user session)?

  [Workaround]
  kill the "dbus-launch --sh-syntax --exit-with-session" with signal 9.  This allows the login process to finish.

  Or else just reboot several times.  It seems to be a race condition
  and some people see it affecting login only intermittently.

  [Background]
  Due to various problems in the venerable xlib, Xorg upstream created the "X C-Language Bindings" (XCB).  Debian and Ubuntu switched to an xcb-enabled libx11 in the Hardy timeframe.  Prior to this, a known issue with Java (bug LP: #86103) prevented us from shipping XCB in Xorg.  A patch to enable 'sloppy locking' solved the java issue and allowed Ubuntu to follow Debian in shipping with this enabled in Hardy.

  [Next Steps]
  XCB is a new technology and as such is a prominent suspect, however we've not yet proven it as the culprit beyond a shadow of doubt.  A non-XCB libx11 package has been prepared for testing, and so the first step is to demonstrate conclusively that the issue is completely absent with that package.

  Since Hardy is an LTS, it is important that we have this issue fixed,
  however disabling XCB in libx11 maybe too short sighted; doing so
  could just unpredictably generate regressions in other packages, and
  it really only sweeps the problem under the rug for us to re-encounter
  later.  Much better would be to work with upstream to get this issue
  resolved definitively.  Going forward, as more X client applications
  start depending on XCB, having it available in Hardy will be of
  obvious benefit.  But if we can show that a non-XCB libx11 resolves
  the issue, and no other viable workaround or solution comes to light,
  we may have no choice than to fall back to that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/232364/+subscriptions