Plasma Workspace as systemd user-session

Ultimate Goal

The ultimate goal of this project is, to make use of systemd's support for user-sessions wherever possible for running a Plasma Workspace. This support is to be implemented in a way which doesn't get in the way of legacy/cross-platform support, so running a Plasma Workspace without a systemd user-session underneath will still be possible.

What are the benefits?

Parallelized and faster startup of the Plasma Workspace after login
More finegrained control over running services
Increased stability by eliminating existing hacks in startkde, ksmserver, kdeinit, … and delegating process/service control to a facility (systemd) which is specifically built for this job
Cleaner definition of dependencies between Plasma Workspace components
Increased security
Greatly improved logging by using systemd's journald - goodbye horrible piece of log-target called ~/.xsession-errors
Better control over system resources/process priorities (e.g. ensure GUI elements are always responsive) via systemd's builtin cgroup control interface

Resources

user-session units for Plasma Workspace

I created some initial user-session units for Plasma Workspace which can be found on GitHub.

Unsorted items

This is a collection of items, notes and other things which need to be taken care of. They need to be investigated and properly documented.

ksmserver

ksmserver does a lot of ugly (from systemd's perspective) things which need to be evaluated:

tries to start a WM in ksmserver/startup.cpp → launchWM which should be left to systemd

ksplashqml

Relies on a serial startup of the components, but isn't able to deal with a parallelized startup. If the final result is a really fast startup, a splash screen might be not needed anymore. If the startup still takes "enough" time to show a splash screen, ksplashqml needs to be reworked to be able to deal with a parallelized startup.

DBus-activatable applications

IRC Log (#kde-devel, 2014-10-03)

[13:57:06] <eliasp> some applications (Kate, Konsole, …) started naming their desktop file in /usr/share/applications/ as org.kde.$application.desktop … is this something which should be streamlined across all KF5 based applications now?
[14:24:41] <frinring> eliasp, rdieter: it allows DBus-activatable applications, see also http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html Not yet supported by kdeplatform, but surely will one day. Needs that naming of desktop file, DBusActivatable=true in desktop file and usage of KDBusService, all that is needed for app-side support
[14:26:45] <eliasp> frinring: ah, awesome… that's something which perfectly fits into my goals for getting systemd user-session support into Plasma…
[14:30:05] <eliasp> frinring: does the application need to do something special when using KDBusService?
[14:30:27] <eliasp> frinring: or does every application using KDBusService automatically fulfill all the requirements?
[14:30:29] <frinring> eliasp: no, just normal KDBusService usage. That installs that interface automatically
[14:30:36] <eliasp> perfect, thanks!

systemd/KCrash race conditions

When auto-restarting services via systemd (which should be the way to go) there are race conditions between systemd and KCrash.

A crashed application is restarted instantly by systemd. At the same time, KCrash tries to launch DrKonqi, but fails to do so, as systemd already restarted the crashed application.