Difference between revisions of "User:Eliasp/Drafts/Plasma Workspace as systemd user-session"
(→ksmserver: Turns out this doesn't needs to be done and is something the login manager should do)
|Line 41:||Line 41:|
[14:30:36] <eliasp> perfect, thanks!
[14:30:36] <eliasp> perfect, thanks!
Revision as of 15:09, 30 November 2014
Plasma Workspace as systemd user-session
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
user-session units for Plasma Workspace
I created some initial user-session units for Plasma Workspace which can be found on GitHub.
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 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
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.
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.