[mr_ecks@MrEcks ~]$ sudo pacman -Syu
[sudo] lösenord för mr_ecks:
:: Synkroniserar katalogdatabaserna…
FEL: Kunde inte uppdatera core (kunde inte låsa databas)
FEL: Kunde inte uppdatera extra (kunde inte låsa databas)
FEL: Kunde inte uppdatera community (kunde inte låsa databas)
FEL: Kunde inte uppdatera multilib (kunde inte låsa databas)
FEL: Kunde inte uppdatera endeavouros (kunde inte låsa databas)
FEL: Kunde inte synkronisera alla databaser
[mr_ecks@MrEcks ~]$ yay -Syu
→ /var/lib/pacman/db.lck is present.
→ There may be another Pacman instance running. Waiting…
A lot of that is in Swedish but tl;dr, pacman says (could not lock database), and you can read what yay says.
I checked and there is a new /var/lib/pacman/db.lck witch seems to be a lock file for pacman. It was created in the middle of the night and looks like this:
I was fast asleep at the time, but I remember that the internet went down during the night. No problems there, I just restarted the connection.
Might it be some security/fail safe that kicked in?
I did check the Arch forum, and what I found was inconclusive, but the general suggestion was to remove the lock file. What is your take on the issue?
I will be at work for a couple of hours, but please tell me if you need any output, and I will provide that.
PS.I did refresh the pacman keys, and rebooted to no avail. DS.
This is not of my own knowledge, but it is clear enough I would personally go with it. I acquired a list of aliases from a knowledgeable source, and this is included in that list:
alias unlock='sudo rm /var/lib/pacman/db.lck'
which seems to me to be a hint that it happens more than rarely (though not to me yet). I have had the error message, but it quickly cleared as whatever operation was running concluded and released the lock itself - usually I think it was a notification of pending updates that was running automatically… maybe such a thing glitched in your case?
I had this message twice, last time just 1 or 2 days ago.
Just waited and tried after a couple of hours and it worked.
(I use reflector service to regularly update my mirros. My assumption was it is running and the reason, but could also be something completely different.)
Just be careful to only remove that file if you are sure there isn’t another process running. It is there for your protection. Typically it only gets left behind wrongly if something crashes or is killed while running. This should hopefully be exceptionally rare. It has happened to me only a handful of times and I maintain and update quite a few Arch-based machines.
If you get in the habit of just blindly removing it when you see that error, you may get yourself in some trouble.
On the other hand, if you get that error on a regular basis, you really should look into why that is and fix the issue.
I’ll give a day or two then. Funny thing, I’m almost happy that something goes awry. Things has been running smother than a shaved baby bottom for a long time now.
I checked htop and couldn’t see any processes that was remotely close to the issue.
If it hasn’t solved itself in a couple of days, I will look over my backup (the home folder goes on the cloud), burn the latest ISO to a stick, and see what happens if I remove /var/lib/pacman/db.lck.
I don’t blindly remove things habitually; hence me asking here.
First, let me say that my response wasn’t directed at you specifically. It was general info I thought should be shared.
I definitely don’t think you need to wait days. The file should be created when pacman is running an operation and removed when the operation completes. Unless you are actively installing a large update, this should only be a few minutes.
If it is still there 15 minutes later, I would check the process list for anything that might trigger pacman(like an update-checker). If nothing is running, it probably makes sense to delete the file.
However, if it keeps happening, it probably needs deeper investigation.
This happened to me a week or so ago. I couldn’t find anything running that needed the db.lck file. I deleted it, rebooted, and did the update. All has been OK ever since.
I usually reboot first before deleting it, to make sure that if even something was running it’s not anymore. I don’t know whether it is the right way to do it though.