Pacman

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.
Tasklist

FS#28048 - pacman tries updating the repositories despite db.lck and fails.

Attached to Project: Pacman
Opened by Darshit Shah (darnir) - Sunday, 22 January 2012, 13:56 GMT
Last edited by Dan McGee (toofishes) - Sunday, 22 January 2012, 17:11 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.0.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:
On a abrupt exit of pacman, the pacman lock file remains. On running pacman the next time, instead of detecting the lock and exiting, pacman keeps trying to update all the repositories and fails everytime because of the lock. Pacman should detect the existence of the lock and exit in the very beginning.
The output of the scenario is:
:: Synchronizing package databases...
error: failed to update core (unable to lock database)
error: failed to update extra (unable to lock database)
error: failed to update community (unable to lock database)
error: failed to update multilib (unable to lock database)
error: failed to synchronize any databases
error: failed to init transaction (unable to lock database)
if you're sure a package manager is not already
running, you can remove /var/lib/pacman/db.lck


Steps to Reproduce:
1. Run pacman.
2. Try running pacman from another terminal.
3. You will experience the said scenario.
This task depends upon

Closed by  Dan McGee (toofishes)
Sunday, 22 January 2012, 17:11 GMT
Reason for closing:  Won't fix
Additional comments about closing:  We do get repeated error messages, but there is a reason to the madness.
Comment by Dan McGee (toofishes) - Sunday, 22 January 2012, 17:05 GMT
This is a very corner case scenario, and quite frankly I'm not that concerned about it as a little extra output hurts no one here.

If your other pacman instance was to finish up halfway through, we actually would succeed on half the database updates here.
Comment by Darshit Shah (darnir) - Sunday, 22 January 2012, 17:09 GMT
True enough. I did not think about the case when the other instance was to finish halfway through. I'll request closure then.
Comment by Dan McGee (toofishes) - Sunday, 22 January 2012, 17:11 GMT
I should note we moved to this vs. what we did before with only one lock as a first step to finer grained locking in pacman- cache directory locks, local vs. sync database locks, etc.

Loading...