After upgrading from Fedora 33 to Fedora 44, KDE no longer runs the scripts in $HOME/.config/autostart-scripts on login. System Settings > Startup and Shutdown > Autostart shows lists all of my startup scripts, so the problem isn't KDE being unable to find them. However, $HOME/.config/plasma-workspace/env scripts are still sourced at login and $HOME/.config/plasma-workspace/shutdown scripts still run at logout. I'm running KDE under X11 instead of Wayland, if that makes a difference.
F34 plasma is configured to use systemd user sessions, this is likely a systemd-xdg-autostart-generator issue.
I have the same problem, What do you mean by "systemd-xdg-autostart-generator issue" ?
It's a systemd bug, not a plasma one, references include: https://github.com/systemd/systemd/issues/16805 https://github.com/systemd/systemd/pull/18782
Systemd maintainers, the aforementioned issue (and subsquent) PR, is that something that could be included in fedora's systemd packaging? It's affecting user-configured autostart items in plasma.
https://github.com/systemd/systemd/pull/18782 was merged, but https://github.com/systemd/systemd/pull/19385#issuecomment-829383337. This needs to be resolved upstream before being pulled into Fedora.
This bug is not still solved. When will it be ?
This bug seem be resolved with Fedora 35. Thank.
New problem. My script is launched and my conky is here, but after the last conky all conky disappears, like I did a killall conky. May-be it is an other bug...
I have a workaround, I added a line in at the end of my script sleep 18000 But it's a workaround, not a solution...
This bug is not solved by Fedora 35 !
It was just fixed for systemd 250: https://github.com/systemd/systemd/pull/20813 Now, it's a question for the systemd maintainers if we can have it backported for systemd 249 in Fedora.
Zbigniew, can this be backported for systemd 249?
fyi -as of 12/3/2021 still an issue. Fresh install of fedora 35, KDE spin on 12/1/2021. Applied all fedora updates. Installed Dropbox. Went into KDE System Settings, set Dropbox as an 'autostart' application. Confirmed that the dropbox.desktop file was created in ~.config/autostart. Also added Kate as an autostart app just to be sure it wasn't a dropbox specific issue. When I boot up, neither of them start up. When I manually start dropbox using the same command that is in the dropbox.desktop file it starts and runs fine.
(In reply to Jeffrey Rocchio from comment #13) > fyi -as of 12/3/2021 still an issue. Fresh install of fedora 35, KDE spin on > 12/1/2021. Applied all fedora updates. Installed Dropbox. Went into KDE > System Settings, set Dropbox as an 'autostart' application. Confirmed that > the dropbox.desktop file was created in ~.config/autostart. Also added Kate > as an autostart app just to be sure it wasn't a dropbox specific issue. When > I boot up, neither of them start up. When I manually start dropbox using the > same command that is in the dropbox.desktop file it starts and runs fine. Update: Today, after 'dnf updating,' Kate now autostarts. And a test bash script I created does autostart. But dropbox still refuses to start no matter what I set for any of the parameters in the dropbox.desktop file. Nor will it autostart from a bash script. Also, no autostart scripts or apps respect the 'run in terminal and keep terminal open' flag (which I was hoping would allow me to see any reported errors may lay behind droboxd unwillingness to run).
Just to confirm that this is still broken in F34 KDE Plasma. Dropbox (an application) does not auto-start. $HOME/Downloads/FEDORA/lock_screen_plasma.sh (a script) does not auto-start. Originally, with F34, autostart worked, but has not worked for a number of months. Hope that helps.
(Updating my comment #13) > fyi -as of 12/3/2021 still an issue. Fresh install of fedora 35, KDE spin on > 12/1/2021. Applied all fedora updates. Installed Dropbox. Went into KDE > System Settings, set Dropbox as an 'autostart' application. Confirmed that > the dropbox.desktop file was created in ~.config/autostart. Also added Kate > as an autostart app just to be sure it wasn't a dropbox specific issue. When > I boot up, neither of them start up. When I manually start dropbox using the > same command that is in the dropbox.desktop file it starts and runs fine. Update 1/2/2022: My continuing experiments have shown me this - if you 'autostart' a binary, then all is well. If you 'autostart' a script then it does run that script. But it appears to always terminate the script, even when launching that same script from a KDE Desktop Application Icon would not do that. For example, I create a shell script to launch Kate. I create a desktop icon that runs that script. I double-click on it. Kate launches. And it stays running until I quite it. It will also get terminated, as expected, if go into the process monitor and send the kill signal to the running 'launch kate desktop' process. All well and good. However, now put a sleep command into the "Launch Kate" script, right after the kate command: kate sleep 3m Add this 'Launch Kate' script to the list of Autostart apps. On boot/login Kate comes up, as expected. But after 3m Kate gets killed and goes away. So naturally I try it using: nohup kate > ~/Downloads/nohup.txt & sleep 3m But this does not have the desired effect. After 3 minutes Kate still gets killed.
(In reply to David W. Legg from comment #15) > Just to confirm that this is still broken in F34 KDE Plasma. > > Dropbox (an application) does not auto-start. If it helps your particular situation with regards to Dropbox: What I have discovered is that if you point an Autostart item directly to the dropbox binary, then it will work OK. The downside is that the dropbox binary is located down a directory path that contains the current release number, so when it gets updates you have to also update the Autostart item (for example, in my case it is: ~/.dropbox-dist/dropbox-lnx.x86_64-138.4.2392/dropbox). The "proper" way to start Dropbox uses one or more shell scripts that de-reference the current binary's location so you wouldn't have to concern yourself with that. But the Autostart system doesn't appear to be handling scripts that same way it would if you launched the same script from a terminal or desktop icon. (See my just posted comment #16)
Reply to Jeffrey Rocchio above. Thanks, that works nicely. Just need some kind person to make autostart work again for scripts, then it could also be used for dropbox. What would be nicest, though, would be if it just worked for anything executable, beit a script or a binary. Cheers.
I backported the patches to v249.10. Unfortunately the backport was very messy, so this is a high-risk endeavour.
FEDORA-2022-f38f479b8f has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f38f479b8f
FEDORA-2022-f38f479b8f has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-f38f479b8f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f38f479b8f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
This should not have been closed as errata.