You are not logged in.
I have been facing a weird issue since the beginning of December: Pressing some keys, like Shift+3 (which should generate · aka. U+00B7 MIDDLE DOT) closes all* GUI programs.
More exactly, everything is closed on GNOME, up to Xorg itself. On Xfce, xfce4-session, xfdesktop, gmain and gdbus remain active (not that it is too useful). chromium also seems to survive.
I have played the usual steps of downgrading selected packages, then everything upgraded at the time I thought it appeared, attempting to find the culprit, but I have been unable to.
The only thing logged at journalctl when this happens are from org.gtk.vfs.Daemon and polkitd, due to bus disconnections (there are a few previous nouveau bus MMIO write FAULT messages, but those seem unrelated).
Interestingly, if running twm, the issue doesn't manifest, which suggests it's located at a relatively high level library.
I also attempted to run ibus on twm thinking it might be a problem with the input method (despite not being updated from August), but didn't manage to make it break, either.
Does anyone have any tip on how to find out what is choking on this and taking down the whole DE?
Offline
So it only happens with ibus and Gnome? Or some programs within an Xfce session?
Not a Pacman issue, moving to Apps & DEs...
Offline
It happens with both Gnome and Xfce (although a few Xfce programs survive). TWN is not affected at all.
Thus, it seems to be some kind of library updated recently that is shared by both DEs. ibus looked like a good candidate, but seems unrelated.
Offline
Take it out of the mix and see what happens...
Offline
That's a good point. It still fails after uninstalling ibus, so it must be something else in the stack.
I am open for ideas ![]()
Offline
Nothing in the Xorg log?
Offline
No, nothing interesting there.
Offline
I have advanced a bit finding out the cause. The common service is dbus.
Originally, there are two dbus instances launched by systemd (the system one owned by 'dbus' and a user one). When launching the DE another dbus-launch is called behind the scenes, which forks another dbus-daemon
/usr/bin/dbus-launch --sh-syntax --exit-with-session xfce4-session
/usr/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
plus sometimes there's a fourth dbus-daemon related to accessibility.conf
/usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
when pressing those keys, dbus-launch reads from stdin (which is /dev/tty1), is unable to and finishes with his children dbus. The lack of dbus is then what brings down the other apps.
I don't know what makes stdin selectable, or why it attempts to read from there, though:
13605 select(1, [0], NULL, [0], NULL <unfinished ...>
(dbus-daemon work)
13605 <... select resumed> ) = 1 (in [0])
13605 read(0, 0x7ffcc859db80, 512) = -1 EIO (Input/output error)
13605 write(2, "dbus-launch: error reading from stdin: Input/output error\n", 58) = 58
13605 close(0) = 0
13605 close(1) = 0
13605 close(2) = 0
13605 kill(13606, SIGTERM) = 0
13606 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=13605, si_uid=1000} ---
13605 nanosleep({3, 0}, <unfinished ...>
13605 <... nanosleep resumed> 0x7ffcc859d830) = 0
13605 kill(13606, SIGKILL) = -1 ESRCH (No such process)
13605 exit_group(0) = ?
13605 +++ exited with 0 +++As an ugly workaround, sending SIGSTOP to dbus-launch avoids the bug from appearing.
Last edited by linas (2016-12-13 01:36:10)
Offline
When launching the DE another dbus-launch is called behind the scenes, which forks another dbus-daemon
This should not happen. Find out why it is and stop it.
Offline
This should not happen. Find out why it is and stop it.
Well, xfce4-session is launching it.
I tried to set DBUS_SESSION_BUS_ADDRESS=autolaunch on .xinitrc to help it find the existing one by itself, but it was actually worse.
I will do DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$(id -u)/bus", but systemd should have made it available (or dbus-launch have performed a no-op).
There seems a bug in dbus-launch nevertheless. It shouldn't be dying, even if duplicated. ![]()
Last edited by linas (2016-12-13 22:14:17)
Offline
It dies because it no longer has X/autolaunch support.
DBUS_SESSION_BUS_ADDRESS is set when the socket is started. See /usr/lib/systemd/user/dbus.socket
Last edited by Scimmia (2016-12-13 13:56:50)
Offline
It dies because it no longer has X/autolaunch support.
It does have autolaunch. Actually, it works normally, unless some of the magic key combinations are pressed.
DBUS_SESSION_BUS_ADDRESS is set when the socket is started. See /usr/lib/systemd/user/dbus.socket
Interesting. /usr/lib/systemd/user/dbus.socket does contain
ExecStartPost=-/usr/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=%t/busbut user shells don't have DBUS_SESSION_BUS_ADDRESS in their environment.
Offline
Then either something is unsetting it, or something is wrong with the user's systemd session.
Offline