Possible Change proposal (F42): convert autostart services to systemd services

Project Discussion
, , , , ,
1

On Fedora Kinoite, like I suppose on all Fedora desktop systems, there are a lot of services in /etc/xdg/autostart that could be converted to systemd services.

I experimented with it and put a script in this repo. Most are KDE services and should be fixed upstream, but the others are afaik put there as part of the Fedora Distribution.

Correct me if I am wrong.

Problem

Having these services in this strange autostart directory is a pain. If you want to stop for example geoclue, or the XWaylandVideobridge (part of KDE), it will just startup again.

Even after neutering many services, the processes still started, so there are likely many other methods which are used as backup, or dependencies.

Benefit

Having these as systemd services, possibly even as systemd user services, would make this way easier.

User services can be enabled and disabled per-user and allow control.

This control is needed for fine tuning, and being able to restrict services is crucial for good administration.

  • reducing the attack surface
  • improving performance
  • making run conditions more intelligent
  • reduce complexity by just using systemd, no strange other detection or restart methods

Afaik the proposal has to be filed within one week as it is system-wide.

I need help and people with the knowledge on these services, to see if it makes sense and how it can be done.

The services are:

  • at-spi-dbus-bus
  • geoclue-demo-agent
  • gnome-keyring-pkcs11
  • gnome-keyring-secrets
  • gnome-keyring-ssh (all these are on KDE as well)
  • orca-autostart
  • powerdevil ?
  • spice-vdagent
  • vboxclient
  • vmware-user
  • xdg-user-dirs

(Look at my script for ideas that I came up with, for example loading some services only under the right conditions)

I suppose there are tons of mechanisms already involved somewhere, for example for controlling when orca starts, or if the Virtualization guest services do something.

These would all need to be found out and removed, to allow this simpler implementation.

1 Like
2

Added idea, package-maintainers, problem, silverblue-team

3

Since most of those are provided by upstream, does it make sense to make those changes on the Fedora side?

From an upstream perspective, using /etc/xdg/autostart allows for support even in environments that don’t have systemd.

1 Like
4

This is not Silverblue or Kinoite specific. This should happen upstream.

2 Likes
5

Removed kinoite-team, silverblue-team

6

That was the question. If these do happen upstream, they should be dealt with there.

yes this is the obvious advantage. I am sure this would also be an agrument against this change on the upstream side.

So, if all these individual projects provide this file and the possible others, the change could be done there.

Question: Do you agree on the benefits of such a change?

7

Services in /etc/xdg/autostart can also be controlled on a per-user basis.

systemd services are more flexible and having a consistent interface would be nice.

We would need to decide if the benefits outweigh the effort of trying to convince all those upstream projects to maintain multiple methods of starting their services.

8

Interesting, you mean by overwriting them in the user dir?

This is the question. I think the services could be converted to a script and then the different init methods of launching that.

The idea: standardization, making it clear what is where

9

Yes.

Right, but now they would be maintaining multiple methods of launching those scripts and the tooling to let the build process choose between them for each distro.

The question becomes, can we convince all the upstream projects this is worthwhile? I think we would need to identify some compelling benefits. For example, what is an actual use case where the current approach doesn’t work?

1 Like
10

Note that xdg-autostart stuff is already transparently handled as transient systemd units. In practice, I’m not sure there’s much benefit given that upstream is trying to avoid breaking non-systemd environments.

2 Likes
11

Could you elaborate on that?

12

It means the implementation is to read them and convert them to systemd units on the fly.

Using an example from your list above, you can see this if you run something like:

 systemctl --user list-units | grep vboxclient

You should see a service named something like app-vboxclient@autostart.service is running.

1 Like