As far as I understood, currently most if not all plasma services are automatically launched on login, and they are defined in /etc/xdg/autostart/. This has several problems, such as annoying ones like DiscoverNotifier, or security relevant ones like kdeconnect-daemon not being trivial to disable. I am currently experimenting with neutering these autostart entries and replacing them with systemd services. Example for KDEConnect # replace with empty entry (attempt to avoid distro updates rein...
Every user can enable services from /etc/systemd/user for their account. If the user doesn’t log in, their instance of the service won’t start. There is a way to have user services launch without logging in, but that would obviously be nonsensical for desktop services.
I don’t think systemd would find units in /etc/systemd/user/KDE. Look at the mess that is /usr/lib/systemd/system. Organization doesn’t seem to be a thing.
I am still a bit confused about systemd services, timers, units, targets and whatever but slowly getting there.
Also do you know how dbus activation would make sense, if it is already used in some ways and if it should be?
I think nearly all these services should run as user ones. I will fix their Wants entry and try to enable them again. Then see if some are dependencies of others, and the other way around on what they depend (like graphical.target, network-online.target, network.target etc).
Also I feel something with accessibility can be improved here, as orca and kaccess may be invoked intelligently (and otherwise dont bother users).
I think systemd targets work opposite to your expectation. The Wants in [unit] define the things that that unit needs to already be available. For instance, you might add Wants=network.target to the unit for nginx so that it won’t try to start until the network is available. When I wrote a unit to start my company’s application, I also had Wants=postgresql.service to ensure that the database came up before the application. Remember that sysyemd tries to run as many things in parallel as it can. This is one thing that makes it much faster than classic sysvinit which started things sequentially. But it means race conditions can occur. You use Wants to break those races where necessary. The targets that you’d specify in WantedBy in [install] more closely resemble SysV runlevels. You might want to read how runlevels used to work in SysV, in order to understand systemd targets.
I fixed them and edited the post. There now is a Github repo for the script, and guess what? Most services still run, so there are at least 2 mechanisms to start them. What a mess
Thanks a lot, I will fix them!
So even though they are placed in
/etc/systemd/userevery user can enable and disable them? This sounds like a good option for many services.Do you know if it is possible to for example place them in
/etc/systemd/user/kde/to have them grouped better?Every user can enable services from /etc/systemd/user for their account. If the user doesn’t log in, their instance of the service won’t start. There is a way to have user services launch without logging in, but that would obviously be nonsensical for desktop services.
I don’t think systemd would find units in /etc/systemd/user/KDE. Look at the mess that is /usr/lib/systemd/system. Organization doesn’t seem to be a thing.
Thanks!
I am still a bit confused about systemd services, timers, units, targets and whatever but slowly getting there.
Also do you know how dbus activation would make sense, if it is already used in some ways and if it should be?
I think nearly all these services should run as user ones. I will fix their Wants entry and try to enable them again. Then see if some are dependencies of others, and the other way around on what they depend (like graphical.target, network-online.target, network.target etc).
Also I feel something with accessibility can be improved here, as orca and kaccess may be invoked intelligently (and otherwise dont bother users).
I really don’t understand dbus.
I think systemd targets work opposite to your expectation. The Wants in [unit] define the things that that unit needs to already be available. For instance, you might add Wants=network.target to the unit for nginx so that it won’t try to start until the network is available. When I wrote a unit to start my company’s application, I also had Wants=postgresql.service to ensure that the database came up before the application. Remember that sysyemd tries to run as many things in parallel as it can. This is one thing that makes it much faster than classic sysvinit which started things sequentially. But it means race conditions can occur. You use Wants to break those races where necessary. The targets that you’d specify in WantedBy in [install] more closely resemble SysV runlevels. You might want to read how runlevels used to work in SysV, in order to understand systemd targets.
I fixed them and edited the post. There now is a Github repo for the script, and guess what? Most services still run, so there are at least 2 mechanisms to start them. What a mess