xdg-autostart-generator: unconditionally ignores items with X-GNOME-Autostart-Phase

[rdieter]

per

systemd/src/xdg-autostart-generator/xdg-autostart-service.c

Line 558 in c0267a5

if (service->gnome_autostart_phase) {

xdg-autostart-generator ignores all autostart items with the key
X-GNOME-Autostart-Phase

and now that kde plasma supports systemd user sessions, we noticed that several autostart items are not running. One of them was xdg-user-dirs since it contains
X-GNOME-Autostart-Phase=Initialization

I'd argue that xdg-autostart-generator should not do this unconditionally, and take more care to do it only where it makes sense.

[keszybz]

@benzea

[benzea]

Hmm, we would need to move the evaluation of such logic into an ExecCondition= then (or possibly generate multiple files with ConditionEnvironment=).

But, I think the proper thing to do here is to create a new systemd service. This should be pulled in by graphical-session-pre.target and also specify Before=graphical-session-pre.target. And then, set X-systemd-skip=true in the .desktop file.

CC: @davidedmundson

[benzea]

We could even run it when the systemd user instance starts. However, I suspect that might cause issues if the user's language has not been properly exported to the environment yet.

[davidedmundson]

@rdieter can you tell us which .desktop files you encountered with?

In KDE we had an X-KDE-autostart-phase=

It was only used by a few core critical processes, our stance was that if it's so important that it needs custom startup positioning it needs to have a custom service file where we can express the exact wants/before/afters. Therefore it was safe to just ignore in the generator.

[davidedmundson]

FWIW, on Arch xdg-user-dirs does have a systemd service for xdg-user-dirs-update and no .desktop file [1]
It's wanted by default.target, which makes it very early in the boot, but there's nothing syncing it to finish before any of our stuff is run.

[1] https://github.com/archlinux/svntogit-packages/blob/packages/xdg-user-dirs/trunk/xdg-user-dirs-update.service

[rdieter]

@rdieter can you tell us which .desktop files you encountered with?

The most important and noticeable one was xdg-user-dirs. I've found some others:
spice-vdagent.desktop

[alois31]

I have xdg-user-dirs and fcitx-autostart. The latter one not starting is pretty annoying.

[benzea]

So, for fcitx-autostart.desktop we could just ignore the Applications phase specifically, as that just explicitly sets the default value.

[benzea]

FWIW, on Arch xdg-user-dirs does have a systemd service for xdg-user-dirs-update and no .desktop file [1]
It's wanted by default.target, which makes it very early in the boot, but there's nothing syncing it to finish before any of our stuff is run.

I think the approach is correct in principle. However, we need to move it to hook into graphical-session-pre.target instead (and let's add an explicit Before=). And we also need to keep providing the XDG autostart file (with X-systemd-skip=true).

The reason is that the xdg-user-dirs requires the locale to be set correctly. However, that may only happen during desktop startup by reading a desktop specific settings key. As such, we must run this only after the graphical session has began startup.

[unusual-thoughts]

@rdieter can you tell us which .desktop files you encountered with?

The most important and noticeable one was xdg-user-dirs. I've found some others:
spice-vdagent.desktop

spice-vdagent already has a (system-level) systemd service, does it also need a user service ?

[rdieter]

@rdieter can you tell us which .desktop files you encountered with?

The most important and noticeable one was xdg-user-dirs. I've found some others:
spice-vdagent.desktop

spice-vdagent already has a (system-level) systemd service, does it also need a user service ?

Alll I know is that this exists, but I don't know it's purpose exactly:

$ cat /etc/xdg/autostart/spice-vdagent.desktop
[Desktop Entry]
Name=Spice vdagent
Comment=Agent for Spice guests
Exec=/usr/bin/spice-vdagent
Terminal=false
Type=Application
Categories=
X-GNOME-Autostart-Phase=WindowManager
NoDisplay=true

[skierpage]

@rdieter can you tell us which .desktop files you encountered with?

This is also causing KDE bug 439346 "baloo_file doesn't start when desktop plasma starts" in Fedora 34.

I commented out both
X-GNOME-Autostart-enabled=true
and
X-systemd-skip=true
in Baloo's /etc/xdg/autostart/baloo_file.desktop, and on next reboot baloo_file autostarted 👍 The actual service unit running is not Baloo's /usr/lib/systemd/user/kde-baloo.service, but

% systemctl --user status app-baloo_file@autostart.service
    ● app-baloo_file@autostart.service - Baloo File Daemon
         Loaded: loaded (/etc/xdg/autostart/baloo_file.desktop; generated)
         Active: active (running) since Sat 2021-07-10 15:35:41 PDT; 7h ago

[benzea]

But if there is kde-baloo.service, then this is what should be run. Of course you can enable it indirectly by not disabling the XDG file.

The proper fix is likely to find the reason that kde-baloo.service is not getting started- This might be a local configuration error in the sense that a preset is not set or not being applied correctly.

[skierpage]

The proper fix is likely to find the reason that kde-baloo.service is not getting started

Yes, I think adding kde-baloo.service to Wants= in /usr/lib/systemd/user/plasma-workspace@.target is probably the best fix, leaving baloo's xdg/autostart file as is. I'm sorry I clogged up this issue.

[gotmax23]

spice-vdagent already has a (system-level) systemd service, does it also need a user service ?

Yes, it does. Please see rhbz#1951580 (specifically comment #13) for more information.

[Arthus]

I have also been bit by this issue.

I'm using openSUSE Tumbleweed and KDE and had the systemd startup enabled. Then I installed IBus and wondered, why the service wouldn't show up, let alone the daemon start up. On another device it works fine. I found that the main difference was that one device used KDE's systemd start process.
And after digging into the process with the systemd generator and finding this Github issue, I checked the autostart file and yes:
the .desktop file for the ibus-daemon also has the "X-GNOME-Autostart-Phase" entry set.
here's the corresponding file for opensuse

So even if the fix takes some more time, please at least raise the log level of the corresponding output. I understand that files that don't conform to the XDG standard can be debug messages - systemd is not meant to be a .desktop file verifier. (Lines

systemd/src/xdg-autostart-generator/xdg-autostart-service.c

Line 520 in 6b64d74

if (service->systemd_skip) {

and surrounding)
But when systemd unconditionally skips these perfectly valid files, even though GNOME is not even used, the log level should be something like log_warning and not a debug message that needs to be enabled first by the end user.

[benzea]

I still think that we just need to go through the migration pain here. We can provide some compatibility, but certain services just need to be migrated to systemd proper for their integration to work (this is really simple, the main issue is knowing what is affected and chasing down people to fix it …).

Is there an upstream issue for ibus already? If yes, could you point me to it, if no, could you maybe open one and paste the link?

[unusual-thoughts]

ibus-autostart is a SUSE-only script, ibus-daemon is normally dbus-activated. So I think the upstream in this case is SUSE.

I'm not sure what the point of the script is, as it exits on GNOME and shouldn't really be needed either way as long as the org.freedesktop.IBus.service DBus service file is installed ?

Edit: Apparently the service file isn't enough, probably the dbus service never gets called unless the DE integration has been started by ibus itself, kind of a chicken and egg situation. The autostart .desktop file itself has been intentionally removed from ibus, see ibus/ibus#1331 (comment)

[Sodivad]

I added a systemd service for xdg-users-update https://gitlab.freedesktop.org/xdg/xdg-user-dirs/-/merge_requests/10

[chewblacka]

I still think that we just need to go through the migration pain here. We can provide some compatibility, but certain services just need to be migrated to systemd proper for their integration to work (this is really simple, the main issue is knowing what is affected and chasing down people to fix it …).

I'm still being bitten by this bug in Nov 2022. spice-vdagent fails to start in KDE due to the presence of the line X-GNOME-Autostart-Phase. This is an issue in Arch, Tumbleweed and NixOS unstable. Who needs to be chased down for this? KDE? Systemd? Spice? Please can we sort this bug out and not let it linger ad infinitum. Many thanks!

[nylocx]

I can add another distribution to the list, Manjaro is affected by this too @chewblacka did you find an "upstream" tracker for this?

[davidedmundson]

spice-vdagent already has a (system-level) systemd service, does it also need a user service ?

they now ship one upstream

[Danny3]

Will this ever be fixed?

KDE Plasma on Debian is affected too.
And this is not user-friendly at all.