mirror of
https://github.com/systemd/systemd.git
synced 2024-12-22 17:35:35 +03:00
docs: Add some notes about managing graphical user sessions
This is work in progress and not finished yet. However, I hope to have captured some of the key points that came up in previous discussions with appropriate notes about things that still need to be defined. I may revisit it later. Also, feel free to completely rewrite if the format is not quite right.
This commit is contained in:
parent
b642dfcdc2
commit
31c68e0277
102
docs/DESKTOP_ENVIRONMENTS.md
Normal file
102
docs/DESKTOP_ENVIRONMENTS.md
Normal file
@ -0,0 +1,102 @@
|
||||
---
|
||||
title: Desktop Environment Integration
|
||||
category: Concepts
|
||||
layout: 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)`](https://www.freedesktop.org/software/systemd/man/systemd.special.html)
|
||||
defines the `graphical-session.target` and `graphical-session-pre.target` to
|
||||
allow cross-desktop integration. Furthermore, systemd defines the three base
|
||||
slices `background`, `apps` 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
|
||||
* `apps.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 assinging 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. `apps.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 `apps-<launcher>-<ApplicationID>-<RANDOM>.service`,
|
||||
e.g. `apps-gnome-org.gnome.Evince-12345.service`,
|
||||
`apps-flatpak-org.telegram.desktop-12345.service` or `apps-KDE-org.kde.okular-12345.service`.
|
||||
* 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.
|
||||
* 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 `apps-<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 `apps-<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 `apps-.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?
|
Loading…
Reference in New Issue
Block a user