Transient Unit name for applications

[swick]

Dbus activated processes currently live in transient units with the scheme dbus-<unique>-<ServiceName>@<instance>.service. The systemd Desktop Environments Integration specification says that applications should be in service or scopes which follow the following scheme app[-<launcher>]-<ApplicationID>[@<RANDOM>].service.

xdg-desktop-portal relies on this convention to derive the app id of a calling process (when the application is not authenticated by a sandboxing specific code path). This however breaks for apps started by dbus-broker. It would be nice if it followed the convention.

Can we change the schema to app-dbus-<ServiceName>@<unique><instance>.service? Not all services are applications. Should we change the schema only if the service has a corresponding desktop file?

[dvdhrm]

Sounds good! I created a PR to implement this. I added a dash between <unique> and <instance>, but didn't check whether systemd actually allows this in the template argument. Anyway, please let me know if that PR looks good!

Btw., we should document that this becomes API and should not be changed in the future.

[smcv]

Am I right in thinking that for services with SystemdService=foo.service, dbus-broker will start the systemd service named foo.service (the same as dbus-daemon does), with transient units only used for services that lack a SystemdService (as dbus-broker's equivalent of dbus-daemon's "traditional activation" in a child process)?

If that's true, then xdg-desktop-portal will not always be able to rely on this convention anyway, both for dbus-broker and for dbus-daemon, because foo.service doesn't indicate an app ID.

[dvdhrm]

Correct. I would mostly see this as an effort to make the naming scheme of dbus-broker API, and then stick to the spec as closely as possible.

[smcv]

I would mostly see this as an effort to make the naming scheme of dbus-broker API

Wouldn't that mean that adding a SystemdService=fooapp.service to an existing session service would be a functional regression on dbus-broker systems, because consumers of this "API" would no longer be able to identify its app-ID?

Something like this:

• start with a D-Bus .service file with Name=com.example.FooApp
  • dbus-broker starts it as a transient service app-dbus-com.example.FooApp@<unique>.service or something, xdg-desktop-portal can identify it as part of com.example.FooApp (which is a nice thing to have)
  • dbus-daemon starts it via traditional activation, xdg-desktop-portal can't identify it (not ideal but not a regression)
• now add SystemdService=fooapp.service
  • dbus-broker starts it as a non-transient service, xdg-desktop-portal can no longer identify it as part of com.example.FooApp (regression!)
  • dbus-daemon starts it as a non-transient service, xdg-desktop-portal still can't identify it (not ideal but not a regression)

I think the ideal thing might be if there was a way for xdg-desktop-portal to inspect fooapp.service and find out its app-ID from metadata, which could work equally well for dbus-broker and dbus-daemon? And then dbus-broker could put that same metadata on its transient units too?

[smcv]

now add SystemdService=fooapp.service

Or is the intention that this is deprecated, and if anything with an app-ID is installing a user-service, it should be named like /usr/lib/systemd/user/app-com.example.FooApp.service and therefore SystemdService=app-com.example.FooApp.service?

If that is the intention, then it doesn't seem to have stuck yet. At the moment, on my Debian testing/unstable system, I have:

• no user services named like that
• lots of user services named the same way system services traditionally were: a short name similar to the one you'd put in /usr/bin or /usr/libexec, like gpg-agent.service and gnome-remote-desktop.service
• a small number of user services named with a reversed-DNS D-Bus-style name with no app- prefix, like org.gnome.Evince.service

[swick]

If that's true, then xdg-desktop-portal will not always be able to rely on this convention anyway, both for dbus-broker and for dbus-daemon, because foo.service doesn't indicate an app ID.

True, we already don't hard rely on this. Users can also start binaries directly from their command line etc.

I don't think anyone disagrees that we should still try to make applications start in services/slices which adhere to this convention whenever possible.

I think the ideal thing might be if there was a way for xdg-desktop-portal to inspect fooapp.service and find out its app-ID from metadata, which could work equally well for dbus-broker and dbus-daemon? And then dbus-broker could put that same metadata on its transient units too?

This doesn't solve the issue with systemd services, does it? Even if the dbus service file contains the appid, if the systemd service name will always be whatever the systemd service file is.

This might still be a good idea. It makes sure only apps end up with the "app-" prefix and not random services which don't happen do have a corresponding systemd service. On the other hand this opt-in requires the app developers to adjust to it. Just looking for a corresponding desktop file doesn't have those issues (but requires the .service and .desktop files to be named to same).

Or is the intention that this is deprecated, and if anything with an app-ID is installing a user-service, it should be named like /usr/lib/systemd/user/app-com.example.FooApp.service and therefore SystemdService=app-com.example.FooApp.service?

Isn't this basically already the case according to the systemd desktop integration spec? It says:

• Application units should follow the scheme [...]
• 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.

Apparently @benzea wrote this. Any opinion?

If that is the intention, then it doesn't seem to have stuck yet.

Yeah, I think we should push for that but I'm not sure what that would involve.

[smcv]

This doesn't solve the issue with systemd services, does it? Even if the dbus service file contains the appid, if the systemd service name will always be whatever the systemd service file is.

Sorry, I wasn't clear enough about fooapp.service being the systemd service file, not the D-Bus service file. What I was suggesting was having x-d-p look at the metadata of the systemd service (which could contain the app ID), and not just its name.

I don't think adding the app ID to the D-Bus service file would be useful, because the important thing on D-Bus is the bus name, which should match the app ID anyway. The D-Bus service file should ideally always be ${bus_name}.service, although a few older D-Bus services don't follow that pattern, and that links them back to the app ID. The filename of the D-Bus service file is also not very interesting, because it's not part of the API in the way that the names of systemd services are.

The names of systemd service files have traditionally used the same short name you might use in /usr/bin, /usr/libexec or /etc/init.d, like dbus.service, gpg-agent.service and pipewire.service, so they're unconnected to the app ID.

[dvdhrm]

Wouldn't that mean that adding a SystemdService=fooapp.service to an existing session service would be a functional regression on dbus-broker systems, because consumers of this "API" would no longer be able to identify its app-ID?

The API would guarantee that a missing SystemdService= line produces a predictable service-name based on the dbus-activation-file. I would expect an application to check the dbus-activation-file and decide based on the presence of SystemdService= how to react. IOW, it would enable a predictable service-naming. It would not allow shortcutting the dbus-service-file. Hence, I don't believe adding SystemdService= would break the API.

The current naming-scheme already allows this, but as @swick correctly pointed out, this has not been part of our API guarantees in any way and is really fragile to rely upon. Hence, the proposed switch to a documented naming scheme plus documenting this as ABI.

I am open to other suggestions, especially if they allow reliably deducing the appid from the dbus-activation file.

[swick]

Re-reading it with the knowledge that the service is a systemd service...

I think the ideal thing might be if there was a way for xdg-desktop-portal to inspect fooapp.service and find out its app-ID from metadata, which could work equally well for dbus-broker and dbus-daemon? And then dbus-broker could put that same metadata on its transient units too?

That would be giving up on the systemd naming convention and we would have yet another convention of how to get the app id from a process. I would much prefer to move everything over to the systemd naming convention if at all possible.

The transient unit case is low hanging fruit. The systemd service case is a bit more interesting.

The names of systemd service files have traditionally used the same short name you might use in /usr/bin, /usr/libexec or /etc/init.d, like dbus.service, gpg-agent.service and pipewire.service, so they're unconnected to the app ID.

Sure, but on the other hand none of those are what I would consider applications. None of them have any reason to use portals and if they do, having a host app with an empty app id should just be considered authorized.

That's why I was also asking if we should only enforce the systemd naming convention for transient units if the dbus service file has a corresponding desktop file (maybe require NoDisplay=false).

Why do you prefer to add another key to the systemd service file instead of renaming the file according to the systemd naming convention?

[smcv]

Why do you prefer to add another key to the systemd service file instead of renaming the file according to the systemd naming convention?

I don't prefer it, exactly, but there are two reasons I thought it should be considered:

• the name of the systemd unit fooapp.service or similar (for an application with a SystemdService=fooapp.service in its D-Bus service file) is potentially also "API" that is referenced from elsewhere, although the ability for systemd units to have aliases probably solves this;
• it seemed strange to me that with the change that is proposed here, a change that is usually positive or at worst neutral (adding a SystemdService to the D-Bus service file to tie it to a systemd unit) becomes negative

[smcv]

I would expect an application to check the dbus-activation-file and decide based on the presence of SystemdService= how to react

This seems odd to me: usually D-Bus service files are written by application authors and only read by a message bus implementation (dbus-daemon or dbus-broker), and occasionally read/written by a sandboxed-app framework like Flatpak that needs to transform the Exec line. Applications usually only care about whether the name is activatable or not, which they canonically find out from ListActivatableNames() rather than by reading D-Bus service files themselves.

[swick]

a small number of user services named with a reversed-DNS D-Bus-style name with no app- prefix, like org.gnome.Evince.service

I checked my install and there is literally no service for what I would consider an application. I suspect there are not many which ship with a systemd service file. Could we reasonable rename them upstream?

it seemed strange to me that with the change that is proposed here, a change that is usually positive or at worst neutral (adding a SystemdService to the D-Bus service file to tie it to a systemd unit) becomes negative

Not if you follow the naming schema for the systemd service file.

[swick]

This is still relevant. Not sure how to push it forward though. I think there are two problems:

1. How do we deal with systemd services
2. How do we decide if something is an app and not a service etc

I would say we can just ignore 1. and then in the future change the service file names when it makes sense. For the second issue maybe one of those is a reasonable solution:

• consider everything an app which has a corresponding .desktop file and where Hidden and NoDisplay are not true
• add a new propery to the dbus service files describing the type (i.e. type=app|service, default to service)