-o Dpkg::Options::=--force-confdef ignored by cleanup run -- makes pkgsync hang

Bug #257279 reported by Knut Auvor Grythe on 2008-08-12

This bug report will be marked for expiration in 29 days if no further activity occurs. (find out why)

Affects Status Importance Assigned to Milestone
aptitude (Ubuntu)
synaptic (Ubuntu)

Bug Description

Binary package hint: aptitude

When pkgsync is running, it calls aptitude with the options "-o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold" to avoid being asked about what to do with changed conffiles. If such a prompt is displayed, aptitude will hang until killed, awaiting user input. pkgsync is typically run from cron, so asking for user input is a bad thing.

In the normal case, aptitude propagates options down to dpkg like this:

  /bin/sh /etc/cron.daily/nightly-pkgsync
   \_ /bin/bash /usr/sbin/pkgsync
       \_ aptitude -y -q -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold dist-upgrade afacli+ apache [...]
           \_ /usr/bin/dpkg --force-confdef --force-confold --status-fd 34 --configure [...]
               \_ /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/sympa.postinst configure

However, if a package installation fails, this chunk of code in src/generic/apt/download_install_manager.cc is called:

     case pkgPackageManager::Failed:
       cerr << _("A package failed to install. Trying to recover:") << endl;
       system("DPKG_NO_TSTP=1 dpkg --configure -a");

This results in the following call tree, which hangs as soon as a conffile is reached:

  /bin/sh /etc/cron.daily/nightly-pkgsync
   \_ /bin/bash /usr/sbin/pkgsync
       \_ aptitude -y -q -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold dist-upgrade afacli+ apache [...]
           \_ sh -c DPKG_NO_TSTP=1 dpkg --configure -a
               \_ dpkg --configure -a

The rest of aptitude seems to use an pkgDPkgPM object from apt-pkg/deb/dpkgpm.h (from the apt source package) when interfacing with dpkg. I believe this cleanup code should adopt a similar approach.

A workaround for this problem is to add these lines to /etc/dpkg/dpkg.cfg:

Daniel Hartwig (wigs) wrote :

commit fd28ea8c2af0786d3a426d06ea3527aa48de96ac
Author: Daniel Hartwig <email address hidden>
Date: Sat Mar 17 01:01:52 2012 +0800

    Respect DPkg::Options when calling dpkg to recover failed installs

    Usually we use APT to call dpkg, which handles all sorts of nice
    option parsing. However, if an install run fails then we to call
    'dpkg --configure -a' ourselves to see if this fixes the problem.

    APT passes various options to dpkg, so we should also.

    * src/generic/apt/download_install_manager.cc:
      - pass DPkg::Options when invoking dpkg. LP: #257279

Changed in aptitude:
status: New → Fix Committed
Daniel Hartwig (wigs) on 2012-03-17
Changed in aptitude (Ubuntu):
status: New → Confirmed
Daniel Hartwig (wigs) wrote :

Previous fix reverted. It was somewhat of a hack and more work required to accurately and *safely* invoke dpkg.

Changed in aptitude:
status: Fix Committed → Confirmed
gf (gf-interlinks) wrote :

Hello Knut,
Thank you for submitting this bug and reporting a problem with synaptic. You made this bug report some time ago and Ubuntu has been updated since then.

Could you confirm that this is no longer a problem and that we can close the ticket?
If it is still a problem, are you still interested in finding a solution to this bug?
If you are, could you let us know and run the following (only once):
apport-collect BUGNUMBER
and upload the updated logs and and any other logs that are relevant for this particular issue.

Thank you again for helping make Ubuntu better.

Changed in synaptic (Ubuntu):
status: New → Incomplete
Changed in aptitude (Ubuntu):
status: Confirmed → Incomplete
Changed in aptitude:
status: Confirmed → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers