Pacman, makepkg and yay all refuse to touch the package database while /var/lib/pacman/db.lck exists. Run pacman itself and it stops with “unable to lock database”. An AUR build in makepkg prints “Pacman is currently in use, please wait…” instead, yay says “There may be another Pacman instance running”, and both wait as long as the file exists. On Arch a reboot will not clear it either, because the lock lives on disk and nothing removes it at boot.
Usually the lock is real and another upgrade has to finish. When it is stale, deleting it is a one-line fix, but you need to tell the two cases apart first. A crash in the middle of an install can also leave a broken package behind, even after the lock is gone. We tested each message on Arch Linux with pacman 7.1 and yay 13.0.1, and on Manjaro 26.1.2 with Pamac 11.7.4, in October 2026.
Match the message to the tool
Each front end words the lock differently, which is why you’ll find the same problem under so many search phrases. What they all check is the same file, db.lck inside the pacman database path (/var/lib/pacman/ unless pacman-conf DBPath says otherwise):
| Tool | What it prints | What it does next |
|---|---|---|
pacman | error: failed to init transaction (unable to lock database) and error: could not lock database: File exists | Exits at once with status 1 |
makepkg -si | ==> Pacman is currently in use, please wait... | Checks every 3 seconds and repeats the line every 30 seconds, with no time limit |
yay | -> /var/lib/pacman/db.lck is present. and -> There may be another Pacman instance running. Waiting... | Waits until the file goes away |
| Pamac (Manjaro) | Waiting for another package manager to quit... | Checks 5 times a second and cancels after 5 minutes with Transaction cancelled: Timeout expired. |
pacman’s own error is the most useful of the four, because it names the file and tells you to remove it only “if you’re sure a package manager is not already running”. makepkg and yay never give up on their own, and Pamac gives up after 5 minutes. Our yay sat for 65 seconds on a stale lock and installed its package 2 seconds after we deleted the file from another shell, so you can fix the lock without cancelling the build you’re waiting on.
Check whether a package manager holds the lock
pacman keeps db.lck open for as long as it holds the lock, so fuser can tell a live lock from a stale one. It comes from psmisc, which the Arch base package already pulls in. Run it as root:
sudo fuser -v /var/lib/pacman/db.lckHere a second terminal was sitting at pacman’s Proceed with installation? [Y/n] prompt. fuser names the process, and that process is your answer:
USER PID ACCESS COMMAND
/var/lib/pacman/db.lck:
root 4987 F.... pacmanDon’t delete the file in this state. Find the terminal or the job that started that pacman and let it finish, or answer its prompt. If you can’t find it, pgrep -a pacman prints the full command line, which usually shows what it was doing:
pgrep -a pacmanOur holder was the half-finished htop install from the other terminal:
4987 pacman -S htopA pacman waiting at its [Y/n] prompt holds the lock the whole time, so check these places before you blame a crash:
- another terminal tab or tmux window
- an SSH session you left open on the same machine
- a
yayormakepkgbuild that reached its install step
When fuser prints nothing and exits with status 1, nothing has the file open and the lock is stale.
The capture shows both cases one after the other: a live pacman that fuser names, then a stale lock left behind by a killed pacman that nothing holds.
Remove a stale db.lck
Once fuser comes back empty, you can delete the file safely. This one-liner does the check and the removal together, and it leaves the lock alone when anything still has it open:
sudo fuser -s /var/lib/pacman/db.lck || sudo rm /var/lib/pacman/db.lckfuser -s is silent and only sets the exit status, so rm runs only when no process holds the file. We tested both branches: with a live pacman the file stayed put, and after we killed pacman with SIGKILL the same command deleted it. Then rerun the transaction you were trying, or a full upgrade if you’re not sure what was interrupted:
sudo pacman -SyuFinish with a database check, which takes a second and tells you whether the process that left the lock also left damage:
sudo pacman -DkOn a clean database you get one line:
No database errors have been found!Any error: line here means the interrupted pacman was writing a package when it died. Skip to repairing a package after a crash before you install anything else.
Find out why the lock went stale
pacman removes its lock when it exits normally, and it also cleans up after some signals. It doesn’t after others, which decides whether a cancelled update leaves a mess. We started pacman -S htop, sent each signal while it sat at the confirmation prompt, then checked for the file:
| How pacman stopped | Signal | db.lck afterwards |
|---|---|---|
| Ctrl+C in its terminal | SIGINT | Removed |
| Terminal window closed (we closed its tmux session) | SIGHUP | Removed |
kill <pid> or pkill pacman | SIGTERM | Left behind |
kill -9 or the OOM killer | SIGKILL | Left behind |
So Ctrl+C is the safe way to cancel pacman. Old guides suggest kill -9 for a stuck pacman, but it’s the one sure way to leave a stale lock. If pacman was mid-install, it also leaves that package half on disk. A power cut or a hard reset leaves the lock the same way, since pacman gets no chance to clean up.
On Arch, rebooting won’t help you either. We created a stale lock, rebooted the VM and found db.lck still in /var/lib/pacman/ with its old timestamp, because /var/lib survives a reboot and none of the systemd-tmpfiles rules on the system mention db.lck. You have to remove the file by hand, after the fuser check above. Manjaro differs here: libpamac deletes a db.lck older than the last boot when Pamac starts, so the first Pamac run after a reboot clears a lock that pacman, makepkg and yay would keep waiting on.
Handle the lock on Manjaro with Pamac
Pamac reads the same lock file, so the check and the fix are identical on Manjaro. What differs is when Pamac takes the lock. In our Manjaro container, pamac install waiting at its Apply transaction ? [y/N] prompt did not hold db.lck at all, unlike pacman, and pamac checkupdates ran fine with a stale lock in place. Pamac takes the lock once it starts applying the transaction, which we caught with fuser while pamac install was running.
That leaves two practical cases:
- Pamac says “Waiting for another package manager to quit”: run the
fusercheck. A live holder is a pacman in another terminal (yay and makepkg start one when they install), or a Pamac transaction that is already applying. fuserfinds nothing: remove the lock with the one-liner above. Pamac carries on if you do it within its 5-minute wait; after that it cancels, so run the command again.
A stale lock on Manjaro still means something killed a transaction, so finish with sudo pacman -Dk there as well.
Repair a package after a crash
A lock left by SIGKILL in the middle of an install is the case that bites later. We pre-downloaded Firefox and its dependencies, started the install and killed pacman 1.5 seconds in, while it was extracting gtk3. After removing the lock, the database check reported the damage:
error: 'gtk3-1:3.24.52-2': description file is missing
error: 'gtk3-1:3.24.52-2': file list is missingpacman had created the database entry for gtk3, but the directory held only its mtree file, without the desc and files entries pacman reads. Re-running the original command looks like a fix, and that’s the trap. Our sudo pacman -S firefox finished without an error and firefox --version ran, but pacman treated gtk3 as installed and skipped it. pacman -Qkk gtk3 still counted 291 altered files out of 1020, and pacman -Dk still failed. Reinstalling gtk3 directly refused to start:
error: could not open file /var/lib/pacman/local/gtk3-1:3.24.52-2/desc: No such file or directory
warning: could not fully load metadata for package gtk3-1:3.24.52-2
error: failed to prepare transaction (invalid or corrupted package)To repair it, you move the broken database entry out of the way so pacman stops believing the package is installed. Moving it rather than deleting it keeps a copy if you want to look at it later:
sudo mv '/var/lib/pacman/local/gtk3-1:3.24.52-2' /root/gtk3-broken-dbentryA plain reinstall now fails the other way, with 459 “exists in filesystem” conflicts, because the files the dead pacman extracted are on disk with no package owning them. Read the conflict lines first. When we repeated the repair, none of the 737 conflicts named an owner, but a line ending in (owned by <package>) means another package claims that path, and overwriting it would break that package. With only unowned files listed and gtk3 alone in the transaction, --overwrite '*' lets pacman take back the files it extracted. gtk3 was a Firefox dependency, so --asdeps keeps it marked that way and pacman -Qdt can still find it as an orphan later:
sudo pacman -S --asdeps --overwrite '*' gtk3Never add --overwrite '*' to a full -Syu, where it would silence real conflicts between packages. Run both checks again so you know the repair held:
sudo pacman -Dk
pacman -Qkk gtk3 | tail -1Both come back clean, and every file gtk3 owns matches its package again:
No database errors have been found!
gtk3: 1020 total files, 0 altered filesIf pacman -Dk lists more than one package, repeat the move and the scoped --overwrite for each one. When pacman itself or glibc is the broken package and pacman won’t run, the Arch Wiki’s pacman page covers repairing the system from the install USB with pacman --root. For the everyday commands around all of this, our pacman cheat sheet lists the query and check flags, and the yay vs pacman vs paru comparison explains how the AUR helpers hand work to pacman. If you landed here from a stuck AUR build, our guides to installing yay and installing Snap on Arch Linux pick up where the build stopped, and the Arch Linux post-install checklist covers the rest of a fresh system.
