So, I dug a little deeper and found a source code inside libpamac library, which launches the exact (troublesome) command as shown in htop. When I studied that code, I came to a conclusion, that the libpamac.check_updates (which launches the pamac checkupdates ... command) is launched automatically when local or sync db are changed. So you just need to create the libpamc.UpdatesChecker object and it automatically checks the db files and launches update command if dbs are changed. This could be troublesome, if more UpdateChecker objects are created or not properly destroyed, because if db file is changed all the UpdateChecker instances will try to check updates.
So I needed to know where the UpdatesChecker instance is used. After some time I found the usage in pamac tray icon code and pamac gnome-shell extension. I’m using the extension, so I tried to investigate the extension more.
I edited the extension code and added a log before the UpdateChecker creation to see, when it is created. Restarted gnome-shell, checked if the log worked. Yes it worked there was a log in journalctl:
jun 04 22:09:55 jeZenBook gnome-shell[133535]: UpdatesChecker creation
Then I periodically checked for packages with the sudo pacman -Syu command and monitored pamac processes in htop. Everything worked as expected for a day, even after sleep/wake up. After every updates checking with pacman only one pamac checkupdates ... command was launched.
Until now. I checked again some time ago and there were more pamac checkupdate ... processes. I checked journalctl and there it was.
jnn 05 21:42:25 jeZenBook gnome-shell[133535]: UpdatesChecker creation
Gnome-shell created UpdatesChecker again. Without restarting the shell or any other action.
So my theory is. Gnome-shell sometimes for some reasons restarts extensions. The previously created UpdatesChecker instance isn’t properly destroyed and new one is created. Both of the instances are monitoring db files and when the files are changed, both are running the pamac checkupdate ... command. I don’t know yet, if before the new instance creation, destroy is called on the one before, so I planted more logs into the code and if it is properly destroyed, I think the UpdateChecker instance destruction (somewhere here) should solve the problem.
I’ll try to debug more and if I find something more, I’ll report.