Bug 1932447 - plasma systemdBoot: autostart items not launched (xdg-user-dirs)
Summary: plasma systemdBoot: autostart items not launched (xdg-user-dirs)
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-workspace
Version: 34
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: KDE SIG
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedFreezeException
Depends On: 1933312
Blocks: F34BetaFreezeException
TreeView+ depends on / blocked
Reported: 2021-02-24 16:04 UTC by Rex Dieter
Modified: 2021-03-22 08:18 UTC (History)
7 users (show)

Fixed In Version: kde-settings-34.0-3.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-03-03 21:06:18 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
KDE Software Compilation 433538 0 NOR UNCONFIRMED systemdBoot: autostart items not launched (xdg-user-dirs) 2021-02-24 16:04:51 UTC

Description Rex Dieter 2021-02-24 16:04:51 UTC
Testing on both fedora 33 and fedora34 with new plasma-5.21.x systemdBoot=true feature enabled, seems at least some (or all?) autostart items in /etc/xdg/autostart do not get processed or started.

The first and primary symptom we noticed was that XDG-related dirs not getting created for new users, which highlighted that this item doesn't run at least:

I tried adjusting plasma-workspace@.target to move xdg-desktop-autostart.target from Requires= to Wants=, but that didn't seem to make any difference.

Comment 1 Rex Dieter 2021-02-24 21:15:49 UTC
Per upstream report,

This is due to xdg-autostart-generator not supporting startup phases yet. If the desktop file contains the X-GNOME-Autostart-Phase key, the unit will not be generated [1].

[1]: https://github.com/systemd/systemd/blob/c0267a592a2d44c89874249573d53a456ea3756b/src/xdg-autostart-generator/xdg-autostart-service.c#L558

Arg, so "it's a feature" we'll have to workaround somehow.

Comment 2 Rex Dieter 2021-02-24 21:19:23 UTC
Here's the autostart items on my box with that key (that aren't OnlyShowIn=Gnome)


Comment 3 Rex Dieter 2021-02-24 22:20:10 UTC
Filed issue against systemd (xdg-autostart-generator),

Comment 4 Rex Dieter 2021-02-24 23:06:29 UTC
xdg-user-dirs workaround commited (kde-settings-plasma):


Comment 5 Rex Dieter 2021-02-25 16:50:51 UTC
Should be fixed here,


Comment 6 Kevin Kofler 2021-02-26 20:24:06 UTC
Why do we enable systemd user sessions at all?

Comment 7 Kevin Kofler 2021-02-26 20:31:59 UTC
(As I understand the mailing list thread, the Fedora 34 KDE live image enables it by default.)

Comment 8 Rex Dieter 2021-02-27 16:10:16 UTC
Was reminded we're frozen for beta, reopening

Comment 9 Rex Dieter 2021-02-27 16:10:29 UTC
Was reminded we're frozen for beta, reopening

Comment 10 Fedora Update System 2021-02-27 16:14:37 UTC
FEDORA-MODULAR-2021-2de8bbfa5d has been submitted as an update to Fedora 32 Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-2de8bbfa5d

Comment 11 Fedora Update System 2021-02-27 16:16:22 UTC
FEDORA-2021-3519ef4c51 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3519ef4c51

Comment 12 Fedora Blocker Bugs Application 2021-02-27 16:21:32 UTC
Proposed as a Freeze Exception for 34-beta by Fedora user rdieter using the blocker tracking app because:

 Due to a quirk of xdg-autostart-generator and plasma now using systemd user sessions, xdg-user-dirs no longer autostart'd as expected, so user directories such as ~/Picutres, ~/Downloads, ~/Documents were no longer being created.

This is highly visible, and lots of f34 testers noticed.  Only recently discovered the true cause and some workarounds (offered via the bodhi update referenced in the tracker bug).

Would be nice papercut to avoid for f34beta if possible to include the workaround.  Thanks.

Comment 13 Fedora Update System 2021-02-28 14:23:08 UTC
FEDORA-2021-3519ef4c51 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3519ef4c51

Comment 14 Fedora Update System 2021-02-28 19:13:03 UTC
FEDORA-2021-3519ef4c51 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3519ef4c51`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3519ef4c51

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 15 Adam Williamson 2021-03-01 16:59:54 UTC
+4 in https://pagure.io/fedora-qa/blocker-review/issue/259 , marking accepted.

Comment 16 Fedora Update System 2021-03-03 21:06:18 UTC
FEDORA-2021-3519ef4c51 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 17 Marco 2021-03-22 08:18:36 UTC
I also have the same issue and it does not seem to be related to not generated units. Actually, the units *are* generated (I can see them in "generated.late"), but for some reasons the corresponding applications are not started.
This happens specifically with Dropbox and Insync (other applications like Thunderbird work fine). If I set systemdBoot to false, these applications run on startup just fine.
Here are their .desktop files as a reference:

--- Dropbox ---
[Desktop Entry]
GenericName=File Synchronizer
Comment=Sync your files across computers and to the web
Exec=dropbox start -i

--- Insync ---
[Desktop Entry]
Comment=Launch Insync
Exec=insync start

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