FS#47188 - The eternal "Unable to lock database" Error

Attached to Project: Pacman
Opened by Camille Bissuel (nylnook) - Thursday, 26 November 2015, 15:49 GMT
Last edited by Allan McRae (Allan) - Monday, 14 December 2015, 13:37 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.2.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:
Every now and then, I run into a "Unable to lock database" Error and have to enter again "sudo rm /var/lib/pacman/db.lck", and trying to remember what the path is. Honestly I'm sick on it, It's been three years, and it's the most common blocking error pacman send to everyone.
I fully understand the need to ensure that the current installation process is the only one running at that time.
But can this be done in a smarter way, and non-obstrusive for users, especially newbies installing Manjaro or Antergos ?

Can't pacman check if another pid of itself is running before running ? And ask "Another Pacman instance is actually running, you should wait for it to finish. Do you want to force it to stop (not recommended) ?"

Or can't pacman just ask "Another Pacman instance is actually running, you should wait for it to finish. Do you want to force delete the lock file (not recommended) ?

Or just Pacamn dealing silently and smartly with that without blocking the user just making it's daily update ?


Steps to Reproduce:
just abort any installation, and launch pacman again.


I know it sound like a feature request, but please consider this as an usability bug.

Thanks a lot in advance.
This task depends upon

Closed by  Allan McRae (Allan)
Monday, 14 December 2015, 13:37 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Leaving the lock file is desirable when pacman is interrupted.
Comment by Doug Newgard (Scimmia) - Thursday, 26 November 2015, 15:55 GMT
You shouldn't be getting this error very often, just when pacman is killed unexpectedly.
Comment by Camille Bissuel (nylnook) - Thursday, 26 November 2015, 15:57 GMT
It happen to me every two weeks or so... I'm using pacman command line and with pamac as a graphical client. It happened with PacmanXG too.
Comment by Andrew Gregory (andrewgregory) - Friday, 27 November 2015, 15:24 GMT
If you are getting leftover db.lck files on a regular basis something is very wrong. pacman should only be leaving a db.lck file behind if it is being killed in a way that prevents it from cleaning up. In that case, your db may be in an inconsistent state and just blindly deleting the file is the wrong thing to do. pamac appears to use libalpm, if it is leaving behind lock files, that is its problem.
Comment by Camille Bissuel (nylnook) - Friday, 27 November 2015, 15:42 GMT
Everything run fine with my install since more that two years, except this recurring error.
I'm using Antergos.
Pamac (graphical client) is installed by default and I'm using it.
It comes with a daemon called "pamac-tray", checking for updates regularly.
So maybe it's linked to this daemon : if I switch off my computer (twice a day) while pamac-tray is invocating pamac, maybe this left the db.lck file.

But, sorry to be insisting, but even it is what is happening that's not the point : Pacman should be able to deal with an interrupted process (script error, user aborting, internet switch off, electrical power cut... ), "repairing" things, or proposing to repair, if something bad happened instead of blocking the user. That's not excluding with pedagogy and the Archlinux principles : just explain the user what happened and inform him on what to do next instead of just saying "Unable to lock database" which is not helpful.

I fully respect the great work done on Pacman, and I tahnk you for that using it every day, but I think there is still room for improvement user-side...
I hope I am clearer...
Comment by Andrew Gregory (andrewgregory) - Saturday, 28 November 2015, 17:56 GMT
If pacman is interrupted in the middle of an upgrade there is no way for it to know what state the database is in. How is it supposed to know what happened or how to automatically fix it?
Comment by Camille Bissuel (nylnook) - Sunday, 06 December 2015, 10:34 GMT
I'm sorry if I sounded aggressive in any way...
Maybe just a log file storing the last used command would allow pacman to know what was happening when something gone wrong.
Then it may be just a question like "Pacman was interrupted, do you want to retry the latest command ?"

Linux doesn't complain after a power cut : it just start again, checking the file system. Firefox ask you if you want to restore your tabs... and so on ! Why Pacman couldn't manage it ?

Thanks !
Comment by Camille Bissuel (nylnook) - Tuesday, 15 December 2015, 20:21 GMT
It's not because you don't want to look at a problem it stops existing :
This search give me thousands of users asking again and again the same question : why my package manager is broken ?
https://www.google.fr/search?q=pacman+unable+to+lock+database

If you read me correctly, I'm not asking not to use this db.lck file, I'm asking you not to leave users with a broken package manager, forced to delete an obscure file in an obscure path without understanding what they do to recover, and with high chances to do something worst than a broken package. A broken error message is a bug not only by conception but by lack of respect for the human using your software.


Comment by Andrew Gregory (andrewgregory) - Tuesday, 15 December 2015, 20:58 GMT
What is so obscure about the lock file path? The very error message you are complaining about tells you the path. As I have already told you, if the lock file exists there is either another package manager running or something went wrong in the middle of an upgrade. Either way just blindly removing the file and continuing is the wrong thing to do. I have no interest in making it easier for users to do the wrong thing and pacman does not have enough information to automatically fix anything (and saving the last command will not change that). If you find yourself having to deal with lock files on a regular basis you are either using a poorly written front-end and need to direct your complaints to them or you are not using pacman correctly.
Comment by Camille Bissuel (nylnook) - Tuesday, 15 December 2015, 21:43 GMT
It is obscure because an user is not a developer and do not see any link between a locked database and him wanting to install a package and his package manager doesn't wanting to do the job. At least the message should say "Another Pacman instance is actually running, you should wait for it to finish, or Pacman was brutally interrupted during latest operation. Actually, the database is locked." It's called pedagogy.

So, what do you do recommend to do if you get this error "Unable to lock database" message and you know no other pacman instance is running ?
pacman -Qk
pacman -Su
pacman -Sy
?
Shouldn't this be better than letting the user type
sudo rm /var/lib/pacman/db.lck
as it is recommended in the Manjaro wiki : https://wiki.manjaro.org/index.php?title=Pacman_troubleshooting ?

Can't we change a simple error message to lead the user in a better way, and not let him do stupid things ?
I'm open to discussion about what should be recommended if no magic is possible, but don't say me there is no issue.

Loading...