https://bugs.kde.org/show_bug.cgi?id=361437
Bug ID: 361437
Summary: startkde -> startplasmacompositor -> startkde =
"blackscreen"
Product: plasmashell
Version: 5.6.1
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: crash
Priority: NOR
Component: general
Assignee: k...@davidedmundson.co.uk
Reporter: ja...@nurealm.net
CC: bhus...@gmail.com, plasma-b...@kde.org
Arch Linux
plasma-workspace 5.6.1-1
systemd 229-3
AMD/ATI Redwood PRO Radeon HD 5570 with triple display
Intel Core2 Quad CPU Q6600
I'm not sure where this report should go. I am submitting it here only because
plasma-workspace owns startplasmacompositor. I seem to have found some kind of
workaround.
Running startplasmacompositor just once will cause a previously working X11 KDE
to fail repeatedly thereafter. "Replacing" the socket /var/run/user/1000/bus
seems to restore normal X11 KDE functionality. This is a problem because
anyone who just "dabbles" with Wayland KDE can make their X11 KDE unusable.
Rebooting the machine is an extreme but effective method of "replacing" the
"bus" socket.
Problem:
1) run startx with startkde - it starts normally, with the splashscreen
disappearing quickly.
2) exit
3) run startplasmacompositor - it starts normally, but the splashscreen hangs
for about 25 seconds before fading.
4) exit
5) run startx with startkde - it starts with a splashscreen which hangs for
about 25 seconds.
Then, fade to "blackscreen".
The mouse works, X applications can be run, but the desktop is unresponsive.
After trying things like deleting ~/.cache and ~/.kde4, which made no
difference, I tried:
$ rm -R /var/run/user/1000/
which allowed startkde to produce a working desktop.
It make no difference to delete the files like
/var/run/user/1000/klauncherXM6740.1.slave-socket
And it makes no difference to kill the process like
/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile
--systemd-activation
Upgrading from 5.6.0 to 5.6.1 makes no difference.
After some trial and error, I found it necessary to restart the process
/usr/lib/systemd/systemd --user
It is not enough to log out, which leaves this process running, and it is not
effective to kill it and try to run it manually, which gives permission errors.
So, it is necessary to find the process with something like "$ ps lU 1000",
then "$ kill <pid>", then log out, then log back in. After all of that, startx
with startkde will function again.
Rebooting the machine will have an equivalent effect, but that is an extreme
remedy.
It seems odd to me that logging out will not automatically kill the "systemd
--user" process, in particular, when there are no other logins on other virtual
terminals, but I suppose that that is a systemd thing.
I notice that "systemd --user" creates the file "/var/run/user/1000/bus", so
this may be a dbus issue.
But then, killling "systemd --user" also - finally - kills other "lurking"
background user processes. Still, comparing the process list after exiting a
working startkde session and after a startplasmacompositor session, the only
change is a new process id for
/usr/bin/pulseaudio --daemonize=no
and
/usr/lib/pulse/gconf-helper
Killing these processes before startkde make no difference. So I would expect
that this is a dbus related issue.
Reproducible: Always
--
You are receiving this mail because:
You are watching all bug changes.
