What is strange to me is that the daemon creates that file while pamac is already running. IMHO, pamac (CLI) should wait if pamac-daemon is already into something and has acquired the lock, but pamac-daemon should not be allowed to acquire the lock if pamac CLI is already running.
Furthermore, when this happens the daemon seems to hang, with the lock never being released.
There is also an additional problem when pamac (CLI) gets terminated and it is leaving around a directory in /var/lib/pacman/sync/ as /var/lib/pacman/sync/dowload-<hash> for which it loudly complains about in further invokations and that must be removed manually.
Today my routine is:
- I know there is a testing update so I
pamac upgrade - pamac syncs the db, shows the upgrades, asks for approval
- I say yes, pamac starts downloading some two GBs which takes time
- When it gets halfway the daemon takes the lock and terminates it
- The daemon hangs and never releases the lock
- I kill the daemon remove the lock
- Try again with
pamac upgrade - The daemon restarts, repeat
Now the obvious solution is systemctl stop pamac-daemon before using pamac from the CLI, but this shouldn’t be necessary. Furthermore, throwing away GBs this way when you are under a metered connection is nasty.
Even systemctl stop pamac-daemon does not help. Even with that while pamac CLI is doing its work, pamac-daemon is restarted when the CLI tool is halfway and terminates pamac CLI and then hangs (ps shows it to be sleeping in Ssl state). Even if manually relaunched, pamac cli waits waits waits then says Transaction cancelled: Timeout expired. and exits.
Weirdly enough, switching to a faster internet connection fixed the issue, letting pamac (CLI) complete its job before the daemon kicking in.