I’ve just upgraded from KDE 5 to 6. I’m trying to setup a script to run when my PC boots. It worked fine in KDE 5, but now in KDE 6 the script doesn’t seem to work correctly.
After a reboot, the login script says “Not autostarted yet”
I can click properties icon on the script and it says to open with Kate. I’ve tried setting to “Is executable” but this still doesn’t change anything.
I also tried a logout script but this doesn’t appear to do anything either.
Can someone help?
You can try to run the .desktop file in ~/.config/autostart from, say, dolphin and get more info. In my failure case, it put “Exec=‘/usr/bin/veracrypt --background-task’” in the .desktop file, and the gratuitous single quotes make it fail to start. Manually edit the file to make it work if malformed.
I worked around the problem for now by starting the application I need at login using a systemd service.
I have exactly the same issue. I updated from KDE5 to KDE6 about 4 days ago and all my login-scripts in ~/.config/plasma-workspace/env/*.sh are now ommitted, even though they are listed in systemsettings under autostart/login-scripts.
Permissions have +x bit set and shebang is #!/bin/sh.
Edit:
So I tracked down where the env scripts are supposed to get loaded (plasma-workspace/startkde/startplasma.cpp:305 - Unfortunately, I can’t post URLs here with my fresh account.). This looks all fine to me and this code segment has not changed for some years, according to git blame. I think, the root of the cause might not come from “startplasma” but on how it is started. Maybe the wayland-session has changed from 5 to 6?
Edit2:
Ok, plasma-workspace/startkde/startplasma-wayland.cpp is looking also fine and calls plasma-workspace/startkde/startplasma.cpp::runEnvironmentScripts() correctly for some years too. I don’t see any obvious mistake here.
Edit3:
Further backtrace: /usr/share/wayland-session/plasmawayland.desktop, that is loaded by sddm, also looks absolutely fine when compared between KDE5 and KDE6.
I honestly do not see an obvious bug anywhere. Yet, $HOME/.config/plasma-workspace/env/*sh files are not sourced at all.
Wayland (Neon) fresh install here.
KDE Plasma 6.02
Frameworks 6.0.0
Script placed in
$HOME/.config/plasma-workspace/env/*sh
automagically appeared under the new category Pre-startup Scripts in System Settings > Autostart
files work - don’t even have to be executable - just a shebang is enough
they are sourced by
/usr/lib/x86_64-linux-gnu/libexec/plasma-sourceenv.sh
which is called by startplasma-wayland and run in a full user environment
As far as Login Scripts go (manually added with Add... button), they do need to be executable, and get a .desktop file created in $HOME/.config/autostart . If I remove or chmod -x the executable, I get a useful warning in the journal from systemd-xdg-autostart-generator which gives No such file or directory or Permission denied.
I have the same problem for all .desktop files in the $HOME/.config/autostart folder. They do not launch at startup.
I cannot find any useful solution to get them work and need to start them manually… after every boot. I would be very glad with a working solution/workaround.
They do not launch at startup.
OK. - I’m all out of magic smoke in my ball…
What does the journal say about them?
I’m not a terminal hero, but I checked “journalctl -b” and it sais for example:
kf.kio.core: Url QUrl(“file:///home/kasper/.config/autostart/synology-drive-autostart.desktop”) already represents a local file, cancelling job
That is Dolphin…
Dolphin happens long time after login…
useless.
You essentially posted the middle page of a book when you are having trouble finding page 1
What is in the synology script file?
What is in the 2 desktop files?
What merde is responsible for true, actions!!! and urly!!! ?
What other files are in that directory?
ls -ln ~/.config/autostart
Arch Linux wayland session here.
KDE Plasma: 6.0.2
Framework: 6.0.0
Scripts in $HOME/.config/plasma-workspace/env/*sh are also automagically discovered in Pre-startup Scripts in System Settings > Autostart. No issues here.
/usr/lib/plasma-sourceenv.sh present and does not differ to the KDE5 version.
Scripts in $HOME/.config/plasma-workspace/env/*sh are completely ignored. $HOME/.config/autostart/*.desktop works flawless however.
Marking a testscript non-executable gives me the following results after a reboot:
journalctl -b | grep auto
Mär 20 13:55:55 defiant kernel: mem auto-init: stack:all(zero), heap alloc:on, heap free:off
Mär 20 13:55:55 defiant kernel: Loaded X.509 cert 'Build time autogenerated kernel key: REDACTED'
Mär 20 13:55:55 defiant kernel: xor: automatically using best checksumming function avx
Mär 20 13:55:55 defiant kernel: BTRFS info (device dm-3): auto enabling async discard
Mär 20 13:55:55 defiant systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
Mär 20 13:55:56 defiant kernel: input: gpio-keys as /devices/platform/MSHW0040:00/gpio-keys.1.auto/input/input38
Mär 20 13:55:56 defiant kernel: input: gpio-keys as /devices/platform/MSHW0040:00/gpio-keys.2.auto/input/input39
Mär 20 13:55:56 defiant kernel: snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC274: line_outs=1 (0x1b/0x0/0x0/0x0/0x0) type:speaker
Mär 20 13:56:03 defiant systemd[1]: Started auto-cpufreq - Automatic CPU speed & power optimizer for Linux.
Mär 20 13:56:05 defiant sddm-helper[2775]: pam_kwallet5(sddm-autologin:auth): pam_kwallet5: pam_sm_authenticate
Mär 20 13:56:05 defiant sddm-helper[2775]: pam_kwallet5(sddm-autologin:auth): pam_kwallet5: Couldn't get password (it is empty)
Mär 20 13:56:05 defiant sddm-helper[2775]: pam_kwallet5(sddm-autologin:auth): pam_kwallet5: Empty or missing password, doing nothing
Mär 20 13:56:05 defiant sddm-helper[2775]: pam_kwallet5(sddm-autologin:setcred): pam_kwallet5: pam_sm_setcred
Mär 20 13:56:05 defiant sddm-helper[2775]: pam_unix(sddm-autologin:session): session opened for user klaus(uid=1000) by klaus(uid=0)
Mär 20 13:56:05 defiant NetworkManager[984]: <info> [1710939365.4241] policy: auto-activating connection 'eduroam' (REDACTED)
Mär 20 13:56:05 defiant sddm-helper[2775]: pam_kwallet5(sddm-autologin:session): pam_kwallet5: pam_sm_open_session
Mär 20 13:56:05 defiant sddm-helper[2775]: pam_kwallet5(sddm-autologin:session): pam_kwallet5: open_session called without kwallet5_key
Mär 20 13:56:07 defiant systemd[2807]: /run/user/1000/systemd/generator.late/app-org.telegram.desktop@autostart.service:18: WorkingDirectory= path is not absolute, ignoring:
Mär 20 13:56:07 defiant systemd[2807]: /run/user/1000/systemd/generator.late/app-io.element.Element@autostart.service:18: WorkingDirectory= path is not absolute, ignoring:
Mär 20 13:56:07 defiant systemd[2807]: /run/user/1000/systemd/generator.late/app-emacs@autostart.service:18: WorkingDirectory= path is not absolute, ignoring:
Mär 20 13:56:07 defiant kwin_wayland[2867]: No backend specified, automatically choosing drm
Mär 20 13:56:10 defiant NetworkManager[984]: <info> [1710939370.9156] policy: auto-activating connection 'eduroam' (REDACTED)
Mär 20 13:56:11 defiant systemd[2807]: Starting org.kde.kclockd-autostart...
Mär 20 13:56:11 defiant systemd[2807]: app-at\x2dspi\x2ddbus\x2dbus@autostart.service: Skipped due to 'exec-condition'.
Mär 20 13:56:11 defiant systemd[2807]: app-gnome\x2dkeyring\x2dpkcs11@autostart.service: Skipped due to 'exec-condition'.
Mär 20 13:56:11 defiant systemd[2807]: app-gnome\x2dkeyring\x2dsecrets@autostart.service: Skipped due to 'exec-condition'.
Mär 20 13:56:11 defiant systemd[2807]: app-gnome\x2dkeyring\x2dssh@autostart.service: Skipped due to 'exec-condition'.
Mär 20 13:56:11 defiant systemd[2807]: Started org.kde.kclockd-autostart.
Mär 20 13:56:11 defiant systemd[2807]: app-kalarm.autostart@autostart.service: Skipped due to 'exec-condition'.
Mär 20 13:56:11 defiant systemd[2807]: app-konqy_preload@autostart.service: Skipped due to 'exec-condition'.
Mär 20 13:56:11 defiant systemd[2807]: Reached target Startup of XDG autostart applications.
Mär 20 13:56:11 defiant kclockd[3343]: Requesting portal to run in the background and autostart...
Mär 20 13:56:13 defiant element-desktop[3330]: No update_base_url is defined: auto update is disabled
My “faulty” test.sh script (with missing +x flag) is nowhere mentioned. Env files are not sourced in my case
I was about to say that, the “solution info” is flawed.
/usr/lib/x86_64-linux-gnu/libexec/plasma-sourceenv.sh does not exist (on my system either), and at least I can not see what paths start-plasma hands off to the env in /usr/lib/plasma-sourceenv.sh (where it is now), so we have no way of confirming anything. I guess I could move the output from /dev/null to a file in plasma-sourceenv.sh to find out.
Logs could also help, but things have MOVED on plasma 6 for a lot of stuff.
One might assume the autostart has moved directory from $HOME/.config/plasma-workspace/env/*sh to $HOME/.config/autostart/*.desktop
But this is just me speculating and putting 1 and 1 together. I have not actually read any documentation.
The program scans
$HOME/.config/autostart/for applications and login scripts,$HOME/.config/plasma-workspace/envfor pre-startup scripts and$HOME/.config/plasma-workspace/shutdownfor logout scripts to check what programs and scripts are already there and displays them. It allows you to manage them easily.
Pre-startup scripts are run earlier and can be used to set environment variables.
Ref:
https://docs.kde.org/stable5/en/plasma-workspace/kcontrol/autostart/index.html
Ok, so what about plasma 6?
This is for migration from plasma 4 to 5.
Revision Plasma
5.20 (2021-04-05)
And/or are you saying scripts not being read from $HOME/.config/plasma-workspace/env/ is a bug?
Edit
So I did a little experiment here.
And it seems highly inconsistent, at least for pre-startup scripts in $HOME/.config/plasma-workspace/env/
I just added an echo line >> file in the for loop in /usr/lib/plasma-sourceenv.sh to see what was happening.
I added a script in $HOME/.config/plasma-workspace/env/, only added shebang and an echo >> file, did not make it executable and rebooted.
Both ran.
Sadly I messed up by adding 2 echo:s, with the second one containing $(date), but not appending with >> so I overwrote what the $i variable contained… 
Ok. So i tried again (after editing the echo to append), just by rebooting. The script ran but not the sourcing. ok, probably gets saved somewhere else, no biggie.
Added another .sh in $HOME/.config/plasma-workspace/env/ and rebooted.
ONLY the first script is ran, not the sourcing OR the second script.
But here comes the interesting part.
In the gui settings, in autostart, BOTH scripts are shown. But that could be as simple as the gui just looking in the directory.
Very inconsistent behavior.
Maybe adding everything in gui solves it all, but it seems the files in $HOME/.config/plasma-workspace/env/ SHOULD still be ran on plasma 6, but does not always seem to do so.
I only posted the lines containing autostart… the rest of “the book” are roughly 6.500 lines which I thought will only be distracting
Only 2 files in autostart (rest is in /etc/xdg/autostart/)
$ ls -ln ~/.config/autostart
total 4
-rwxrwxr-x 1 1000 1000 412 mrt 20 09:42 remmina-applet.desktop
lrwxrwxrwx 1 1000 1000 52 mrt 4 14:21 synology-drive-autostart.desktop → /opt/Synology/SynologyDrive/synology-drive-autostart
Little update: I just updated my Arch system today and my pre-login env scripts now work. No idea, if this was related of my messing around or if the updated fixed it (many KDE related programs were in the update but nothing hinting towards plasma. Plasmaversion etc did not change).
I never heard of the $HOME/.config/plasma-workspace/env/ and that directory is empty for me.
But I noticed in the past, that autostart scripts didnt launch at all, also on Plasma5, while apps work perfectly.
this has not changed with the Plasma6 update.
Example file:
$ cd ~/.config/autostart
$ cat gsettings
#!/usr/bin/env sh
gsettings set org.gnome.desktop.interface icon-theme Adwaita
$ cat gsettings.desktop
[Desktop Entry]
Exec=/var/home/user/.config/autostart/gsettings-adwaita
Icon=application-x-shellscript
Name=gsettings-adwaita
Type=Application
X-KDE-AutostartScript=true
I noticed this when I wanted to launch apps with a delay in the past, as Plasma seemed to launch them before launching the Panel, which is very bad UX. I wrote a script with some sleep intervals and the apps simply didnt launch at all.
Update: I recreated a script to start all my apps with some delay.
Still the same, the script was enabled in the GUI but does not start, nothing happens.
as no script is launching, my workaround is literally to use a .desktop file instead, placing it in ~/.config/autostart/
[Desktop Entry]
Exec=gsettings set org.gnome.desktop.interface icon-theme Adwaita
Name=Apply Adwaita icons to GNOME apps
Type=Application
Here to automatically make all GNOME apps look normal, even though Fedora breaking them on purpose.
and it works! I will convert all my scripts now, but for sure it is pretty insane. A workaround could likely also be to place all scripts in multiple Exec= lines in the same .desktop file.