| Summary: | Autostart scripts (commands) not executing | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Andy <sxxe> |
| Component: | kcm_autostart | Assignee: | Nicolas Fella <nicolas.fella> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | kde, plasma-bugs-null |
| Priority: | NOR | ||
| Version First Reported In: | 5.25.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Andy
2022-07-13 08:36:56 UTC
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! |