Desktop Environments

NOTE: This document is a work-in-progress.

Single Graphical Session

systemd only supports running one graphical session per user at a time. While this might not have always been the case historically, having multiple sessions for one user running at the same time is problematic. The DBus session bus is shared between all the logins, and services that are started must be implicitly assigned to the user’s current graphical session.

In principle it is possible to run a single graphical session across multiple logind seats, and this could be a way to use more than one display per user. When a user logs in to a second seat, the seat resources could be assigned to the existing session, allowing the graphical environment to present it is a single seat. Currently nothing like this is supported or even planned.

Pre-defined systemd units

systemd.special(7) defines the and to allow cross-desktop integration. Furthermore, systemd defines the three base slices background, app and session. All units should be placed into one of these slices depending on their purposes:

The purpose of this grouping is to assign different priorities to the applications. This could e.g. mean reserving memory to session processes, preferentially killing background tasks in out-of-memory situations or assigning different memory/CPU/IO priorities to ensure that the session runs smoothly under load.

TODO: Will there be a default to place units into e.g. app.slice by default rather than the root slice?

XDG standardization for applications

To ensure cross-desktop compatibility and encourage sharing of good practices, desktop environments should adhere to the following conventions:

This has the following advantages:

TODO: Define the name of slices that should be used. This could be app-<launcher>-<ApplicationID>-<RANDOM>.slice.

TODO: Does it really make sense to insert the <launcher>? In GNOME I am currently using a drop-in to configure, CollectMode=inactive-or-failed and TimeoutSec=5s. I feel that such a policy makes sense, but it may make much more sense to just define a global default for all (graphical) applications.

XDG autostart integration

To allow XDG autostart integration, systemd ships a cross-desktop generator to create appropriate units for the autostart directory (systemd-xdg-autostart-generator). Desktop Environments can opt-in to using this by starting The systemd generator correctly handles OnlyShowIn= and NotShowIn=. It also handles the KDE and GNOME specific X-KDE-autostart-condition= and AutostartCondition= by using desktop-environment-provided binaries in an ExecCondition= line.

However, this generator is somewhat limited in what it supports. For example, all generated units will have set on them, and therefore may not be useful to start session services.

Desktop files can be marked to be explicitly excluded from the generator using the line X-systemd-skip=true. This should be set if an application provides its own systemd service file for startup.

Startup and shutdown best practices

Question here are: