Conky not autostarting anymore in Plasma 5.24

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

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:


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 >>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.

Either use a start script like that:

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


modify application command in GUI:

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


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.

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.

Maybe that is the issue, maybe this is their desired behavior.

Without a bug report nothing can change though.


In my case, an autostart script I have seems to be working, but conky doesn’t even start.
When manually starting from terminal, it exits with Floating point exception (core dumped).

Prior to 5.24, everything worked fine. I use conky-cairo-no-nvidia, but I also tried with conky.

I think you should open a new topic for that problem as it is completely different. conky didn’t crash with corefiles here.
you could give conky-git a try though, it gave me 1.12.3pre instead of 1.12.2pre that is in the repos (it didn’t have any influence on my problem though)

will check on Saturday if KDE and/or conky already have bug reports and take care of that. Won’t have time to check how to report bugs in those projects until then.

You’re right. I’ll wait till the weekend and maybe I’ll open a new topic.

I had issues with 2 machines last update, both use kde, but only one uses conky.

My main machine using conky would not load the conkies, but the autostart loaded my menu I made in python to control them.
The machine not using conky, removed everything from the desktop except the welcome menu.
idk if related or not just sayin’

I used downgrade by date

Super nice easy thing to use to get everything back, but I’ll watch here for when I should attempt update again.

Much easier solution:
add -q option

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.