debsums runs concurrently with unattended-upgrades which leads to false positives
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| debsums (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
Bug Description
On most systems I administer, both debsums and unattended-upgrades are installed and run from cron daily.
unattended-upgrades has been configured to wait for a random amount of time before doing its thing, and this every now and then causes it to perform an upgrade at the time debsums is running.
During such an upgrade (especially of large packages like kernel headers), debsums can find a mismatch between the files on disk and the checksums, but these are false positives.
I guess this can be fixed by adding an option to debsums to let it (read-)lock the dpkg admin dir before doing its job, so it can be prevented from running concurrently with software altering package state.
The bug has been observed on 16.04 systems with all upgrades applied, but looking at the debsums changelogs I see no reason to believe this has been fixed.
| Axel Beckert (xtaran) wrote | #1 |
| Launchpad Janitor (janitor) wrote | #2 |
| Changed in debsums (Ubuntu): | |
| status: | New → Confirmed |
Thanks for the bug report and feature idea/suggestion!
Not yet sure if that option should be really added to debsums (the program), or be default inside the cron job(s) itself.
Note to myself: I see there's a lot of code duplication in the cron jobs. (Never really looked at them since I took over that package.) Might be an idea to clean up and deduplicate them a little bit. This would also make it easier to add such a feature to the cron job (in case me or the Debian Perl Team decides that that's the proper place to implement this).