Open swick opened 1 year ago
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.
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.
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.
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:
.service
file with Name=com.example.FooApp
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)SystemdService=fooapp.service
com.example.FooApp
(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?
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:
gpg-agent.service
and gnome-remote-desktop.service
app-
prefix, like org.gnome.Evince.service
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.
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.
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.
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?
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:
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;SystemdService
to the D-Bus service file to tie it to a systemd unit) becomes negativeI 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.
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.
This is still relevant. Not sure how to push it forward though. I think there are two problems:
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:
Hidden
and NoDisplay
are not truetype=app|service
, default to service)
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 schemeapp[-<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?