I am recently experiencing an issue with pamac, where while pamac is running from the CLI (e.g., pamac upgrade) it gets terminated (typically while downloading packages) and hangs on restart because “another package manager is running”.
This looks a lot like pamac the daemon terminating pamac the command line utility, that seems to me a priority inversion. If the administrator is explicitly doing something on the CLI, it should be the daemon to wait.
Furthermore, when this happens there seems to be nothing to do. Waiting (for ages) does not help at all.
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.
I think you experience this old issue. Notice however that the daemon is the actual package manager, the front-end is merely to interact with the user. That is, the daemon will do its job - it upgrades the system successfully unless the user restarts or stops the daemon in the middle of its job. Seems to me you were lucky not to end up with a broken system.
So far it isn’t clear what causes the issue. Could be related to the connection, could be something else. If one could find out what it is one would be able to fix it.
On slow/metered connection it’s best to always refresh your mirrors before updating. And while you lose the packages that didn’t complete their downloads if the update gets interrupted, those that did are kept in cache and won’t be downloaded again. Just repeat the update until it’s completed and don’t reboot.
Another big GB waster is pamac’s default update checker that is set to 6h. At roughly 25MB per check it wastes 3GB per month. Set it to weekly/monthly in the Preferences.
Alternatively, disable it completely, go to Stable Updates - Manjaro Linux Forum , login in to the forum and hit the little bell icon on the top right and you’ll get a notification whenever a new update has been announced.
Just to put this issue into perspective for ‘fibre people’; most users in Africa are on prepaid SIM at roughly a $/GB.
Your topic has been moved to an appropriate Support category – Please remember to do this, in future.
Avoid successive posts – Instead, if there are no posts since your last post, please edit that post to add additional content.
As has already been mentioned, the cause of the condition you describe is yet to be identified; being that it’s rather intermittent in nature, it’s clearly difficult to track.
For those who must use a GUI package manager, it has been suggested to use octopi instead, to replace pamac-manager (Add/Remove Software).
The presence of the file /var/lib/pacman/db.lck will prevent more than one instance of the package manager.
The package manager engine - libalpm is provided by pacman.
The Manjaro package manager pamac honor the presence of that file and will refuse to execute as long as it exist.
Unlike an Arch Linux system - Manjaro’s package manager comes with timers and services which execute mundane maintenance tasks in the background.
pamac timers and services
$ ls -l /usr/lib/systemd/system/pamac*
-rw-r--r-- 1 root root 108 18 dec 2025 /usr/lib/systemd/system/pamac-cleancache.service
-rw-r--r-- 1 root root 140 18 dec 2025 /usr/lib/systemd/system/pamac-cleancache.timer
-rw-r--r-- 1 root root 118 18 dec 2025 /usr/lib/systemd/system/pamac-daemon.service
-rw-r--r-- 1 root root 205 18 dec 2025 /usr/lib/systemd/system/pamac-mirrorlist.service
-rw-r--r-- 1 root root 157 18 dec 2025 /usr/lib/systemd/system/pamac-mirrorlist.timer
-rw-r--r-- 1 root root 813 13 dec 2025 /usr/lib/systemd/system/pamac-offline-upgrade.service
If your launch of console to run pamac update, happens to be colliding with the background service creating the lock - then the pamac update command will terminate because of the lock file.
The lock will be created even for the task of checking if the metadata has been updated.
It has been seen that the GUI terminates abruptly but the background process continues.
When the process gets terminated during download - nothing bad happens but you will need to manually remove the lock.
The really nasty stuff may happen when the package manager is shorted during a transaction… because then the post transaction hooks (if any) is not run and the system - worst case scenario - is rendered unbootable.
From user perspective I experience the same issue. The pamac update within terminal runs into a process terminated situation. I am pretty sure this is a simple timeout issue in the pamac-cli and it terminates the process due to a “long running” operation blocking the pamacd service.
From my experience the update finishes just fine and leaving pamac doing its thing for 5 to 10 Minutes helps. A followup pamac update/upgrade should show “no updates available” (and no other process running).