Re: Bug#776063: dbus fails to upgrade rendering entire apt unusable
Hi!
On Sun, 2015-01-25 at 00:45:10 +0000, Simon McVittie wrote:
> On Fri, 23 Jan 2015 at 19:04:33 +0100, Guillem Jover wrote:
> > I think this one should be merged with the other dbus+triggers+apt
> > bugs.
> I notice that before the failing upgrade, Yaroslav had dpkg 1.17.21 and
> apt 1.0.9.4 (if I'm reading the right status-file backup), which means
> he did not have the fix for https://bugs.debian.org/769609 in apt.
> dpkg and apt were upgraded to 1.17.23 and 1.0.9.6 earlier in the same
> batch that failed with this dbus trigger thing, which I assume means
> dbus was upgraded with the old apt (although maybe the new dpkg).
AFAIR I tested with latest apt and could reproduce the issue, it also
affects the apt in stable.
> Is the fix for https://bugs.debian.org/769609 expected to fix this
> particular issue, or am I misreading it?
This is for another issue (leaving packages in trigger states after
finishing up the apt run), and although running «dpkg --configure -a»
would indeed fix the issue at hand, the problem is that apt does not
recognize the problem and is unable to make progress. But the real fix
would be for apt to not try to explicitly configure the packages out
of order.
> > I don't think this can be worked around in dbus, barring the removal
> > of its triggers.
(Just in case, I meant the removal of the awaiting part of the trigger,
not necessarily the whole trigger.)
> If it's absolutely necessary, I might be able to back out the trigger
> for jessie, because it is *meant* to be non-essential: dbus-daemon is meant
> to use inotify to monitor the system services directory, and that feature
> works fine for me. However, I've had reports that it doesn't work for
> everyone, hence the trigger (and in any case it seems more
> predictable/deterministic to use a trigger to kick off the reload
> when all new packages are known to be fully in place).
Besides getting an apt fix, we'd need to add a workaround for this
outside of apt anyway, because the new dpkg and dbus can be upgraded
and as such reinvoked from the running apt session.
If apt (with a fix) got upgraded too, then although quite unfortunate
and inconvenient the subsequent upgrade would not get stuck and could
at least proceed.
But if apt did not yet get upgraded then the upgrade would get stuck,
as it currently happens.
> Or if dropping it down to interest-noawait would help, that isn't
> really semantically correct, but it's probably acceptable in practice?
So if switching to interest-noawait does not seem too onerous, I'd
probably prefer that to adding workarounds in dpkg, because that would
require changing the semantics of some operations that might get
entrenched and might be difficult to revert later on. :/
But, in this case that does mean that perhaps we might be moving the
problem to some other package groups, and as I've asked before, I'd
like input from the apt team on this, as in how difficult an apt fix
seems to be, what's the reach of the problem for stable's apt, etc. So
that we can better evaluate where and what kind of workaround would be
best. Or even if an outright revert in dpkg, with the implied upgrade
failures due to unsatisfied dependencies, is to be considered.
But lacking that input, I guess it might be worth a try?
> <https://bugs.debian.org/740139> is the bug report that prompted me to
> add the trigger, FWIW.
It's unfortunate that the root cause for this problem was never
discovered. :(
Although even with interest-noawait, it means that dbus would be
guaranteed to be restarted during the apt run, so any such breakage
would be time-confined.
Thanks,
Guillem
Reply to: