Conky not autostarting anymore in Plasma 5.24

just switched to testing and updated everything, now conky won’t autostart anymore.
It runs fine if I run it in terminal or from the menu, but it won’t start as startup application, and it won’t start in a loginscript (not even with a sleep before the actual start).
All my other autostart things (yakuake, latte-dock, ckb-next) work fine.

I wrote debug informations into my script, something seems majorly broken:
My script that I added as an autostart application in the Plasma System Settings:

#!/bin/bash
date=$(date)
echo "started script $(date)" >> conkydebug.txt
echo "sleeping 10s $(date)" >> conkydebug.txt
sleep 10s 
echo "starting conky $(date)" >> /conkydebug.txt
/usr/bin/conky
echo "started conky $(date)" >> conkydebug.txt

the debug-log looks as follows:

started script Di 8. Feb 19:30:04 CET 2022
sleeping 10s Di 8. Feb 19:30:04 CET 2022
starting conky Di 8. Feb 19:30:14 CET 2022
started conky Di 8. Feb 19:30:14 CET 2022

I could even see the script still sleeping in ps -x running in yakuake, but conky still wasn’t running once the script finished.

How does one autostart conky in KDE Plasma after 5.24?

I downgraded to stable’s KDE 5.23 and conky is starting as expected, even with the script …

1 Like

Same here.

I use conky manager, i checked there and noticed the widgets to load where all disabled.
I disabled autostart, re-enabled my widgets and autostart (all this re-writes ~/.conky/conky-startup.sh) and it solved this issue.
So, conky is running but loading nothing, check your startup script for lines like:

conky -c "$HOME/.conky/Process Panel"

thanks for the suggestion, but I don’t use conky-manager. My complete startup - script is posted above and it is working in Plasma 5.23.
My config is in it’s default location .conkyrc - it is not necessary to specify that with -c.
(Also, in Plasma 5.23, that worked with simply adding conky itself as startup application)

Just for the sake of trying, I gave conky-manager a go, but it is so outdated that it wouldn’t even read my lua-config (which is the default conky config language for some years now, I had to convert it some years ago because conky wouldn’t read the old-style config anymore)
The widget-presets present in conky-manager won’t autostart either (yes, the script generated by it has it added as -c)

whats your conky-version? mine says:

conky --version
conky 1.12.2_pre compiled 2021-04-26 for Linux x86_64

it is installed from the extra-repository.

Same here, Just as @BS86 . I don’t use conky-manager, and my conky does not autostart any more. It displays normally when launched from CLI after Plasma 5.24 has launched.
My Conky version is also the same as yours.

1 Like

I use conky-git:

conky --version
conky 1.12.2_pre compiled 2021-03-28 for Linux x86_64

and conky-manager2-git

conky-git gave me

conky --version
conky 1.12.3_pre compiled 2022-02-09 for Linux x86_64

but it didn’t change anything, neither conky directly autostarting or using the startup-script worked.

conky-manager2-git won’t compile due to some patches failing. Given that it was last updated in AUR in 2020 but the repo had some work done since then, I guess it needs to be updated or be compiled directly from the repo - might look into that later to check if the script generated with it does something differently.

Edit: conky-manager2 does things differently in the script:

#!/bin/sh

if [ "$DESKTOP_SESSION" = "plasma" ]; then 
   sleep 5s
   killall conky
   cd "$HOME/.conky/PRESET"
   conky -c "$HOME/.conky/PRESET/presetfile" &
   exit 0
fi

but it still won’t autostart conky …

Well… Plasma has widget, doesn’t it ? So not a real solution but a kind of workaround… I have switched to widgets. Fine for my specific current needs
Screenshot

widgets take way too much screenspace to display everything I want. I just start conky manually for the time being.
conky

It might not be relevant to your problem as it is dependent on how you start conky, but my conky is in the KDE autostart applications and almost never (although not never) starts from there. Most days I need to start it from the KDE menu, but then it starts normally.

For the truly lazy option - create a .desktop file to launch your conky with, and that will fire it off with a click. Of course, depending on your DEs capabilities, it might also be an alternative way to autostart (some DEs react to the placement of .desktop files in a specific directory).

Good luck - I can’t imagine widgets coming close to my conkys either! :grin:

Agree.

I have clock, weather, cpu & gpu temps, mem usage, cpu %, network bandwidth on my panel.

All other system info on your conky I get from btop with a shortcut, when I need it, but this stuff doesn’t change much.

thats what I am currently doing while autostart is broken.

well, KDE goes that road. The GUI actually creates files in ~/.config/autostart/ - I see no difference in these files, neither in editor nor with file nor with ls -l
The autostart-file is started correctly, that’s what I tried to check with my “debug-information” - it just doesn’t run conky. If I run that file manually, conky starts.

ok, NOW my brain just exploded.

I changed the script of my first post, because I realized I write a lot of debug information, but none that conky might ouptput.
so I changed

/usr/bin/conky

to

/usr/bin/conky >>conky.txt 2>&1 

and with THAT conky autostarts again.

With only that:

/usr/bin/conky >>conky.txt

it still won’t work …

but that:

/usr/bin/conky >>/dev/null 2>&1 

still works. What the …

@pierrep56 can you check if that script added as startup application starts conky for you, too? For me this works.

Solution:
Either use a start script like that:

#!/bin/bash
#sleep 3s  #optional for slow systems
/usr/bin/conky >>/dev/null 2>&1 

or

modify application command in GUI:
conky_solution

Edit: @pierrep56 edited the minimal working script again to not write anything, still works
Edit2: What also works: Adding >>/dev/null 2>&1 to the command-entry that KDE generates, see screenshot
Edit3: Formatted the post to make the solution more prominent for future reference

3 Likes

Just as a datapoint: no issue with conky on Plasma 5.24 here. Starts as before by just having it in the plasma autostart items. The app entry is the standard conky --daemonize --pause=1.

1 Like

do you have any special conky from AUR installed or the one from the repo?

Just to add to my other post:

/usr/bin/conky >>conky.txt

as well as

/usr/bin/conky >conky.txt

created the file but only printed an empty line into it. (i deleted the file after each try)
It looks like conky didn’t even try to start. >>conky.txt 2>&1 created the file and contained only the normal output that you also get in terminal when starting conky.

I am not sure why the >>/dev/null 2>&1, especially the 2>&1 part fix the problem. If anyone could clarify that, I would be really glad. @jonathon do you maybe know something that might help solve that mystery?

All I have installed is the extra/conky package and I never did anything special but customizing the ~/.conkyrc.

That doesn’t produce any output in the file here either. When I start with conky in the terminal I see:

conky: desktop window (2be) is root window
conky: window type - normal
conky: drawing to created window (0xe00002)
conky: drawing to double buffer

Have you checked if there’s any indication for an issue in the system log (e.g. journalctl -b) when you start conky? Did you try to start with a fresh config (removing ~/.conkyrc)? What if you give conky a little more wiggle room to start by increasing the --pause= param?

This routes both stderr and stdout to /dev/null … so for whatever reason Plasma startup cannot deal with both now.

I sometimes append >>/dev/null 2>&1 within custom application launchers, when something that works from the terminal won’t launch from a panel applet or using a shortcut.

only line: plasma_session[1322]: org.kde.plasma.session: Starting autostart service PATH TO TRIED METHOD but no errors or such

yes, no dice

had it up to 10, but also no dice. Also the sleep before starting conky was at 20 at the maximum, also no dice.

ok, so I should definitely keep that in mind for various problems. The thing is that conky apparently did not even try to write anything in the failed attempts, see:

Edit: I just tried:
conky --daemonize --pause=1 >conkylog.txt 2>conkyerror.txt
and conky still starts, but conkylog.txt contains nothing, conkyerror.txt contains:

conky: desktop window (2000019) is subwindow of root window (6c7)
conky: window type - normal
conky: drawing to created window (0x3600002)
conky: drawing to double buffer
conky: forked to background, pid is 29800

so I guess,

actually is: Plasma can’t deal with errors in autostart applications now as long as they are not printed anywhere.

In a terminal both stdout and stderr are output to stdout, so you can see the error messages.

This >>/dev/null 2>&1 appends stderr and stdout to a file (1) then disposes of it by piping it to /dev/null.

I think you can explicitly output each to a separate file for more advanced scripting.

[command] 1>stdout-log 2>/stderr-log

I suspect it is something to do with how Plasma startup handles stderr, but I don’t know enough to add much insight.

Could just be a regression that gets fixed later.

no output in stdout-log, the other output is in stderr-log
I guess it is wrong that conky outputs the regular log in stderr to start with.

lets hope that it is that way.