1
1
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-22 13:33:56 +03:00
systemd-stable/docs/DESKTOP_ENVIRONMENTS.md
David Edmundson 6a881daf85 docs: Change suffix for desktop applications to support non-transient services
One problem found with the current draft specification is we can't have
an application provide a non-transient systemd service file in a way
that is spec compliant as the service name currently needs to end in a
random token defined by the launcher.

This came up when trying to put DBus activated services into the correct
cgroup. There isn't enough metadata in the DBus service file to know the
correct application ID, and the most intuitive fix is for those
applications to just specify the SystemdService file in the existing
system. They're generally unique for a given user session anyway so
don't need a separate cgroup identifier.

This changes the spec for RANDOM to be optional for services.

It also changes the separator between in services to act like templates.
Ultimately that's what we're trying to recreate with the RANDOM token of
the systemd service and it's a better fit. It's needed as otherwise with
launcher and the random ident being both optional it would be impossible
to get the application ID reliably.

Scopes are unchanged as they don't support templates.
2020-06-10 17:10:57 +02:00

5.2 KiB

title category layout
Desktop Environment Integration Concepts default

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 graphical-session.target and graphical-session-pre.target 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:

  • session.slice: Contains only processes essential to run the user's graphical session
  • app.slice: Contains all normal applications that the user is running
  • background.slice: Useful for low-priority background tasks

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:

  • Application units should follow the scheme app[-<launcher>]-<ApplicationID>[@<RANDOM>].service or app[-<launcher>]-<ApplicationID>-<RANDOM>.scope e.g:
    • app-gnome-org.gnome.Evince@12345.service
    • app-flatpak-org.telegram.desktop@12345.service
    • app-KDE-org.kde.okular@12345.service
    • app-org.kde.amarok.service
    • app-org.gnome.Evince-12345.scope
  • Using .service units instead of .scope units, i.e. allowing systemd to start the process on behalf of the caller, instead of the caller starting the process and letting systemd know about it, is encouraged.
  • The RANDOM should be a string of random characters to ensure that multiple instances of the application can be launched. It can be ommitted in the case of a non-transient application services which can ensure multiple instances are not spawned, such as a DBus activated application.
  • If no application ID is available, the launcher should generate a reasonable name when possible (e.g. using basename(argv[0])). This name must not contain a - character.

This has the following advantages:

  • Using the app-<launcher>- prefix means that the unit defaults can be adjusted using desktop environment specific drop-in files.
  • The application ID can be retrieved by stripping the prefix and postfix. This in turn should map to the corresponding .desktop file when available

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 BindTo=graphical-session.target, 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.

  • Should application lifetime be bound to the session?
  • May the user have applications that do not belong to the graphical session (e.g. launched from SSH)?
  • Could we maybe add a default app-.service.d drop-in configuration?

XDG autostart integration

To allow XDG autostart integration, systemd will ship a cross-desktop generator to create appropriate units for the autostart directory. Desktop Environments will be able to make use of this simply by starting the appropriate XDG related targets (representing e.g. content of the $XDG_CURRENT_DESKTOP environment variable to handle OnlyShowIn/NotShowIn). The names and ordering rules for these targets are to be defined.

This generator will likely never support certain desktop specific extensions. One such example is the GNOME specific feature to bind a service to a settings variable.

Startup and shutdown best practices

Question here are:

  • Are there strong opinions on how the session-leader process should watch the user's session units?
  • Should systemd/logind/… provide an integrated way to define a session in terms of a running user unit?
  • Is having gnome-session-shutdown.target that is run with replace-irreversibly considered a good practice?