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.

References/links

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. For example


751239-Nov 30 20:11:33 archbox kded5[2183]: Gesture ungrab
751291:Nov 30 20:11:33 archbox kded5[2183]: kdeinit5: Got EXEC_NEW '/usr/lib/drkonqi' from wrapper.
751384:Nov 30 20:11:33 archbox kded5[2183]: kdeinit5: preparing to launch '/usr/lib/drkonqi'
751470-Nov 30 20:11:33 archbox plasmashell[2197]: Application::crashHandler() called with signal 6; recent crashes: 1
751581-Nov 30 20:11:33 archbox plasmashell[2197]: Too many crashes in short order or respawning disabled, not restarting automatically.
751710-Nov 30 20:11:33 archbox plasmashell[2197]: KCrash: crashing... crashRecursionCounter = 2
751799-Nov 30 20:11:33 archbox plasmashell[2197]: KCrash: Application Name = plasmashell path = /usr/bin pid = 2197
751908-Nov 30 20:11:33 archbox plasmashell[2197]: KCrash: Arguments: /usr/bin/plasmashell --no-respawn
752004:Nov 30 20:11:33 archbox plasmashell[2197]: KCrash: Attempting to start /usr/lib/drkonqi from kdeinit
752105-Nov 30 20:11:33 archbox systemd[2162]: plasmashell.service holdoff time over, scheduling restart.
752203-Nov 30 20:11:33 archbox systemd[2162]: Stopping KDE Plasma Workspace.
752273-Nov 30 20:11:33 archbox systemd[2162]: Stopping KDE Plasma Workspace...
752345-Nov 30 20:11:33 archbox systemd[2162]: Starting KDE Plasma Workspace...
752417:Nov 30 20:11:34 archbox drkonqi[2974]: kf5.kiconthemes: "Theme tree: (Breeze)"
752496:Nov 30 20:11:34 archbox drkonqi[2974]: found lsb_release
752553:Nov 30 20:11:34 archbox drkonqi[2974]: Executable is: "/usr/bin/plasmashell"
752630:Nov 30 20:11:34 archbox drkonqi[2974]: Executable exists: true
752693-Nov 30 20:11:34 archbox plasmashell[2978]: kf5.kiconthemes: "Theme tree: (Breeze)"
752776-Nov 30 20:11:34 archbox systemd[2162]: Started KDE Plasma Workspace.
752845-Nov 30 20:11:34 archbox systemd[2162]: Starting KDE Plasma Workspace.
752915-Nov 30 20:11:34 archbox systemd[2162]: Reached target KDE Plasma Workspace.
754173:Nov 30 20:11:34 archbox drkonqi[2974]: The specified process does not exist.