Comment 5 for bug 1412698

Why #4 is a problem here but not in the standard system-image.

In standard si, CheckForUpdate tries to acquire the checking lock, but it does so non-blocking. If the lock cannot be acquired, but there is cached update information already available, it will just send an UpdateAvailableStatus with the cached information. If no cached information is available, it is assumed the check is still in progress, and when *that* check completes, an UAS signal is emitted and the update information is cached. So for all intents and purposes, it doesn't matter if the checking lock is acquired.

However, when snappy's version with mvo's patch is used, it changes the internal assumptions. Let's say a CFU is called, and it completes, sending a UAS signal. However, as with the si trunk, the checking lock is not released, *and* snappy always uses manual downloads, so the release after the download completes never happens. When ReloadConfiguration invalidates the cache (by setting self._update to None), we now have a situation where the checking lock is acquired, no download or CancelUpdate is called to release the lock, *and* there is no cached update information. So from here on, no UAS signal will be emitted.

mvo should confirm, but I believe when he says in comment #2 that "I had to self._checking.release() first or it would hang", the "it" means the snappy client would hang because it would be waiting on a UAS signal that would never arrive. It's *not* the case that si-dbus would hang, at least I predict as such. :)

This then explains why mvo had to also release the checking lock after invalidating the cache. Once that's done, then next CFU will see the lock get re-acquired and will re-initiate the check, eventually leading to a UAS.

Ideally, the checking lock should probably get released after the UAS signal is emitted, but that's too risky of a change here. I'll work on that for si 3.0 though, thus the additional bug task. For the snappy version, I think mvo's patch is exactly right.