On Mon, 04 Jul 2016 at 12:43:41 +0200, Vincent Lefevre wrote: > $ ls -a /tmp/*dbus* > zsh: no match
This is normal. The session dbus-daemon on Linux uses abstract Unix sockets (AF_UNIX sockets with sockaddr_un.sun_path[0] == '\0'), which are not present in the filesystem at all: their names (the rest of sockaddr_un.sun_path) are opaque and meaningless. Confusingly, the value dbus-daemon chooses for the rest of sun_path looks like a pathname, because it is chosen by code that transparently uses either an abstract Unix socket or a filesystem-backed Unix socket, whichever the kernel supports. > The dbus related processes: > > UID PID PPID C STIME TTY TIME CMD > message+ 879 1 0 Jul01 ? 00:00:02 /usr/bin/dbus-daemon --system > --address=systemd: --nofork --nopidfile --systemd-activation This is the system bus and is not relevant here: your problem is with the session bus. > lightdm 3597 1 0 Jul01 ? 00:00:00 dbus-launch > --autolaunch=dcbbbc34fb4249e4864ba967a9d3b514 --binary-syntax --close-stderr > lightdm 3598 1 0 Jul01 ? 00:00:00 /usr/bin/dbus-daemon --fork > --print-pid 5 --print-address 7 --session This is the lightdm user's session bus, started as a side-effect of something in the lightdm greeter using D-Bus. It is not running under your uid and hopefully should not be relevant here. > vlefevre 9702 1 0 11:20 ? 00:00:00 /usr/bin/dbus-launch > --exit-with-session --sh-syntax > vlefevre 30347 1 0 Jul03 pts/0 00:00:00 dbus-launch --autolaunch > dcbbbc34fb4249e4864ba967a9d3b514 --binary-syntax --close-stderr > vlefevre 30348 1 0 Jul03 ? 00:00:00 /usr/bin/dbus-daemon --fork > --print-pid 5 --print-address 7 --session These indicate that something in your session, whose controlling terminal is /dev/pts/0 (?!), used D-Bus and started a dbus-daemon as a side-effect ("autolaunching", pid 30347/30348); and in addition, dbus-launch was run during your X11 session startup (pid 9702; most likely by /etc/X11/Xsession.d/75dbus_dbus-launch). From the fact that pid 9702 does not have a dbus-daemon child, I think we can infer that it has latched onto some other dbus-daemon - hopefully 30348 - advertised in a hidden X11 window by some other dbus-launch - hopefully 30347. What is /dev/pts/0? Is it a terminal or something? It might be enlightening to see the result of env | grep '^DBUS' inside the session that is failing (for example from an xterm); if you're lucky, there might be a process ID (I can't remember whether that gets exported or not). It might also be useful to attach a gdb to each dbus-launch process (with dbus-1-dbg installed), go to the frame that is in main() and do "p bus_pid", "p bus_address", "p address", "p wid" before detaching. For a session startup less closely resembling a Rube Goldberg machine, consider installing dbus-user-session. This makes a semantic change to the meaning of "D-Bus session", which is why it is not the default: it is meant to be "opt-in". See its Description for details. At some point I'm probably going to do a mass-bug-filing for misuses of dbus-launch, with a mini-policy on what desktop components should do about D-Bus, and a side goal of having all desktop environments that currently depend on dbus-x11 switch to "dbus-x11 | dbus-user-session" (or even "dbus-user-session | dbus-x11") so that removing dbus-x11 altogether becomes feasible. This is blocking on me writing up that mini-policy, without which a mass-bug-filing would be unconstructive. Regards, S