Bug 1956022 - KDE doesn't run scripts in $HOME/.config/autostart-scripts
Summary: KDE doesn't run scripts in $HOME/.config/autostart-scripts
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 35
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-02 07:23 UTC by Matthew Cline
Modified: 2022-05-16 09:46 UTC (History)
26 users (show)

Fixed In Version: systemd-249.9-1.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-12 19:00:05 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Fedora Pagure fedora-kde/SIG issue 50 0 None None None 2021-07-30 11:41:18 UTC
Github systemd systemd issues 16805 0 None closed New service `Type=any` 2021-11-20 13:12:58 UTC
Github systemd systemd pull 20813 0 None Merged Reintroduce ExitType 2021-11-20 13:12:58 UTC

Internal Links: 2025183

Description Matthew Cline 2021-05-02 07:23:02 UTC
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.

Comment 1 Rex Dieter 2021-05-03 15:32:53 UTC
F34 plasma is configured to use systemd user sessions, this is likely a systemd-xdg-autostart-generator issue.

Comment 2 dominique 2021-05-04 14:46:28 UTC
I have the same problem, What do you mean by "systemd-xdg-autostart-generator issue" ?

Comment 3 Rex Dieter 2021-05-04 15:56:39 UTC
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

Comment 4 Rex Dieter 2021-05-04 16:07:20 UTC
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.

Comment 5 Zbigniew Jędrzejewski-Szmek 2021-05-17 06:16:09 UTC
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.

Comment 6 dominique 2021-06-02 05:32:34 UTC
This bug is not still solved.
When will it be ?

Comment 7 dominique 2021-06-24 05:50:28 UTC
This bug seem be resolved with Fedora 35.
Thank.

Comment 8 dominique 2021-07-08 16:09:47 UTC
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...

Comment 9 dominique 2021-07-16 07:57:48 UTC
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...

Comment 10 Pierre Juhen 2021-11-20 08:31:58 UTC
This bug is not solved by Fedora 35 !

Comment 11 Neal Gompa 2021-11-20 13:06:46 UTC
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.

Comment 12 Neal Gompa 2021-11-20 13:09:17 UTC
Zbigniew, can this be backported for systemd 249?

Comment 13 Jeffrey Rocchio 2021-12-04 23:29:20 UTC
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.

Comment 14 Jeffrey Rocchio 2021-12-06 22:33:51 UTC
(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).

Comment 15 David W. Legg 2021-12-31 10:34:17 UTC
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.

Comment 16 Jeffrey Rocchio 2022-01-02 17:19:59 UTC
(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.

Comment 17 Jeffrey Rocchio 2022-01-02 17:32:31 UTC
(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)

Comment 18 David W. Legg 2022-01-03 17:40:58 UTC
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.

Comment 19 Zbigniew Jędrzejewski-Szmek 2022-01-11 19:54:45 UTC
I backported the patches to v249.10. Unfortunately the backport was very messy, so this is a high-risk
endeavour.

Comment 20 Fedora Update System 2022-01-11 21:42:44 UTC
FEDORA-2022-f38f479b8f has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f38f479b8f

Comment 21 Fedora Update System 2022-01-12 01:49:26 UTC
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.

Comment 22 David W. Legg 2022-05-13 09:19:54 UTC
This should not have been closed as errata.


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