Bug 2038750 - systemd user session does not autostart ksensors
Summary: systemd user session does not autostart ksensors
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: ksensors
Version: 35
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kevin Kofler
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-10 01:01 UTC by Kevin Kofler
Modified: 2022-01-11 11:27 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github systemd systemd pull 22071 0 None Merged Improve logs in systemd-xdg-autostart-generator 2022-01-10 21:49:43 UTC
Github systemd systemd pull 22072 0 None open xdg-autostart-service: Ignore missing desktop-sepcific condition binary 2022-01-10 21:49:43 UTC

Description Kevin Kofler 2022-01-10 01:01:10 UTC
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):
systemd-249.7-2.fc35.x86_64
ksensors-0.7.3-48.fc35.x86_64

How reproducible:
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.

Actual results:
KSensors is not automatically started and has to be started manually.

Expected results:
KSensors is started automatically.

Additional info:
Workaround: switch back to ksmserver, i.e.:
kwriteconfig5 --file startkderc --group General --key systemdBoot false

Comment 1 Zbigniew Jędrzejewski-Szmek 2022-01-10 10:16:05 UTC
When I execute 'systemd-xdg-autostart-generator /tmp/out', it produces
/tmp/out/app-ksensors@autostart.service, 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?

Comment 2 Benjamin Berg 2022-01-10 11:26:20 UTC
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.

Comment 3 Zbigniew Jędrzejewski-Szmek 2022-01-10 11:27:14 UTC
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=unless-exists gnome-initial-setup-done
AutostartCondition=GSettings org.gnome.desktop.a11y.applications screen-reader-enabled
AutostartCondition=GSettings org.gnome.desktop.interface toolkit-accessibility
X-KDE-autostart-condition=ksensorsrc:General:AutoStart:true

Comment 4 Benjamin Berg 2022-01-10 11:32:19 UTC
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)

Comment 5 Zbigniew Jędrzejewski-Szmek 2022-01-10 11:36:30 UTC
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?

Comment 6 Benjamin Berg 2022-01-10 11:48:51 UTC
> 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.

Comment 7 Zbigniew Jędrzejewski-Szmek 2022-01-10 11:51:27 UTC
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 app-ksensors@autostart.service in xdg-desktop-autostart.target/.wants…

So it looks all right.

Kevin, can you paste $XDG_RUNTIME_DIR/systemd/generator.late/app-ksensors@autostart.service ?

Comment 8 Kevin Kofler 2022-01-10 13:23:38 UTC
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).

Comment 9 Kevin Kofler 2022-01-10 14:06:51 UTC
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?

Comment 10 Kevin Kofler 2022-01-10 14:53:44 UTC
In particular, ksensors should start after xembedsniproxy or there is no way the XEmbed system tray icon(s) will show up.

Comment 11 Benjamin Berg 2022-01-10 14:54:44 UTC
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).

Comment 12 Benjamin Berg 2022-01-10 14:57:00 UTC
> 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:

```
PartOf=graphical-session.target
After=plasma-core.target
```

Adding a `Before=graphical-session.target` into the .service file would solve the issue then.

Comment 13 Kevin Kofler 2022-01-10 15:06:31 UTC
> 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?

Comment 14 Benjamin Berg 2022-01-10 15:11:40 UTC
> 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:

PartOf=plasma-core.target
After=plasma-core.target
Before=graphical-session.target

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.

Comment 15 Benjamin Berg 2022-01-10 15:43:20 UTC
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.

Comment 16 Zbigniew Jędrzejewski-Szmek 2022-01-10 21:49:44 UTC
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.)

Comment 17 Benjamin Berg 2022-01-11 11:22:53 UTC
Upstream KDE is also picking up a fix to plasma to make sure xembedsniproxy is started prior to launching other applications.

https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1343

Comment 18 Kevin Kofler 2022-01-11 11:27:20 UTC
I have seen that, but it does not seem to fix the problem for me, at least not by itself.


Note You need to log in before you can comment on or make changes to this bug.