race condition with locking during update-manager dist-upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
update-manager (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: update-manager
Hello! I've just noticed something weird:
I have a machine with Ubuntu Hardy on it. Today I tried to upgrade to Intrepid, so I started 'update-manager -d'. It started doing its thing, everything seemed OK.
In a separate terminal I was toying with aptitude, looking for a vnc package. I typed "aptitude install vnc-server"; I realized at the end that it couldn't work because of the update, but I pressed enter anyway to see what'd happen. Surprisingly, the update-manager coughed out an error. As far as I can tell, aptitude managed to take the "update lock" and start its thing, and the update-manager stumbled on it. (In fact, update-manager threw up the error, then continued installing a few things, and then stopped. I ran 'aptitude dist-upgrade' and it seems to continue correctly, but it's still going so I'm not sure everything will be A-OK.)
I know this is not a common situation, but it still should be fixed. I'm not sure if the update-manager can take lock on behalf of whatever apps it's running, so perhaps it should detect lock failures and retry or ask the user what to do.
Changed in update-manager: | |
milestone: | none → later |
status: | New → Triaged |
Thanks for your bugreport.
Could you please attach the logs in /var/log/ dist-upgrade/ * ? There is a known race condition in the lock file operation, but it should not be easy to trigger. I have not debugged it in detail, but it basicly its the problem that apt runs dpkg in various runs and when one dpkg exists it gives up the lock and when the next one starts it takes it again. In between there is a lock-less time.