Stuart Henderson <s...@spacehopper.org> writes: > The last I remember from the discussion is that it sometimes hangs at shutdown > unless a system dbus is running,
I don't think it was a system dbus problem, rather a user session dbus problem. > but there's no documentation to tell people to do this I'm currently writing a README, but I still don't really know what should its content be: every time I try to reproduce this problem, I fail. What I have observed on the gtk3 flavor (using emacs -q): - with my personal .xinitrc that does nothing related to dbus, Emacs (or rather the glib/gtk3 backend) automatically spawns a dbus session and seems to use it. jca 21115 0.0 0.1 1052 1548 ?? Ss 2:03PM 0:00.02 /usr/local/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session jca 15409 0.0 0.2 864 1656 ?? S 2:03PM 0:00.02 /usr/local/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3 jca 6960 0.0 0.1 424 1452 p9 S+ 2:03PM 0:00.01 dbus-launch --autolaunch ff6ac36d53058081989a13de508345c5 --binary-syntax --close-stderr emacs spawns /usr/local/bin/dbus-launch dbus-launch spawns /usr/local/bin/dbus-daemon dbus-daemon spawns /usr/local/libexec/at-spi-bus-launcher at-spi-bus-launcher spawns /usr/local/bin/dbus-daemon Killing the dbus session results in Emacs exiting with this error message: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. But I couldn't trigger freezing at exit time. - with the stock /etc/X11/xdm/Xsession and fvwm: At session start: jca 25633 0.0 0.1 428 1480 ?? S 2:11PM 0:00.00 dbus-launch --sh-syntax --exit-with-session jca 3625 0.0 0.1 660 916 ?? Ss 2:11PM 0:00.00 /usr/local/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session After emacs -q: jca 25633 0.0 0.1 428 1480 ?? I 2:11PM 0:00.00 dbus-launch --sh-syntax --exit-with-session jca 3625 0.0 0.2 896 1568 ?? Is 2:11PM 0:00.05 /usr/local/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session jca 18004 0.0 0.2 832 1640 ?? I 2:12PM 0:00.04 /usr/local/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3 After pkill dbus, Emacs prints errors (related to committing changes to dconf) but still "works OK" and exits without hanging. After Emacs has been exited, it tries to connect to the previous dbus socket since it is still defined in its environment, but stops bothering after a few failures. There again, I couldn't trigger freezing at exit. So, what I'm going to put in this README is: --8<-- There is some random bug in graphical Emacs sessions (freeze/crash at exit time) that some do experience and some don't. It seems that starting a global dbus user session solves the problem; if you use your own .xinitrc / .xsession, please have a look at /etc/X11/xinit/xinitrc. -->8-- I don't know if the wording looks clear enough or those hints are optimal. > (and I'm not aware of other software behaving like this so it's > a bit unexpected..) Wha, is it really the first Heisenbug ever? :) I've been unable to reproduce it on -current i386, even without a dbus user session running. As experienced by others in the 24.1 and 24.2 threads, either the changes made to the default xinitrc/xsession or using a session manager that automatically starts dbus should fix the bug. http://marc.info/?l=openbsd-ports&m=134054137119141&w=2 The problem is that some people don't run a session manager / desktop environment that might spawn dbus, and forget to do so in their own ~/.xinitrc. I think the dbus port README should come back. New port attached. I've changed the ${OSREV}/--build=${GCCARCH} stuff so that we don't include ${OSREV} in the PLIST, but I don't really know about the possible bad consequences. Adding myself as maintainer. [...] -- Jérémie Courrèges-Anglas GPG Fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
emacs24.tgz
Description: Binary data
