shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-01 00:51:24 +03:00
Code
21d46382e0
systemd/docs/DESKTOP_ENVIRONMENTS.md

119 lines
5.5 KiB
Markdown
Raw Normal View History

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.
2020-02-10 17:53:55 +03:00
---
title: Desktop Environment Integration
category: Concepts
layout: default
docs: add spdx tags to all .md files I have no idea if this is going to cause rendering problems, and it is fairly hard to check. So let's just merge this, and if it github markdown processor doesn't like it, revert.
2021-09-14 17:05:21 +03:00
SPDX-License-Identifier: LGPL-2.1-or-later
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.
2020-02-10 17:53:55 +03:00
---
# 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
docs: Change prefix for desktop applications to app- We need both a slice name and a prefix for application units. For consistency we tried to use the same name and ended up standardising on "apps.slice" and and "apps-" prefix for the units. However, "app-" would be a more natural prefix for applications. And it is no problem to simply also name the slice "app.slice" for consistency rather than keeping the current "apps.slice".
2020-04-30 15:21:44 +03:00
slices `background`, `app` and `session`.
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.
2020-02-10 17:53:55 +03:00
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
docs: Change prefix for desktop applications to app- We need both a slice name and a prefix for application units. For consistency we tried to use the same name and ended up standardising on "apps.slice" and and "apps-" prefix for the units. However, "app-" would be a more natural prefix for applications. And it is no problem to simply also name the slice "app.slice" for consistency rather than keeping the current "apps.slice".
2020-04-30 15:21:44 +03:00
* `app.slice`: Contains all normal applications that the user is running
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.
2020-02-10 17:53:55 +03:00
* `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
tree-wide: fix spelling errors Based on a report from Fossies.org using Codespell. Followup to #15436
2020-04-21 21:46:53 +03:00
or assigning different memory/CPU/IO priorities to ensure that the session
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.
2020-02-10 17:53:55 +03:00
runs smoothly under load.
docs: Change prefix for desktop applications to app- We need both a slice name and a prefix for application units. For consistency we tried to use the same name and ended up standardising on "apps.slice" and and "apps-" prefix for the units. However, "app-" would be a more natural prefix for applications. And it is no problem to simply also name the slice "app.slice" for consistency rather than keeping the current "apps.slice".
2020-04-30 15:21:44 +03:00
TODO: Will there be a default to place units into e.g. `app.slice` by default
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.
2020-02-10 17:53:55 +03:00
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:
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-09 00:00:33 +03:00
* 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`
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.
2020-02-10 17:53:55 +03:00
* 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.
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-09 00:00:33 +03:00
* The RANDOM should be a string of random characters to ensure that multiple instances
of the application can be launched.
tree-wide: spellcheck fixes Most of them were reported by Fossies.org
2020-06-26 22:30:04 +03:00
It can be omitted in the case of a non-transient application services which can ensure
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-09 00:00:33 +03:00
multiple instances are not spawned, such as a DBus activated application.
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.
2020-02-10 17:53:55 +03:00
* 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:
docs: Change prefix for desktop applications to app- We need both a slice name and a prefix for application units. For consistency we tried to use the same name and ended up standardising on "apps.slice" and and "apps-" prefix for the units. However, "app-" would be a more natural prefix for applications. And it is no problem to simply also name the slice "app.slice" for consistency rather than keeping the current "apps.slice".
2020-04-30 15:21:44 +03:00
* Using the `app-<launcher>-` prefix means that the unit defaults can be
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.
2020-02-10 17:53:55 +03:00
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.
docs: Change prefix for desktop applications to app- We need both a slice name and a prefix for application units. For consistency we tried to use the same name and ended up standardising on "apps.slice" and and "apps-" prefix for the units. However, "app-" would be a more natural prefix for applications. And it is no problem to simply also name the slice "app.slice" for consistency rather than keeping the current "apps.slice".
2020-04-30 15:21:44 +03:00
This could be `app-<launcher>-<ApplicationID>-<RANDOM>.slice`.
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.
2020-02-10 17:53:55 +03:00
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)?
docs: Change prefix for desktop applications to app- We need both a slice name and a prefix for application units. For consistency we tried to use the same name and ended up standardising on "apps.slice" and and "apps-" prefix for the units. However, "app-" would be a more natural prefix for applications. And it is no problem to simply also name the slice "app.slice" for consistency rather than keeping the current "apps.slice".
2020-04-30 15:21:44 +03:00
* Could we maybe add a default `app-.service.d` drop-in configuration?
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.
2020-02-10 17:53:55 +03:00
## XDG autostart integration
docs: Update section about XDG autostart generator The generator is already merged. So update the corresponding section to describe the current status.
2020-07-20 11:45:48 +03:00
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
`xdg-desktop-autostart.target`. 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 `After=graphical-session.target` set on them,
it may therefore not be useful to start session services.
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.
2020-02-10 17:53:55 +03:00
docs: Document xdg-autostart parameter X-systemd-skip
2020-07-20 14:42:13 +03:00
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.
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.
2020-02-10 17:53:55 +03:00
## 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?
Copy Permalink