diff options
| author | David Edmundson <kde@davidedmundson.co.uk> | 2020-06-08 22:00:33 +0100 |
|---|---|---|
| committer | Lennart Poettering <lennart@poettering.net> | 2020-06-10 17:10:57 +0200 |
| commit | 6a881daf85b18798ca11ee3340b6585f65ffef1b (patch) | |
| tree | d6547946a9fef636c4a71900d3f0c4c36e3642bf /docs/DESKTOP_ENVIRONMENTS.md | |
| parent | 97033ba455c4c1e359835879eee2e3c690395792 (diff) | |
| download | systemd-6a881daf85b18798ca11ee3340b6585f65ffef1b.tar.gz | |
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.
Diffstat (limited to 'docs/DESKTOP_ENVIRONMENTS.md')
| -rw-r--r-- | docs/DESKTOP_ENVIRONMENTS.md | 15 |
1 files changed, 12 insertions, 3 deletions
diff --git a/docs/DESKTOP_ENVIRONMENTS.md b/docs/DESKTOP_ENVIRONMENTS.md index f8f0cb671f..b0ac5b824d 100644 --- a/docs/DESKTOP_ENVIRONMENTS.md +++ b/docs/DESKTOP_ENVIRONMENTS.md @@ -50,13 +50,22 @@ rather than the root slice? 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`, - e.g. `app-gnome-org.gnome.Evince-12345.service`, - `app-flatpak-org.telegram.desktop-12345.service` or `app-KDE-org.kde.okular-12345.service`. + * 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. |