After upgrading from KDE 5.20 to 5.21 the scripts in $HOME/.config/autostart-scripts are no longer running at login time, even though System Settings still lists them. Poking around in the plasma-workspace code it seems that they're supposed to have been automatically converted into .desktop files (function migrateUserScriptsAutostart() in startkde/startplasma.cpp), but this hasn't happened.

I'm using Fedora, and the KDE upgrade happened when I upgraded from Fedora 33 to Fedora 34.

I've got the same problem here too (after the upgrade vom FC33 to FC34). On FC33 everything was fine.

Where did you find the newly created ".desktop" files? Did you file a bug report? Could you fix the issue somehow?

It's not the upgrade to 5.21 that broke it, it's the Fedora 33->34 upgrade. Fedora chose to enable the systemd startup integration (which is still off by default upstream) which improves all kinds of things but has known limitations, like autostart scripts not working. The conversion to desktop files will fix this, but it is not part of Plasma 5.21 but will be in 5.22

nicolasfella wrote:It's not the upgrade to 5.21 that broke it, it's the Fedora 33->34 upgrade. Fedora chose to enable the systemd startup integration (which is still off by default upstream) which improves all kinds of things but has known limitations, like autostart scripts not working. The conversion to desktop files will fix this, but it is not part of Plasma 5.21 but will be in 5.22

I don't understand the implications of this. Is there a way to enable the start/login scripts in KDE with Fedora 34 and Plasma 5.21?

Might be a different root cause, but my auto start scripts aren't running either, and I'm not on Fedora.

Another bug I guess. I've already filed half a dozen of them and none of them have been fixed, half of them don't even have a reply. It sounds like people are overworked, and I can't help but wonder if it wouldn't be wise to focus on quality over pushing out new features at this point.

chefniko wrote:...
Another bug I guess. I've already filed half a dozen of them and none of them have been fixed, half of them don't even have a reply. It sounds like people are overworked, and I can't help but wonder if it wouldn't be wise to focus on quality over pushing out new features at this point.

You mean the bugs you file a few days ago? Did you ever try filing a bug to Microsoft? I got a notification about a bug I filed in the 1990 against Word which was fixed about 17 years later... how about a little patience?

Can someone point me to the filed bug report? Are we talking about Bug 436439 - plasma-workspace 93f9ef030 broke my autostart scripts -- repeating the conversion?

There's quite a few bugs on the topic, this one may be helpful to you: https://bugs.kde.org/show_bug.cgi?id=427340

--

I do everything I can not to use Microsoft, although I do have a small secondary drive with Windows installed which is named "Dumpster Fire".

I'm more concerned about the underlying trend in software development, which I see in KDE, as well as many other things, to not show users meaningful errors, and to avoid fixing things when it can be blamed on someone else. Sorry if that's not easy to hear, but I only mention it in hopes that things will improve. I value quality over newness, which is part of why I prefer Linux.

My comment was mainly done because you only just reported the bugs a few days ago, not giving the developers even a bit of time to fix this. Remember they are not all paid for this work?

I understand your point. However, I have numerous bugs filed, and most of them are older than a few days. In fact, I got a 15 day notification that one was waiting on me for info. I certainly should have done better about that! Yes, we're all here on our own time, and it is greatly appreciated.

It's just so frustrating to have so many features that don't work correctly, especially when some of them pretty basic, and it's hard to remain positive when I'm spending so much time finding and implementing workarounds, instead of being productive in my own work. But, with every workaround I implement, I'm able to spend more time being productive, so that's good.

chefniko wrote:I understand your point. However, I have numerous bugs filed, and most of them are older than a few days. In fact, I got a 15 day notification that one was waiting on me for info. I certainly should have done better about that! Yes, we're all here on our own time, and it is greatly appreciated.

It's just so frustrating to have so many features that don't work correctly, especially when some of them pretty basic, and it's hard to remain positive when I'm spending so much time finding and implementing workarounds, instead of being productive in my own work. But, with every workaround I implement, I'm able to spend more time being productive, so that's good.

I share your view and appreciate the civility of your reply. OTOH, you get what you pay for. I gave up on filing bug reports for the same reason. This is one of the unfortunate flaws in open source software with volunteer support. viewtopic.php?f=223&t=165788 It is kind of a thankless effort. I certainly do not want to go back to windows though.

fuzz wrote:

nicolasfella wrote:It's not the upgrade to 5.21 that broke it, it's the Fedora 33->34 upgrade. Fedora chose to enable the systemd startup integration (which is still off by default upstream) which improves all kinds of things but has known limitations, like autostart scripts not working. The conversion to desktop files will fix this, but it is not part of Plasma 5.21 but will be in 5.22

I don't understand the implications of this. Is there a way to enable the start/login scripts in KDE with Fedora 34 and Plasma 5.21?

The workaround I'm using is to manually create a .desktop file for each login script within folder ~/.config/autostart/.

One way to do this is with Dolphin. Open Dolphin and navigate to folder ~/.config/autostart/. In Dolphin's file view pane (on the right side), right-click on any open area. On the pop-up context menu select the options Create New > Link to Application.... When the PROPERTIES dialog appears,

1. (Optional) On the Properties dialog's GENERAL tab, click on the ICON button. On the SELECT ICON dialog, select the desired icon. For example, check option SYSTEM ICONS; select MIMETYPES; in the search box type shell; select the icon application-x-shellscript; click on OK.
2. On the Properties dialog's GENERAL tab, replace the text "Link to Application" with a file name that is compatible with Freedesktop.org's Desktop Entry Specification; see the section titled "File naming." Specifically, the file name is restricted to these characters: ASCII letters, digits, dash (U+002D HYPHEN-MINUS) and underscore (U+005F LOW LINE)), and period (U+002E FULL STOP). If you have your own Internet domain name (e.g., xyz.com), you might specify the desktop file's name as com.xyz.my-login-script.desktop; otherwise, omit the domain prefix, e.g., my-login-script.desktop.
3. On the Properties dialog's APPLICATION tab, click on the Browse... button and then browse to and select the desired login script file. (FWIW, I ususally store my login scripts in a folder named ~/bin/.)
4. (Recommended) On the Properties dialog's GENERAL tab, provide values in the NAME, DESCRIPTION, and COMMENT fields.
5. On the Properties dialog, click on the OK button.

The workaround I'm using is to manually create a .desktop file for each login script within folder ~/.config/autostart/.

Thank you for the verbose explanation. I think the problem lies elsewhere. I've got three files in ~/.config/autostart:

• conky.desktop ✅
• test.desktop ✅
• xbindkeys.desktop ❌

The first one is a working X11 program. And it's starting and running fine. The second program is a test script, that logs it's start, so I can see, everything is fine.

But now the third program: There is a article that describes a problem with xbindkeys and systemd: xbindkeys won't run in ExecStart script but runs in regular script

So, maybe I'm barking at the wrong tree and my systemd scripts are working fine and xbindkeys is the problem here. I will further investigate. Stay tuned.

PS: Here are some log from journalctl:

Code: Select all

Jun 02 20:08:25 REMOVED systemd-xdg-autostart-generator[3748]: /home/REMOVED/.config/autostart/xbindkeys.desktop:14: Unknown key name 'TerminalOptions' in section 'Desktop Entry', ignoring.
Jun 02 20:08:28 REMOVED systemd[3742]: Starting xbindkeys...
Jun 02 20:08:28 REMOVED systemd[3742]: Started xbindkeys.
Jun 02 20:08:28 fuzz.home systemd[3742]: app-xbindkeys@autostart.service: Deactivated successfully.


fuzz wrote:Thank you for the verbose explanation. I think the problem lies elsewhere. I've got three files in ~/.config/autostart:

• conky.desktop ✅
• test.desktop ✅
• xbindkeys.desktop ❌

The first one is a working X11 program. And it's starting and running fine. The second program is a test script, that logs it's start, so I can see, everything is fine.

But now the third program: There is a article that describes a problem with xbindkeys and systemd: xbindkeys won't run in ExecStart script but runs in regular script

So, maybe I'm barking at the wrong tree and my systemd scripts are working fine and xbindkeys is the problem here. I will further investigate. Stay tuned.

Were you able to figure it out? I'm having the same issue with xbindkeys and plasma 5.22.5

So this is the work around I had to settle for :sigh: I made use of the plasmashell Notifications settings to run a script along with a notification for "Connection activated" since I'm on wifi and I always get that notification when I first login. For some reason putting the same script on the "Login" notifications (Under Notifications>plasmashell workspace) did not work, even when I configured that notification to play a sound it just didn't work so this workaround will do for now.

Script:

Code: Select all

#! /bin/sh
# start-xbindkeys.sh
DISPLAY=:0 xbindkeys