SUMMARY When trying to execute a bash script or a command line program directly nothing happens, the script/command is not executed when the computer starts. As far as I can tell this happens since plasma 5.25 and the introduction systemd startup. STEPS TO REPRODUCE program: 1. Add a new autostart entry "Application". 2. Add this command "amixer -c 0 sset Front unmute" as the "Command" in the "Application" tab. 3. Restart your computer. script: 0. Create a new bash script with the same command: #!/usr/bin/env bash amixer -c 0 sset Front unmute 1. Save it as autostarter and make it executable. 2. Execute the script once to test if it works. 3. Add a new autostart entry "Login script". 4. Select the autostarter script . 5. Restart your computer. OBSERVED RESULT The command is not executed. No visible results or logs I can find. Happy to help to debug this. EXPECTED RESULT The script should be executed. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux main 5.18.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 07 Jul 2022 17:18:13 +0000 x86_64 GNU/Linux KDE Plasma Version: 5.25.3 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 ADDITIONAL INFORMATION Using kwriteconfig5 --file startkderc --group General --key systemdBoot false fixes it for now since it disables systemd startup completely.
I am also not the only one with this problem. There are a couple reports on reddit as well. Example: https://www.reddit.com/r/kde/comments/vi44jr/terminal_windows_in_autostart_are_no_longer/
Are you saying both the script and program approach fail? Please do the test with something simpler. "touch /tmp/foo" I could not reproduce issue using a script as described. It should not have changed. The "program" version would have done. How were you creating a new autostart entry? The UI only presents a way to choose an existing app.
Hi David, I did some more simplified testing as you suggested. Yes both approaches from my initial report failed. More tests: Using a script with: touch /tmp/test1 WORKS Using as an app call with the command "touch /tmp/test2" also WORKS. Using as an app call with a more complicated command "sleep 5s && touch /tmp/test2" does NOT work. Using as an app call with a more complicated command "amixer -c 0 sset Front unmute" does NOT work. The UI allows to execute any command you like. Click +Add... > Add Application... > type touch (or any text, doesn't have to be an existing program) > Press enter > Open the created auto start entry > Click Application tab > change the "Command" field to "sleep 5s && touch /tmp/test" Please note, as I mentioned before, all these attempts work when I disable systemd starup. Hope that clarifies it. Cheers
> Using as an app call with a more complicated command "sleep 5s && touch /tmp/test2" does NOT work. That is somewhat expected. Autostart is based on the desktop entry spec, which says "The Exec key must contain a command line. A command line consists of an executable program optionally followed by one or more arguments.". Consequently shell features like && are not supported there. The fact that it used to work was relying on an implementation detail in Plasma > Using as an app call with a more complicated command "amixer -c 0 sset Front unmute" does NOT work. Not sure what's going on there, as far as I can tell it's a valid Exec line. Perhaps the command is executed properly but due to circumstances it does not have the desired effect
Setting the program to "sleep 5 && touch /tmp/asdf" is expected to fail. The desktop entry spec says it must be a program with args. Not a bash line. setting it to `/bin/sh -c "sleep 5 ; touch /tmp/foo"` would work. With the systemd boot we share some components, which is normally a good thing, but it means aherence to the actual autostart spec. Maybe I should redo the UI to be clearer. I don't understand why the amixer command fails.
Thanks for the feedback guys. The UI should definitely be altered in a way that makes it clear what you can use. Or at the very least fail in a way to make it more clear what's going on. Right now there is no way, even for experienced people, to fix or even notice this problem. As you guys said yourself, this explains the chained command executing problem but not the other two. When I put the also mixer call in a script, and call that as an login script entry, it also doesn't work with systemd starup.
Sort of works here. I can see the program is launched and bails with "unable to find simple control 'Front'. >When I put the also mixer call in a script, and call that as an login script entry, it also doesn't work with systemd starup. An untested theory is some other systemd unit is also adjusting sounds. We're opting in to more shared systems. pulseaudio "journalctl --user -b" would tell you more.
> An untested theory is some other systemd unit is also adjusting sounds. > We're opting in to more shared systems. pulseaudio > > "journalctl --user -b" would tell you more. That might be it, even tho I can't really tell from the logs cause there is no direct conflict or error. I just see that pipewire gets called AFTER the generated systemd startup call: (autostarter is my super creative name ;) of the auto start script btw) > Jul 13 14:21:47 main plasma_session[1285]: org.kde.plasma.session: Starting autostart service "/home/andy/.config/autostart/autostarter.desktop" ("/home/andy/daten/daten/dokumente/eigene_programme/scripts/autostar> > Jul 13 14:21:47 main systemd[695]: Started PipeWire Multimedia Service. > Jul 13 14:21:47 main systemd[695]: Started PipeWire PulseAudio. That's why I added "sleep 5s" to begin with but in the systemd startup context it doesn't seem to work for reasons unknown to me. This means that startup scripts are now restricted by the systemd environment in general tho, which is a regression/downgrade imo. I think we can close this bug then but there should be some documentation/error handling happening when new autostart scripts are created. Thanks for your help guys!