Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#63404 - error: unable to lock database
Attached to Project:
Pacman
Opened by grenudi (grenudi) - Wednesday, 07 August 2019, 23:33 GMT
Last edited by Allan McRae (Allan) - Thursday, 08 August 2019, 02:11 GMT
Opened by grenudi (grenudi) - Wednesday, 07 August 2019, 23:33 GMT
Last edited by Allan McRae (Allan) - Thursday, 08 August 2019, 02:11 GMT
|
DetailsSummary and Info:
error: unable to lock database Steps to Reproduce: -try to install any package using: pacman -S packagename -press Ctrl+C in the middle of the installation process -done. you broke it! Now next time I run any command from pacman I get error: failed to update core (unable to lock database) ...extra... ...community... Works everytime. Quite a popular problem actually. removing /var/lib/pacman/db.lck seems to help. |
This task depends upon
Ok, seems like you right about quit signal. I believe that it is installers like makepkg and GUI pamac that send QUIT signal on CTRL+C or when you press cancel in pamac.
P.S. ctrl+/ doesn't interrupt pacman for me (gif included)
That's the control sequence for manually forcing a coredump (or to be exact, SIGQUIT). I don't know why you feel surprised that a coredump leaves the lockfile in place -- the whole point of dumping a core is that we want to emulate a completely abnormal fatal crash, which... surprise, leaves a lockfile as a sign that "something very bad happened".