Fix pacman "error: failed to init transaction (unable to lock database)"

pgrep -a 'pacman|yay|paru|pamac|packagekitd'
# only if the command above prints nothing:
sudo rm /var/lib/pacman/db.lck
sudo pacman -Syu

What the error means

$ sudo pacman -Syu
:: Synchronizing package databases...
error: failed to synchronize all databases (unable to lock database)

or, when installing:

error: failed to init transaction (unable to lock database)
error: could not lock database: File exists
  if you're sure a package manager is not already running, you
  can remove /var/lib/pacman/db.lck

pacman creates /var/lib/pacman/db.lck when it starts a transaction and deletes it when it finishes, so two instances never change the package database at the same time. Unlike dpkg's kernel locks, this is a plain file: if pacman dies without cleaning up, the file stays and every later run refuses to start. The message is pacman telling you it cannot distinguish "another pacman is running" from "a previous pacman crashed", so you have to check.

Cause 1: another package manager really is running

Look for anything that uses libalpm, the pacman library:

pgrep -a 'pacman|yay|paru|pamac|packagekitd|discover'
sudo fuser -v /var/lib/pacman/db.lck

Common culprits:

• An yay or paru run in another terminal, waiting at a prompt or still building an AUR package. The build phase runs as your user, and the helper calls pacman when it installs; both stages can be the one holding the lock.
• Pamac (Manjaro's "Add/Remove Software") checking for updates in the background.
• KDE Discover or GNOME Software through PackageKit, if packagekit is installed.
• A timer or script you set up for automatic updates or pacman -Sy checks (use checkupdates from pacman-contrib instead; it uses a separate database and no lock).

Wait for it to finish or close it normally. Do not delete the lock while it runs.

Cause 2: a stale lock from an interrupted run

If nothing is running, the lock is stale. Remove it:

sudo rm /var/lib/pacman/db.lck

This is the documented fix and is safe when no other instance is active. If rm says the file does not exist but the error persists, the filesystem may be read-only (check mount | grep ' / '), or pacman is pointed at a different root with --root or --dbpath.

Step after removing the lock: check the interrupted upgrade

A stale lock means the last transaction stopped part-way. Finish it, then verify:

sudo pacman -Syu
# list packages whose files are missing or modified
sudo pacman -Qkk 2>/dev/null | grep -v ' 0 altered files'
# reinstall any damaged package
sudo pacman -S PACKAGE

If the upgrade was interrupted during a kernel or initramfs step, regenerate the boot images with sudo mkinitcpio -P (on distros that use dracut, such as current EndeavourOS, use their rebuild command, for example sudo reinstall-kernels) before rebooting. If the system no longer boots, boot the Arch ISO, mount your root at /mnt and run the upgrade from outside:

mount /dev/ROOT-PARTITION /mnt
mount /dev/EFI-PARTITION /mnt/boot    # match your own layout
rm -f /mnt/var/lib/pacman/db.lck
arch-chroot /mnt
pacman -Syu
mkinitcpio -P

The Arch install guide shows the mounting steps in more detail.

Cause 3: running pacman without root

Without sudo, pacman cannot create the lock and normally says so directly:

error: you cannot perform this operation unless you are root.

Rerun with sudo. Do not run yay or paru with sudo; they ask for it themselves when needed.

Cause 4: pacman is hung

Occasionally pacman really is running but stuck: waiting on a slow or dead mirror, blocked on a hook such as a DKMS build, or waiting for input in a terminal you cannot find. Find out what it is doing before you stop it:

ps -o pid,etime,stat,cmd -C pacman
sudo cat /proc/$(pgrep -x pacman)/wchan; echo
ps -ef --forest | grep -A4 '[p]acman'

Child processes under pacman (for example dkms, mkinitcpio or gpg) show which step it is on. A download stuck at 0 B/s for minutes is safe to cancel with Ctrl+C or sudo kill PID: nothing has been installed yet. Avoid killing it during the "upgrading" or "running post-transaction hooks" stages; if you have to, use a normal kill (not kill -9), then remove the lock and follow the verification steps above. Arch's own advice on this is in the pacman article on the ArchWiki.

Distro-specific notes

• Manjaro: Pamac has its own option, pamac update from the terminal, but uses the same lock. If Pamac's GUI reports "Failed to synchronize databases", close it, check with pgrep -a pamac, then remove the lock as above.
• EndeavourOS, CachyOS and other Arch-based distros: identical behaviour; their update notifiers can hold the lock briefly.
• SteamOS: the root filesystem is read-only by default and pacman is not meant for normal use there.
• Debian/Ubuntu have the equivalent error "Could not get lock /var/lib/dpkg/lock-frontend", but there you should not delete lock files. Fedora's DNF5 waits for its lock, and zypper on openSUSE reports "System management is locked by the application with pid".

How to prevent it

• Upgrade from a terminal you will not close; over SSH use tmux.
• Do not press Ctrl+C during "checking package integrity" or "upgrading" stages.
• Avoid running a GUI updater and a terminal upgrade at the same time.
• Use checkupdates instead of pacman -Sy in scripts or status bars; partial -Sy runs also lead to dependency breakage. The Arch Linux reference lists other maintenance habits.
• If the next run fails with a signature error, see "invalid or corrupted package (PGP signature)".

Frequently asked questions