deferred trigger failures not reported on --status-fd and not properly in the terminal log

[Michael Vogt]

Binary package hint: dpkg

While looking at a upgrade failure report I noticed that dpkg does not report trigger failures as real errors via the status-fd or via the terminal output. Here is a example:

term.log
...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.24-27-generic
cpio: ./etc/modprobe.d/arch-aliases: Cannot stat: No such file or directory
update-initramfs: failed for /boot/initrd.img-2.6.24-27-generic
dpkg: subprocess installed post-installation script returned error exit status 1
....

status:
2010-03-17 01:05:55,527 INFO cache.commit()
2010-03-17 01:43:24,349 ERROR got an error from dpkg for pkg: 'dmsetup': 'dependency problems - leaving unconfigured
'

This error on the status-fd is a subsequent error that happens because initramfs-tools is now in half-configured state because the trigger failed. This is misleading and conceptually it should be the same kind of error as a normal postinst failure.

[Michael Vogt (mvo)]

The original bug is:
https://bugs.launchpad.net/bugs/540125

[Michael Vogt (mvo)]

It turns out this is a side effect of using --auto-deconfigure in apt:

When modifying the software-center trigger code to error out, this is the result:

# dpkg --auto-deconfigure --unpack /var/cache/apt/archives/app-install-data-partner_12.10.04_all.deb
(Reading database ... 367213 files and directories currently installed.)
Preparing to replace app-install-data-partner 12.10.04 (using .../app-install-data-partner_12.10.04_all.deb) ...
Unpacking replacement app-install-data-partner ...
Processing triggers for software-center ...
exiting with exit code in software-center trigger
dpkg: subprocess installed post-installation script returned error exit status 1

[Michael Vogt (mvo)]

Hrm, false alarm, nothing to do with --auto-deconfigure. It seems to be the deferred trigger processing instead that does not raise a explicit error (no ehflag_bombout maybe?).

[Michael Vogt (mvo)]

I think there are two options:
- add a push_error_handler() before trigproc_run_deferred() in src/archives.c
- add code to the push_error_handler() code inside trigproc_run_deferred() in src/trigproc.c

[Launchpad Janitor (janitor)]

This bug was fixed in the package dpkg - 1.15.5.6ubuntu4

---------------
dpkg (1.15.5.6ubuntu4) lucid; urgency=low

  * Backport from upstream:
    - Restore fsync during package unpack (LP: #559915). This is now done
      by deferring the fsync and rename for normal files in tar extraction
      so that it's done in one pass afterwards, to avoid massive I/O
      degradation due to the serialization from each write + fsync. When
      creating hard links to normal files on extraction use the .dpkg-new
      filename for source as the file is not yet in place due to the rename
      deferral.
    - Fix dpkg to not lose package metadata on filesystems where readdir()
      returns new files added after the opendir() call, btrfs in particular
      triggered the problematic behaviour. Closes: #575891
    - Report deferred trigger errors on status-fd. Closes: #574599,
      LP: #540252
      Thanks to Michael Vogt <email address hidden>.
 -- Colin Watson <email address hidden> Thu, 15 Apr 2010 12:38:50 +0100