SUMMARY When setting a login script to run in the system settings, it does not show again after the window is closed. STEPS TO REPRODUCE 1. Add login script to the autostart system settings. 2. Close the settings window. 3. Open the settings window again. OBSERVED RESULT No autostart scripts are shown. EXPECTED RESULT Previously selected autostart script is shown. SOFTWARE/OS VERSIONS Kubuntu 21.04 Plasma: 5.21.4 Frameworks: 5.80.0 QT: 5.15.2 Kernel 5.11.0-17-generic x64 ADDITIONAL INFORMATION Konsole output: $) ~: kcmshell5 autostart file:///usr/share/kpackage/kcms/kcm_autostart/contents/ui/main.qml:35:13: QML InlineMessage: Cannot anchor to an item that isn't a parent or sibling. Model size of -96 is less than 0 Model size of -13 is less than 0 ($) ~: kcmshell5 autostart file:///usr/share/kpackage/kcms/kcm_autostart/contents/ui/main.qml:35:13: QML InlineMessage: Cannot anchor to an item that isn't a parent or sibling. ------ How do I remove the duplicate entries for the login script, when I can't see them in the UI?
The anchors message is unrelated. Are you using the systemd startup feature?
.
Sorry, I don't know how to answer your question. I'm not familiar with how systemd works. It looks like the login scripts aren't running. My log file isn't being updated at all when I log in, but when I run my script manually it does work.
If you don't know, you're not using it, as it's an opt-in thing. Unfortunately (or fortunately?) this KCM was rewritten in Plasma 5.22, and 5.21 is not going to get any more bugfix releases, so even if we went back to the old codebase and found and fixed the bug, it would not have a way of getting to users unless distro packagers of all distros manually patched the package. So I'm afraid there is little chance we can fix this bug for you in Plasma 5.21 if it is particular to the old KCM. Any chance you can try the Plasma 5.22 beta and see if the problem still happens for the new KCM?
> If you don't know, you're not using it, as it's an opt-in thing. technically the distro can opt in and at least Fedora does. To be sure run "kreadconfig5 --file startkderc --group General --key systemdBoot" FWIW I cannot reproduce the issue on 5.21.5 and master (without systemdBoot)
(This is true, but the reporter is using Kubuntu, which to my knowledge has not opted in)
Thank you for the additional information! I ran the command mentioned, and got a blank return... so I guess that's a no to using systemd startup feature. Konsole Output: ($) ~: kreadconfig5 --file startkderc --group General --key systemdBoot ($) ~: Just to confirm, do you want me to try the testing version from here: https://neon.kde.org/download Sorry for the back and forth, but KDE isn't the most accessible software to do things like getting source code or installing betas, so I just want to confirm I'm testing the right thing.
Kubuntu has the 5.22 beta available via their own methods, in fact: https://kubuntu.org/news/plasma-5-22-beta-available-for-testing/ So you could either upgrade your system using that, or try KDE Neon Testing or Unstable edition in a VM or something.
Thank you for the additional information... and point taken. :) I tried the neon testing addition live image, and it looks much better. When I closed and re-opened the settings window, the script showed up correctly. Unfortunately, I couldn't test if the script ran at log in, because I couldn't log out. I made a new user then logged out, but it just went right back to the desktop as the live user. I also tried to switch users, but that ended up hanging (not the entire system, but the animation stopped running). Anyway, that's good enough for me. If the scripts still aren't running properly in the future, I can re-address it then. Thanks for your help!
OK cool!
I had the same bug. For me, ~/.config/autostart was not a directory but a file. I deleted the file and recreated the autostart dir. I restarted just to be sure and I could add scripts and applications again.
That was the key detail. Thanks. Sounds like we need a migration path, or to just delete that file.
I can't think of a good reason why .config/autostart would be a file and I'm a bit hesitant to add a workaround without understanding how we ended up in that state
That's fair. I don't know why it was there, the file was empty as well. Guess we could wait for more reports and instruct to check whether autostart is a file or folder. If it does turn out to be the issue multiple times the workaround might be justified.
Closing this bug report as no one else reported the same issue in the past two years.