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? On Mon, Dec 5, 2016 at 1:44 PM, Didier Roche <[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/ > 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/), 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/rFpKbTdZ > 31LyAxWF6RpcerZov1TdtDly_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]> wrote: > >> Le 05/12/2016 à 15:38, Gustavo Niemeyer a écrit : >> >> >> >> On Mon, Dec 5, 2016 at 12:23 PM, Didier Roche <[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/. 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/ 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 (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 (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 >> * 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 >> > 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] >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > > gustavo @ http://niemeyer.net > > > > > -- > Snapcraft mailing list > [email protected] > Modify settings or unsubscribe at: 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
