[SOLVED] Conky forks itself at login.

Leprotto · 2024-10-22 12:43:18

So on first launch we have 2⁰ conky process. After a reboot we have 2¹ conky processes. After a second reboot we have 2² conky. After a third 2³ conky and so on.
This is the craziest funny behavior i have ever seen in a program. If i didn't knew better i would think this is an intended joke.

Last edited by Leprotto (2024-10-23 13:35:28)

seth · 2024-10-22 13:43:32

https://bbs.archlinux.org/viewtopic.php?id=57855

1. what starts conky in general
2. what starts the particular conky processes (parenting PID)
3. reboot, not a mere session restart? Ie. the PIDs are all new?

Leprotto · 2024-10-22 16:07:07

Now that you mentioned it, i just checked and a session restart is enough to trigger the behavior.
I don't really know what starts the process. There are some symstemd logs in the journal, but i don't have any service set, nor a [service] field in the config.

journald.log
.conkyrc

seth · 2024-10-22 18:14:57

ott 22 14:27:54 ArchPC systemd[942]: Started conky.
ott 22 14:27:54 ArchPC systemd[942]: Started conky.
ott 22 14:27:54 ArchPC udisksd[1520]: FUSE exfat 1.4.0 (libfuse3)
ott 22 14:27:54 ArchPC udisksd[1520]: WARN: volume was not unmounted cleanly.
ott 22 14:27:54 ArchPC mount.exfat[1520]: volume was not unmounted cleanly
ott 22 14:27:54 ArchPC systemd[942]: Started conky.
ott 22 14:27:54 ArchPC systemd[942]: Finished KDE Session Restoration.
ott 22 14:27:54 ArchPC dbus-broker-launch[681]: Activation request for 'org.freedesktop.ModemManager1' failed: The systemd unit 'dbus-org.freedesktop.ModemManager1.service' could not be found.
ott 22 14:27:54 ArchPC kded6[1225]: kf.modemmanagerqt: Failed enumerating MM objects: "org.freedesktop.DBus.Error.NameHasNoOwner" 
                                     "Could not activate remote peer 'org.freedesktop.ModemManager1': activation request failed: unknown unit"
ott 22 14:27:54 ArchPC kded6[1225]: Known activities: QList("f2da818d-ddab-4862-bdaa-c68f5d725148")
ott 22 14:27:54 ArchPC udisksd[1029]: Mounted /dev/sdb1 at /run/media/fulvio/Disco Dati on behalf of uid 1000
ott 22 14:27:54 ArchPC kded6[1538]: xsettingsd: Loaded 14 settings from /home/fulvio/.config/xsettingsd/xsettingsd.conf
ott 22 14:27:54 ArchPC kded6[1538]: xsettingsd: Created window 0xe00001 on screen 0 with timestamp 20444
ott 22 14:27:54 ArchPC kded6[1538]: xsettingsd: Selection _XSETTINGS_S0 is owned by 0x0
ott 22 14:27:54 ArchPC kded6[1538]: xsettingsd: Took ownership of selection _XSETTINGS_S0
ott 22 14:27:54 ArchPC kernel: EXT4-fs (sda): Using encoding defined by superblock: utf8-12.1.0 with flags 0x1
ott 22 14:27:54 ArchPC systemd[1]: Created slice Slice /system/dbus-:1.2-org.kde.kded.smart.
ott 22 14:27:54 ArchPC systemd[1]: Started dbus-:1.2-org.kde.kded.smart@0.service.
ott 22 14:27:54 ArchPC systemd[942]: Started conky.
ott 22 14:27:54 ArchPC systemd[942]: plasma-powerdevil.service: Scheduled restart job, restart counter is at 1.
ott 22 14:27:54 ArchPC systemd[942]: Starting Powerdevil...
ott 22 14:27:54 ArchPC udisksd[1029]: Mounted /dev/sda at /run/media/fulvio/GIOCHI on behalf of uid 1000
ott 22 14:27:54 ArchPC kernel: EXT4-fs (sda): mounted filesystem a3531c3c-7ecc-4f3d-a745-c289c4a22431 r/w with ordered data mode. Quota mode: none.
ott 22 14:27:54 ArchPC kded6[1225]: kf.bluezqt: PendingCall Error: "The name is not activatable"
ott 22 14:27:54 ArchPC org_kde_powerdevil[1551]: Starting libddcutil. library built Oct 20 2024 at 13:43:55. stdout_stderr_redirected=true
ott 22 14:27:54 ArchPC systemd[942]: Started conky.
ott 22 14:27:54 ArchPC systemd[942]: Started conky.
ott 22 14:27:54 ArchPC systemd[942]: Started conky.
ott 22 14:27:54 ArchPC systemd[942]: Started conky.

So looks like it's started as systemd user service(s)

systemctl --user list-units
loginctl session-status

Leprotto · 2024-10-22 20:10:21

So it seems there are indeed two conky services running. Now i've to find what it's starting them.

list
session

seth · 2024-10-22 20:16:01

systemctl status app-conky@1c5f3225fb9f4bd9982d86be7a40791d.service

but looks autogenerated, probably some https://wiki.archlinux.org/title/XDG_Autostart entries

Leprotto · 2024-10-22 21:28:26

This is the content of /etc/xdg/autostart

at-spi-dbus-bus.desktop       gnome-keyring-secrets.desktop      org.kde.kdeconnect.daemon.desktop                polychromatic-autostart.desktop
baloo_file.desktop            gnome-keyring-ssh.desktop          org.kde.plasma-fallback-session-restore.desktop  powerdevil.desktop
geoclue-demo-agent.desktop    kaccess.desktop                    org.kde.plasmashell.desktop                      xapp-sn-watcher.desktop
gmenudbusmenuproxy.desktop    kglobalacceld.desktop              pam_kwallet_init.desktop                         xembedsniproxy.desktop
gnome-keyring-pkcs11.desktop  org.kde.discover.notifier.desktop  polkit-kde-authentication-agent-1.desktop

seth · 2024-10-22 21:33:49

And ~/.config/autostart ?
Did you check the service status? (Maybe there's a comment about the origin)

Leprotto · 2024-10-22 22:13:55

seth wrote:

And ~/.config/autostart ?
Did you check the service status? (Maybe there's a comment about the origin)

Nope.
I think the answer is quite obvious indeed. Since conky acts as a desktop app so, whenever you restart the session, Plasma will just restore its previous state. This doesn't explain why it keeps forking itself though, but maybe with a proper starting/closing script i could make it behave correctly.

ploub · 2024-10-23 06:22:06

In System Settings, if you have conky in Autostart and in Desktop Session you have session restore "on last logout" you will get a new instance of conky on each new login. If this is the case either remove conky from autostart or change the session restore option.
Not sure where the systemd service file comes in though - maybe this will start yet another instance?

Leprotto · 2024-10-23 11:11:06

Yes but it's not in autostart.

seth · 2024-10-23 12:00:23

If you give it a fresh start, ie. configure to start w/ an empty session and then start restoring the session from there, does it still happen?
Another thing is to look out for https://wiki.archlinux.org/title/Core_d … _core_dump
I could imagine conky crashing on exit, restarting and KDE capturing and restoring both instances.

Leprotto · 2024-10-23 13:33:52

I finally fixed it adding conky in the ignore field in System Settings --> Session Restore.
I still haven't found what starts conky at login, but it doesn't matter anymore at this point.

Arch Linux

#1 2024-10-22 12:43:18

[SOLVED] Conky forks itself at login.

#2 2024-10-22 13:43:32

Re: [SOLVED] Conky forks itself at login.

#3 2024-10-22 16:07:07

Re: [SOLVED] Conky forks itself at login.

#4 2024-10-22 18:14:57

Re: [SOLVED] Conky forks itself at login.

#5 2024-10-22 20:10:21

Re: [SOLVED] Conky forks itself at login.

#6 2024-10-22 20:16:01

Re: [SOLVED] Conky forks itself at login.

#7 2024-10-22 21:28:26

Re: [SOLVED] Conky forks itself at login.

#8 2024-10-22 21:33:49

Re: [SOLVED] Conky forks itself at login.

#9 2024-10-22 22:13:55

Re: [SOLVED] Conky forks itself at login.

#10 2024-10-23 06:22:06

Re: [SOLVED] Conky forks itself at login.

#11 2024-10-23 11:11:06

Re: [SOLVED] Conky forks itself at login.

#12 2024-10-23 12:00:23

Re: [SOLVED] Conky forks itself at login.

#13 2024-10-23 13:33:52

Re: [SOLVED] Conky forks itself at login.

Board footer