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 just not taking into
account unsatisfied dependencies for packages in trigger states, then
I'm a bit more at ease, although I'd also like to understand how apt
got into state. The options in that case would probable be:
* get a fixed apt into jessie that does:
- «dpkg --confiure -a» instead of configuring packages in trigger
states.
- and handles packages implicitly configured by dpkg (in case of
using --force-configure-any).
* and either:
- change dpkg to enable --force-configure-any, and not fail on
reconfigured packages.
- or revert the triggers change for jessie, but keep it enabled for
stretch.
If the problem is more general, and apt might try to configure
packages in other "broken" states even when having unsatisfied
dependencies, then there might be other instances independent of the
trigger changes that could get apt stuck into an unrecoverable state.
Thanks,
Guillem
Reply to: