Le 05/12/2016 à 17:32, Gustavo Niemeyer a écrit : > Okay, so curl is not retrying. That means the problem is specific to > something snapd is doing with the server.. might still be a problem on > the client or the server under those particular conditions. > > Can I hand you a binary for you to try out?
Sure! I'm happy to give it a test (probably tomorrow by now), while I have my setup nearby. > > On Mon, Dec 5, 2016 at 1:44 PM, Didier Roche <[email protected] > <mailto:[email protected]>> wrote: > > Le 05/12/2016 à 16:05, Gustavo Niemeyer a écrit : >> Xavier posted the exact URL of the failing snap in this thread: > Note it's not *the* failing snap but *a* failing snap. Every "snap > install" here is failing on my setup when they are more than a > couple of MB. This is why I posted as such in the instructions on > the bug. > > So, with curl -v -L, with the same snap than on the bug report, > here are the results: http://paste.ubuntu.com/23583801/ > <http://paste.ubuntu.com/23583801/> > I did 10 successful downloads in a row. This snap is 23MB. > > I did retry with the new revision (49), 32MB. > Tried 10 times with curl, 10 successful and complete downloads > (one is http://paste.ubuntu.com/23583847/ > <http://paste.ubuntu.com/23583847/>), with expected size and checksum. > Tried 10 times with snapd, got hashsum mismatch 10 times. Download > stops after few KBs up to few MBs. > > Cheers, > Didier > > >> >> "[1] >> - >> https://public.apps.ubuntu.com/anon/download-snap/rFpKbTdZ31LyAxWF6RpcerZov1TdtDly_24.snap >> >> <https://public.apps.ubuntu.com/anon/download-snap/rFpKbTdZ31LyAxWF6RpcerZov1TdtDly_24.snap> >> (extracted >> from the log file)" >> >> Bret also posted another one above (thanks!). >> >> >> On Mon, Dec 5, 2016 at 12:52 PM, Didier Roche >> <[email protected] <mailto:[email protected]>> wrote: >> >> Le 05/12/2016 à 15:38, Gustavo Niemeyer a écrit : >>> >>> >>> On Mon, Dec 5, 2016 at 12:23 PM, Didier Roche >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> I did though write on the bug: "contrary to curl or wget >>> which both supports large downloads." >>> The feedback thread mentioned as well "while same assets >>> can be successfully downloaded via curl or wget". >>> >>> I thought that was really obvious that they worked >>> consistently and that I did rerun then multiple times or >>> I wouldn't have opened the bug report + write this >>> feedback. Sorry if that wasn't clear enough, let's move >>> on :) >>> >>> >>> If you file a bug and a developer asks for specific >>> information that wasn't provided, it means the specific >>> information is not obvious. >>> >>>> Is it the case? Did you ever get a failure with them? >>>> Are they retrying while they work? Do you have a >>>> verbose dumb of the process? >>> Yes, as mentioned. I never got any failure with any of >>> them and I did retry multiple times in loop when I saw >>> the snapd failures. >>> wget is in verbose mode by default and I never got any >>> hint that it was retrying (just getting the normal >>> download output). >>> >>> I did just try a verbose download in curl (here, an >>> ubuntu 300M image). Here is the output: >>> http://paste.ubuntu.com/23583568/ >>> <http://paste.ubuntu.com/23583568/>. It seems that curl >>> doesn't complain of any reconnect. >>> >>> >>> You are downloading an image from an arbitrary server on the >>> internet unrelated to the problem we're trying to debug. >>> >>> Can you please attempt these several curl downloads while >>> using the exact same URL that failed for snapd? >> >> As a developer asking for more debug information, can you >> please paste the exact instructions on how to get those? >> >> I'm trying the >> https://public.apps.ubuntu.com/anon/download-snap/ >> <https://public.apps.ubuntu.com/anon/download-snap/> based >> url with the .snap showing up in the logs to get the exact >> same assets I pasted snapd information on. However, curl -v >> returns (output stripped out): >> * Trying 162.213.33.92... >> * Connected to public.apps.ubuntu.com >> <http://public.apps.ubuntu.com> (162.213.33.92) port 443 (#0) >> * found 173 certificates in /etc/ssl/certs/ca-certificates.crt >> * found 692 certificates in /etc/ssl/certs >> * ALPN, offering http/1.1 >> * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256 >> * server certificate verification OK >> * server certificate status verification SKIPPED >> * common name: public.apps.ubuntu.com >> <http://public.apps.ubuntu.com> (matched) >> * server certificate expiration date OK >> * server certificate activation date OK >> * certificate public key: RSA >> * certificate version: #3 >> * subject: C=GB,L=London,O=Canonical Group >> Ltd,CN=public.apps.ubuntu.com <http://public.apps.ubuntu.com> >> * start date: Mon, 30 May 2016 00:00:00 GMT >> * expire date: Wed, 21 Jun 2017 12:00:00 GMT >> * issuer: C=US,O=DigiCert Inc,CN=DigiCert SHA2 Secure >> Server CA >> * compression: NULL >> * ALPN, server did not agree to a protocol >> > GET >> /anon/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap >> HTTP/1.1 >> > Host: public.apps.ubuntu.com <http://public.apps.ubuntu.com> >> > User-Agent: curl/7.47.0 >> > Accept: */* >> > >> < HTTP/1.1 302 FOUND >> >> I guess that's due to the macaroon exchanged system and I'm >> not authorized or something else? >> Thanks for helping debugging. >> >> Cheers, >> Didier >> >> -- >> Snapcraft mailing list >> [email protected] >> <mailto:[email protected]> >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> <https://lists.ubuntu.com/mailman/listinfo/snapcraft> >> >> >> >> >> -- >> >> gustavo @ http://niemeyer.net >> >> > > > -- > Snapcraft mailing list > [email protected] <mailto:[email protected]> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > <https://lists.ubuntu.com/mailman/listinfo/snapcraft> > > > > > -- > > gustavo @ http://niemeyer.net > >
-- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
