Description of problem:
The ksensors package ships an /etc/xdg/autostart/ksensors.desktop desktop file. That autostart file works fine with ksmserver. But if I have the systemd user session enabled in Plasma, I have to start KSensors manually.
Version-Release number of selected component (if applicable):
Always (as far as I can tell)
Steps to Reproduce:
1. Install KSensors.
2. Ensure that "Autostart KSensors on KDE startup" is enabled in the KSensors settings.
3. kwriteconfig5 --file startkderc --group General --key systemdBoot true (the default for current Fedora releases)
4. Restart your Plasma session.
KSensors is not automatically started and has to be started manually.
KSensors is started automatically.
Workaround: switch back to ksmserver, i.e.:
kwriteconfig5 --file startkderc --group General --key systemdBoot false
When I execute 'systemd-xdg-autostart-generator /tmp/out', it produces
/firstname.lastname@example.org, but does symlink it into /tmp/out/xdg-desktop-autostart.target.wants.
I don't know the details of the autostart logic, but it's either some bug or missing feature there.
@benzea, any idea?
I am getting the symlink once I install plasma-workspace which contains the kde-systemd-start-condition binary. This is a bug in the generator, as the symlink should still be installed, but I expect Kevin has the binary.
Kevin, can you provide the logs of the login? I wonder if there is something weird going on and ksensors actually fail to start.
I created a pull request to enhance the logging: https://github.com/systemd/systemd/pull/22071.
With that, it's pretty clear what is happening: for non-trivial autostart conditions we defer to
a helper binary that was supposed to be provided by the desktop environment. For GNOME that is
gnome-systemd-autostart-condition, and for KDE kde-systemd-start-condition. Neither binary was
ever implemented, afaict. And if we can't figure out the condition, we skip the unit.
/etc/xdg/autostart/ksensors.desktop has X-KDE-autostart-condition=ksensorsrc:General:AutoStart:true.
To handle this, kde-systemd-start-condition would need to be implemented that groks this syntax
and implements the appropriate check. Doing this is out of the scope of systemd itself. This bug
should be reassigned to some KDE component that could provide this helper.
gnome-systemd-autostart-condition is missing too. E.g. /etc/xdg/autostart/orca-autostart.desktop
has 'AutostartCondition=GSettings org.gnome.desktop.a11y.applications screen-reader-enabled'
and we don't add the enablement symlink.
I see the following examples:
AutostartCondition=GSettings org.gnome.desktop.a11y.applications screen-reader-enabled
AutostartCondition=GSettings org.gnome.desktop.interface toolkit-accessibility
Yeah, the systemd bug is that the generator doesn't create the symlink if one of the binaries are missing. The fix is trivial for that, I'll create an MR in upstream. (note that GNOME doesn't even ship that binary yet)
I see I messed up my query. I think I was confused by the "-autostart-" vs. "-start-" in the two names, and when I couldn't find the GNOME helper, I didn't look to hard for the KDE one.
> the systemd bug is that the generator doesn't create the symlink if one of the binaries are missing
I'm pretty sure that this is correct. It is better not to start units than to start them when
we can't figure things out. For example, in the test case being discussed here, I don't think I should
get ksensors autostarted just because I don't have plasma-workspace installed.
> note that GNOME doesn't even ship that binary yet
Is there something in the works?
> I'm pretty sure that this is correct. It is better not to start units than to start them when we can't figure things out.
Yes and no. Units that are desktop specific also need to set the appropriate OnlyShowIn= option. This option is evaluated by the systemd internal ExecCondition= checker. Said differently, it is not systemd's problem, but rather a bug in the .desktop file which is not setting the appropriate OnlyShowIn= or NotShowIn= options.
If we have a service that works for both KDE and GNOME, and GNOME isn't installed (or doesn't ship the binary), we still need to autostart it for KDE. I filed https://github.com/systemd/systemd/pull/22072
>> note that GNOME doesn't even ship that binary yet
> Is there something in the works
To be honest, I lost track of that. There were some unresolved issues with GNOME startup quirks that make it really hard to switch over currently. ExitType=cgroup solved some things, but not all.
Anyway, I think this should work. My initial guesses were all wrong. With plasma-workspace installed:
/etc/xdg/autostart/ksensors.desktop: ExecCondition converted to /usr/bin/kde-systemd-start-condition --condition "ksensorsrc:General:AutoStart:true"…
/etc/xdg/autostart/ksensors.desktop: symlinking email@example.com in xdg-desktop-autostart.target/.wants…
So it looks all right.
Kevin, can you paste $XDG_RUNTIME_DIRfirstname.lastname@example.org ?
I suppose I need to debug this further. One issue could be that it starts too soon (and fails as a result), because systemd does not support the "X-KDE-autostart-phase=2" line. (But neither does it automatically ignore anything with the line as it does for the GNOME equivalent. It just starts the service whenever it wants.)
If the X-KDE-autostart-condition is the problem, I suspect I can probably drop that line entirely, considering that:
* KSensors writes the configuration in the legacy KDE 3/4 location, Plasma 5 probably does not even look there, but just uses the default value (the "true" in the .desktop file), AND
* the .desktop file uses "ksensors --autostart", which verifies the condition by itself (a feature I have originally patched in for non-KDE desktops, which do not support X-KDE-autostart-condition at all).
But I suspect the ordering is the issue. I added that "X-KDE-autostart-phase=2" line in 2017 to work around a race condition:
* Sun Apr 30 2017 Kevin Kofler <Kevin@tigcc.ticalc.org> - 0.7.3-36
- Fix autostart race condition in Plasma 5 by setting the autostart phase
and even then KSensors occasionally fails to start up. I suppose I should try shipping a native systemd unit that adds a systemd After= dependency on a specific target and setting X-systemd-skip on the .desktop file?
In particular, ksensors should start after xembedsniproxy or there is no way the XEmbed system tray icon(s) will show up.
Yes a custom systemd unit (and possibly dbus-activation if appropriate) is generally the best solution.
The startup race (even with setting the autostart phase) seems like something that might need to be solved independently anyway. In general, I would think that the After=graphical-session.target setting that the generator does is already quite generous; all core components should be ready at that point (in GNOME's case all gnome-settings-daemon processes are running for example).
> In particular, ksensors should start after xembedsniproxy or there is no way the XEmbed system tray icon(s) will show up.
Wait, that might be a KDE bug then. The unit has:
Adding a `Before=graphical-session.target` into the .service file would solve the issue then.
> The startup race (even with setting the autostart phase) seems like something that might need to be solved independently anyway.
Well, the legacy ksmserver does not support dependencies, the autostart phase number is the only way to enforce some kind of ordering.
That said, I suspect that even with the correct ordering, there may still be a race, because the startup happens asynchronously and has no way to know when xembedsniproxy is actually ready. (This is also why the numbering approach in ksmserver is not completely race-free either.)
> Adding a `Before=graphical-session.target` into the .service file [for xembedsniproxy] would solve the issue then.
Uh, can a unit be ordered before the target it is part of?
> Uh, can a unit be ordered before the target it is part of?
I think it works, but you are right that it is weird and probably much better to do:
At the end of the day you'll need some synchronisation to prevent the race. A DBus name is the generic method that I know which works with and without systemd. But maybe there are other solutions.
I talked to David Edmundson. Turns out, the appropriate ordering is already there on the other side (in plasma-workspace@.target). The only problem is that xembedsniproxy is of Type=simple and systemd considers it immediately started rather than waiting for the X11 parts to be there.
Note that ksensors could also watch for the X11 tray to appear dynamically rather than assuming it will already be ready when it starts.
Reassigning to ksensors based on the last comment.
(We'll apply the fixups in systemd in https://github.com/systemd/systemd/pull/22071 and https://github.com/systemd/systemd/pull/22072,
but it's seems that this will not fix the bug.)
Upstream KDE is also picking up a fix to plasma to make sure xembedsniproxy is started prior to launching other applications.
I have seen that, but it does not seem to fix the problem for me, at least not by itself.