Comment 55 for bug 1277589

On 3 Mar 2014 19:20, "Barry Warsaw" <email address hidden> wrote:
>
> On Mar 03, 2014, at 08:44 AM, Alan Pope ㋛ wrote:
>
> >I have triggered it again on 216 upgrading to 217.
> >
> >To be clear, I'm *not* upgrading, but starting the upgrade then pressing
> >back, then going back in later, and then the error appears. Here's a
> >video:-
> >
> >https://www.youtube.com/watch?v=YmD6cGYvIAI
>
> One difference from the previous incarnation is that you're doing manual
> downloads. Your video actually helped quite a bit as I can reproduce this
> fairly consistently now by flashing to 215 and upgrading to whatever is
the
> latest image.
>
> Log file analysis leads me to think there's a race condition between u-d-m
> doing its atomic renames and it sending the 'finished' signal for the
group
> download. If I put some logging right after the finished signal is
received,
> and I list the directories containing the destination files, I see that
they
> have .tmp.tmp suffixes. The first .tmp is put there by s-i (which still
has
> its own atomic-rename workaround), but the second .tmp is put there by
u-d-m
> for *its* atomic rename operation.
>
> It should not be possible for s-i to see the .tmp.tmp files. This can
only
> happen if it's seeing the finished signal before u-d-m does its atomic
> rename.
>
> I tried the following experiment: at the point where the finished signal
is
> received, I log the data as explained above, and then I sleep(2) before
> continuing on. With the sleep in there, it doesn't crash for me.
>
> This isn't definitive proof of what's going on, but it seems plausible.
> Manuel is investigating u-d-m, and then he'll provide a package for me to
test
> on my device.

After adding extra test and logs I can say that udm sees all the downloaded
files before raising the signal that s-I receives.

udm does not delete any files are all unless an error occurs and this is
not the case.

>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1277589
>
> Title:
> Better protection against concurrent access
>
> Status in Ubuntu Download Manager:
> Fix Released
> Status in Ubuntu system image (server/client/updater):
> Fix Released
> Status in “ubuntu-system-settings” package in Ubuntu:
> Fix Released
>
> Bug description:
> Trying to update to 170 from a fresh 169 on mako I get the above error
> message after downloading the update and trying to install it.
>
> http://popey.com/~alan/phablet/device-2014-02-07-112816.png
>
> TEST CASE (verified on mako):
> 1. Flash the device with an older build than latest in -proposed
> $ phablet-flash ubuntu-system --channel devel-proposed -b --revision 176
> 2. Wait
> 3. On the device: Skip intro
> 4. Configure networking and make sure the device connects to the Wifi
network
> 5. Go to system-settings
> 6. Select 'Updates'
> 7. The device will detect that an update is available (e.g 178),
proceed with the update
>
> EXPECTED RESULT:
> Upgrade succeeds and user can reboot the device to apply them
>
> ACTUAL RESULT:
> Upgrade fails with
> FileNotFoundError: /var/lib/system-image/blacklist.tar.xz
>
> To manage notifications about this bug go to:
>
https://bugs.launchpad.net/ubuntu-download-manager/+bug/1277589/+subscriptions