precise -> trusty upgrade failed dpkg status database is locked by another process

[Jason R. Coombs]

Here's the report from the failed upgrade. I'll attach the requested files:

Processing triggers for man-db ...
dpkg: error: dpkg status database is locked by another process
Error in function:

A fatal error occurred

Please report this as a bug and include the files
/var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in
your report. The upgrade has aborted.
Your original sources.list was saved in
/etc/apt/sources.list.distUpgrade.

SystemError: E:Sub-process /usr/bin/dpkg returned an error code (2)

Could not install the upgrades

The upgrade has aborted. Your system could be in an unusable state. A
recovery will run now (dpkg --configure -a).

Please report this bug in a browser at
http://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+filebug
and attach the files in /var/log/dist-upgrade/ to the bug report.
installArchives() failed

dpkg: error: dpkg status database is locked by another process

Upgrade complete

The upgrade has completed but there were errors during the upgrade
process.

[Kyrylo Galanov (kgalanov)]

Hello,

According to the logs, provisioning was done ~ 4:00 AM
[node-1.test.domain.local] out: 04:07:28 up 6 min, 1 user, load average: 0.20, 0.36, 0.19

It's time to run cron daily tasks.
Surprisingly, one of the cron tasks is /etc/cron.daily/apt . That's why dpkg database was blocked.

Any suggestions for a work-around except stopping cron before provisioning and starting it after?

--
Kyrylo

[Jason R. Coombs (jaraco)]

Perhaps the dist-upgrade process could acquire some kind of exclusive lock early (and release late) such that it could guarantee that the packaging infrastructure wouldn't be in use by another process (or fail early, rather than midstream, if the packaging infrastructure is in use).

If only there were a way to early invoke dpkg (to create its usual lock), leave it running, send signals to that process to invoke substeps of the whole operation, and eventually release the process and its lock near the end of the upgrade.

I have a very naive view of the system, so that's as deep as my recommendation can go, but I hope it provides at least a hint of inspiration. I certainly understand the challenge with having a "all or nothing" update to a system platform.

[Kyrylo Galanov (kgalanov)]

Jason,

I should have placed the comment to another branch. However, it might help you as well.
You can check which process blocks the database by running the command:
$ fuser /var/lib/dpkg/lock

Best regards,
Kyryl