[Pkg-xfce-devel] Bug#829557: firefox: error box at start-up / D-BUS related issue
- Subject: [Pkg-xfce-devel] Bug#829557: firefox: error box at start-up / D-BUS related issue
- From: smcv at debian.org (Simon McVittie)
- Date: Mon, 4 Jul 2016 17:48:57 +0100
- Message-id: <[🔎] 20160704164857.GA17385@perpetual.pseudorandom.co.uk>
- In-reply-to: <20160704104341.GC11030@cventin.lip.ens-lyon.fr>
- References: <20160704092628.GA10429@cventin.lip.ens-lyon.fr> <20160704104341.GC11030@cventin.lip.ens-lyon.fr>
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'), 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"
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.