https://bugs.kde.org/show_bug.cgi?id=361437
--- Comment #4 from James <ja...@nurealm.net> ---
Ok - finally - yes "export $(dbus-launch)" - BUT - apparently there is a
running:
/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile
--systemd-activation
that comes up with "startkde" that plasmashell cannot use. So, instead, first
kill the running dbus-daemon, then run:
export $(dbus-launch)
and then run plasmashell, and it works again.
There is some odd relationship to startplasmacompositor, in that running
plasmacompositor causes the subsequent startkde to start a dbus-daemon that
plasmashell cannot use, with "connection refused" messages in the log.
After starting and then exiting from startplasmacompositor, there are:
$ ps waxl|grep dbus-daemon
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 81 490 1 20 0 33520 2792 - Ss ? 0:04
/usr/bin/dbus-daemon --system --address=systemd: --nofork
--nopidfile --systemd-activation
0 1000 32450 32420 20 0 32916 3784 ep_pol Ss ? 0:00
/usr/bin/dbus-daemon --session --address=systemd: --nofork
--nopidfile --systemd-activation
$ ps waxl|grep 32420
4 1000 32420 1 20 0 33956 4520 ep_pol Ss ? 0:00
/usr/lib/systemd/systemd --user
5 1000 32422 32420 20 0 105164 1772 - S ? 0:00 (sd-pam)
0 1000 32450 32420 20 0 32916 3784 ep_pol Ss ? 0:00
/usr/bin/dbus-daemon --session --address=systemd: --nofork
--nopidfile --systemd-activation
0 1000 32520 32420 20 0 478900 15480 poll_s Sl ? 0:00
/usr/lib/telepathy/mission-control-5
0 1000 32529 32420 20 0 748468 32348 poll_s Sl ? 0:00
/usr/lib/gnome-online-accounts/goa-daemon
0 1000 32536 32420 20 0 270808 5572 poll_s Ssl ? 0:00
/usr/lib/gvfs/gvfsd
0 1000 32541 32420 20 0 338908 7328 futex_ Sl ? 0:00
/usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
0 1000 32550 32420 20 0 280960 8292 poll_s Sl ? 0:00
/usr/lib/gnome-online-accounts/goa-identity-service
0 1000 32633 32420 9 -11 446820 12624 poll_s S<sl ? 0:04
/usr/bin/pulseaudio --daemonize=no
0 1000 32637 32420 20 0 60676 5132 poll_s S ? 0:00
/usr/lib/GConf/gconfd-2
and then, because I've discovered that this second dbus-daemon is causing
problems, suppose:
$ kill 32450
$ ps lU 1000
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 1000 325 32430 20 0 34440 2980 - R+ tty1 0:00 ps lU 1000
4 1000 32420 1 20 0 34048 4532 ep_pol Ss ? 0:00
/usr/lib/systemd/systemd --user
5 1000 32422 32420 20 0 105164 1772 - S ? 0:00 (sd-pam)
4 1000 32430 32413 20 0 16696 4732 wait Ss tty1 0:00 -bash
0 1000 32633 32420 9 -11 446820 12624 poll_s S<sl ? 0:05
/usr/bin/pulseaudio --daemonize=no
0 1000 32635 32633 20 0 82000 5692 poll_s S ? 0:00
/usr/lib/pulse/gconf-helper
Then after startkde, there is:
$ ps waxl|grep dbus-daemon
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 1000 374 32420 20 0 32836 3672 ep_pol Ss ? 0:00
/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile
--systemd-activation
4 81 490 1 20 0 33520 2792 - Ss ? 0:04
/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile
--systemd-activation
...
So now, two dbus-daemon processes have been started, one by the PID 1 "systemd
--system", and one by my login "systemd --user".
Plasmashell will not run properly. Perhaps it tries to use the "wrong"
dbus-daemon?
I can kill "my" PID 374 dbus-daemon, and plasmashell still does not run
properly.
So then, "export dbus-launch --exit-with-session", which has
+ export
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-kW9FbJrDeq,guid=c39cc3939fe85074db1f6c09570d400c
DBUS_SESSION_BUS_PID=1195
DBUS_SESSION_BUS_WINDOWID=10485761
+
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-kW9FbJrDeq,guid=c39cc3939fe85074db1f6c09570d400c
+ DBUS_SESSION_BUS_PID=1195
+ DBUS_SESSION_BUS_WINDOWID=10485761
and there is a new dbus-daemon session:
1 1000 1195 1 20 0 32576 324 ep_pol Ss ? 0:00
/usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
And plasmashell now runs normally.
Does that make any sense, why plasmashell will not run with the first
dbus-daemon, started with "startkde"?
And then, what is the effect being caused by previously running
startplasmacompositor?
If I start over, after killing all user processes, then log out and log in,
what is the dbus-daemon state when startkde comes up before
startplasmacompositor?
After login:
$ ps lU 1000
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 1000 1991 1 20 0 33956 4476 ep_pol Ss ? 0:00
/usr/lib/systemd/systemd --user
5 1000 1995 1991 20 0 105496 2016 - S ? 0:00 (sd-pam)
4 1000 2000 1983 20 0 16696 4892 wait Ss tty1 0:00 -bash
0 1000 2007 2000 20 0 34440 3148 - R+ tty1 0:00 ps lU 1000
After startkde
$ ps waxl|grep dbus-daemon
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 81 490 1 20 0 33520 2792 - Ss ? 0:04
/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile
--systemd-activation
0 1000 2044 1991 20 0 32836 3812 ep_pol Ss ? 0:00
/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile
--systemd-activation
0 1000 2298 2259 20 0 10760 2168 pipe_w S+ pts/2 0:00 grep
dbus-daemon
Comparing the form of the commands, the "not working with plasmashell" PID 374,
and the "works with plasmashell" PID 2044, they are exactly the same. But the
first cannot be used by plasmashell, and the second can.
When plasmashell fails, in the log there are things like:
Apr 12 10:39:42 topaz kglobalaccel5[31802]: Failed to create display
(Connection refused)
Apr 12 10:39:43 topaz kscreen_backend_launcher[31807]: Failed to create display
(Connection refused)
and "strace plasmashell" has:
write(2, "kscreen: Failed to request backe"..., 132kscreen: Failed to request
backend: "org.freedesktop.DBus.Error.Spawn.ChildExited" : "Process
org.kde.KScreen exited with status 1"
The log message is not very useful, because it fails to state "what connection"
is being refused. That is a bug on its own. But is the connection being
referenced to the dbus-daemon? And then, why or how would the connection be
refused?
--
You are receiving this mail because:
You are watching all bug changes.
