For years, I have had a conky configuration that is started via KDE autostart at login. So far everything has worked without any problems. Since the stable update on November 30th, conky is started twice. Once with my desired configuration (top part in the picture) and once with the standard configuration (right in the picture).
I have deleted the KDE autostart and now start conky via user unit. The result is the same, conky is started twice.
When I run the script in the console, it runs as expected.
In Kde I have inserted it as autostart (see picture). When I log out and log in again, conky starts twice.
2nd command /usr/bin/conky --daemonize --pause=1 does not specify a configuration file and will use default conky configuration file ~/.config/conky/conky.conf
I suggest remove one of the two autostart commands so that only one conky is loaded at startup
If the default configuration is loaded, move and rename the custom configuration /home/mepi/.conky/.my_conky_config to /home/mepi/.config/conky/conky.conf
As Kde is set up in such a way that the previous status is restored when you log in again (previously opened programs). I have just tested the following with deleted autostart:
When I turn off autostart and kill all running conky tasks, conky did not start at login/reboot!
When I turn off autostart and perform the following script, conky starts with my configuration. After a new login/reboot conky starts with default configuration. See my previous post.
I think this is the plan - replace that with your conky start script.
I tried to use Session Restore a while back, I just wanted to do a quick restart, but you have to restart first to enable it… and once it was enabled it did go a little crazy.
I remember now that the ‘default’ conky launched too, so I had to run my script to clean them up.
If a user wanted to load multiple conky’s with a script, they could either delete the default configuration or use one conky config in default location as a fallback
If a user wants to load one conky only at login, and uses the default location instead of a custom location, the autostart command does not need to specify location of configuration file
just one less thing that could go wrong in the autostart command, also easier to remedy if it does go wrong in future