Bug#773256: dbus + triggers + apt issue (was: Bug#773256: pre-approval: unblock: dpkg/1.17.23)
On Thu, Jan 08, 2015 at 02:47:05AM +0100, Guillem Jover wrote:
[ @deity: please check out the dbus issue below. ]
[..]
[ Re dbus issue ]
Noted. Do we (still?) have a (reliable) way of reproducing the dbus
trigger issue?
We didn't up to now (AFAIK), but there's now very valuable data from
Karl Ljungkvist at #774124. I've been able to reproduce the issue with
that status file and apt (over a clean debootstrap of jessie, and
adding i386 as a foreign arch).
Thanks for pointing us towards this bugreport, this contains some good
information. I followed up there with some more questions, it would be
really nice to be able to reproduce what error happend that caused
this broken state.
And have been trying out several things:
* It seems to affect both apt from jessie/sid and wheezy. :(
apt gets into a state it cannot recover from by itself.
Indeed, apt sees the triggers-pending and triggers-awaited state
and tries to run dpkg --configure on all those packages. This
fails.
* «dpkg --configure --pending» solves the issue.
* Using dpkg --force-configure-any only fixes the issue partially, :(
because apt does not notice that the package has been implicitly
configured, and tries to configure the package again and dpkg exits
with an error for that run, which apt does not like much either (as
I feared). So I'd need to also change dpkg to not fail configuring
an already configure package, or try to detect that specific case.
When you say implicitly configured what does that mean exactly? Is
the issue here that apt should ignore the triggers-awaited state
because those will be dealt with by dpkg entirely?
I also wonder if there are further implications for apt by the trigger
changes. The ordering code in apt builds on the premise that there is
no implict configuration, it builds the unpack/configure ordering
early and its static. Is this still a valid assumption?
[..]
Before considering either reverting, or trying to find a workaround
for this in dpkg, I'd like to know if this is easily fixable in apt
and the implications of this problem (i.e. can it affect similar
situations regardless of the recent dpkg trigger changes?) and the
implications of such a fix.
We have code in pkgApplyStatus that detects and fixes not-ok
packages. So far it considered packages with
triggers-{pending,awaited} as something to just dpkg --configure. We
could change the code to ignore those states and simply let dpkg
handle them (via Davids code that ensures 'dpkg --configure -a' gets
called). Does that sound sensible?
I'm still a bit nervous about the issue that lead to #774124. It would
be good to get more data here.
Cheers,
Michael
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773256: dbus + triggers + apt issue (was: Bug#773256: pre-approval: unblock: dpkg/1.17.23)
Hi!
On Tue, 2015-01-13 at 15:08:01 +0100, Michael Vogt wrote:
On Thu, Jan 08, 2015 at 02:47:05AM +0100, Guillem Jover wrote:
[ Re dbus issue ]
Noted. Do we (still?) have a (reliable) way of reproducing the dbus
trigger issue?
We didn't up to now (AFAIK), but there's now very valuable data from
Karl Ljungkvist at #774124. I've been able to reproduce the issue with
that status file and apt (over a clean debootstrap of jessie, and
adding i386 as a foreign arch).
Thanks for pointing us towards this bugreport, this contains some good
information. I followed up there with some more questions, it would be
really nice to be able to reproduce what error happend that caused
this broken state.
The bug probably deserves to be reassigned to apt, I'll do that later.
Unfortunately it seems many if not all of these instances where also
affected by the apt bug eating dpkg's output. :(
I've some code locally that will log dpkg errors to the log file, but
didn't even try to get this into jessie due to the deep freeze. Will
be included with 1.18.x in any case.
And have been trying out several things:
* It seems to affect both apt from jessie/sid and wheezy. :(
apt gets into a state it cannot recover from by itself.
Indeed, apt sees the triggers-pending and triggers-awaited state
and tries to run dpkg --configure on all those packages. This
fails.
Because I'm assuming apt is simply not taking into account the
unsatisfied dependencies for those package states?
* «dpkg --configure --pending» solves the issue.
* Using dpkg --force-configure-any only fixes the issue partially, :(
because apt does not notice that the package has been implicitly
configured, and tries to configure the package again and dpkg exits
with an error for that run, which apt does not like much either (as
I feared). So I'd need to also change dpkg to not fail configuring
an already configure package, or try to detect that specific case.
When you say implicitly configured what does that mean exactly? Is
the issue here that apt should ignore the triggers-awaited state
because those will be dealt with by dpkg entirely?
In normal conditions, when dpkg is called with an explicit list of
packages to configure, it will only configure those.
When using dpkg with --force-configure-any, if there's an unsatisfied
dependency that could be fixed by configuring another package, then
dpkg will also enqueue that package for configuration. Which means that
even though apt didn't request its configuration, it got configured
(implicitly) anyway.
Ideally apt would notice this through the status-fd updates, and not
try to configure that package explicitly afterwards, but it seems this
is not currently the case? And dpkg fails when apt requests to
configure the already configured package.
Otherwise enabling --force-configure-any by default in dpkg, would be
a sufficient workaround for this issue.
I also wonder if there are further implications for apt by the trigger
changes. The ordering code in apt builds on the premise that there is
no implict configuration, it builds the unpack/configure ordering
early and its static. Is this still a valid assumption?
As long as --force-configure-any is not used (which is the case
currently), then yes, there's no implicit configuration going on. I
was just checking if that would be a viable workaround for the dbus
issue. But due to the current apt behavior, that is not a viable
workaround by itself, it might require more changes in dpkg.
The only implication that I assume was not being taken into account
previously is that for dpkg to be able to process pending triggers,
the dependencies for that package need to be satisfied.
[..]
Before considering either reverting, or trying to find a workaround
for this in dpkg, I'd like to know if this is easily fixable in apt
and the implications of this problem (i.e. can it affect similar
situations regardless of the recent dpkg trigger changes?) and the
implications of such a fix.
We have code in pkgApplyStatus that detects and fixes not-ok
packages. So far it considered packages with
triggers-{pending,awaited} as something to just dpkg --configure. We
could change the code to ignore those states and simply let dpkg
handle them (via Davids code that ensures 'dpkg --configure -a' gets
called). Does that sound sensible?
That should indeed in theory fix the issue (depending where apt runs
that command). The other option is to micromanage dpkg even more, by
checking for unsatisfied dependencies, and configuring those first. I'd
rather go with the first, as a way to start micromanaging dpkg less.
I'm still a bit nervous about the issue that lead to #774124. It would
be good to get more data here.
Indeed, that's why I wanted to get you guys to take a look at it
before proceeding with a decision or fixes/workarounds in dpkg. If it
ends up being a very localized problem of apt
Bug#773256: dbus + triggers + apt issue (was: Bug#773256: pre-approval: unblock: dpkg/1.17.23)
[ @deity: please check out the dbus issue below. ] Hi! On Sat, 2014-12-27 at 18:45:38 +0100, Niels Thykier wrote: I hope you are feeling better now. :) Yes, much better, thanks. :) TL;DR: Please upload dpkg/1.17.23 with the proposed fix for #771730 at your earliest convenience - by the looks of it, might fix one or two of our upgrade tests on jenkins.d.n. Thanks for the unblock. [ Re dbus issue ] Noted. Do we (still?) have a (reliable) way of reproducing the dbus trigger issue? We didn't up to now (AFAIK), but there's now very valuable data from Karl Ljungkvist at #774124. I've been able to reproduce the issue with that status file and apt (over a clean debootstrap of jessie, and adding i386 as a foreign arch). And have been trying out several things: * It seems to affect both apt from jessie/sid and wheezy. :( apt gets into a state it cannot recover from by itself. * «dpkg --configure --pending» solves the issue. * Using dpkg --force-configure-any only fixes the issue partially, :( because apt does not notice that the package has been implicitly configured, and tries to configure the package again and dpkg exits with an error for that run, which apt does not like much either (as I feared). So I'd need to also change dpkg to not fail configuring an already configure package, or try to detect that specific case. This is the (trimmed) «dpkg -C» output for the broken status file: ,--- The following packages have been unpacked but not yet configured. They must be configured using dpkg --configure or the configure menu option in dselect for them to work: bluezBluetooth tools and daemons bzip2high-quality block-sorting file compressor - utilities libdbus-1-3:amd64simple interprocess messaging system (library) libdbus-1-3:i386 simple interprocess messaging system (library) libdbus-1-dev:amd64 simple interprocess messaging system (development headers libperl5.20 shared Perl library perl Larry Wall's Practical Extraction and Report Language perl-modules Core Perl modules systemd-sysv system and service manager - SysV links tzdata-java time zone and daylight-saving time data for use by java r The following packages are awaiting processing of triggers that they have activated in other packages. This processing can be requested using dselect or dpkg --configure --pending (or dpkg --triggers-only): systemd system and service manager The following packages have been triggered, but the trigger processing has not yet been done. Trigger processing can be requested using dselect or dpkg --configure --pending (or dpkg --triggers-only): dbus simple interprocess messaging system (daemon and utilitie `--- And here's the «apt-get install -f -s» output: ,--- Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following extra packages will be installed: libpam-systemd The following packages will be upgraded: libpam-systemd 1 upgraded, 0 newly installed, 0 to remove and 238 not upgraded. 10 not fully installed or removed. Conf systemd-sysv (215-8 Debian:testing [amd64]) [libpam-systemd:amd64 ] Inst libpam-systemd [215-7] (215-8 Debian:testing [amd64]) Conf libdbus-1-3 (1.8.12-3 Debian:testing [amd64]) Conf libdbus-1-3:i386 (1.8.12-3 [i386]) Conf bzip2 (1.0.6-7+b2 Debian:testing [amd64]) Conf perl-modules (5.20.1-4 Debian:testing [all]) Conf perl (5.20.1-4 Debian:testing [amd64]) Conf bluez (5.23-2 Debian:testing [amd64]) Conf libdbus-1-dev (1.8.12-3 Debian:testing [amd64]) Conf libperl5.20 (5.20.1-4 Debian:testing [amd64]) Conf tzdata-java (2014j-1 Debian:testing [all]) Conf libpam-systemd (215-8 Debian:testing [amd64]) `--- Trying to run the first action gives the undesired unsatisfied trigger dependency problem: ,--- $ dpkg --configure systemd-sysv dpkg: dependency problems prevent processing triggers for dbus: dbus depends on libdbus-1-3 (= 1.7.6); however: Package libdbus-1-3:amd64 is not configured yet. dpkg: error processing package dbus (--configure): dependency problems - leaving triggers unprocessed […] dpkg: too many errors, stopping Errors were encountered while processing: dbus […] Processing was halted because there were too many errors. `--- Before considering either reverting, or trying to find a workaround for this in dpkg, I'd like to know if this is easily fixable in apt and the implications of this problem (i.e. can it affect similar situations regardless of the recent dpkg trigger changes?) and the implications of such a fix. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
