plasma-workspace 5.6.1-1

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.

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.
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 to kde-unstable 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.