Since yesterday, I'm getting this error in using drush make: "File drupal-7.22.tar.gz is corrupt (wrong md5 checksum)"

Drush version is 5.7. I also got a similar error with comment notify awhile back that my co-worker posted to their issue queue and got it for days, so we just commented that out of the profile for now.

Any ideas?

Files: 
CommentFileSizeAuthor
#21 xml.diff1.49 KBmoshe weitzman

Comments

evanmwillhite’s picture

I just wanted to follow up and say I'm still getting this error, but running drush make with the option '--no-cache' solved it temporarily. So, I guess this is an issue with drush make storing incorrect info during a window of time when a new release is put out there? I want to leave the ticket open as it seems to me the fact that drush make references an incorrect checksum in the first place could still be a problem.

yuchuan1’s picture

This happened to me this morning as well.

>> File file_entity-7.x-2.x-dev.tar.gz?date=1374367521 is corrupt [error]
(wrong md5 checksum)

'--no-cache' solved the issue.
However, after running drush make with no cache option, and run it the second time without no cache option, the issue came back.

ezra-g’s picture

We're experiencing this issue with an invalid checksum on the OG module as part of packaging the Commons distribution: #2047677: Unable to package Commons: invalid checksum on OG..

jgraham’s picture

Experiencing this same issue with running a local drush makefile. Cleared out ~/.drush/cache and ran with --no-cache. Problem persists.

Error below.

File file_entity-7.x-2.x-dev.tar.gz?date=1374454907 is corrupt (wrong md5 checksum).

file_entity has a dev release from today. I'm guessing this is likely a caching issue or a failure to rebuild/reset the XML at the correct time.

EDIT: As of Wed Jul 24 18:04:39 UTC 2013 XML at http://updates.drupal.org/release-history/file_entity/7.x indicates md5sum should be fbf654f4c6324e076586991cb36b9312 for http://ftp.drupal.org/files/projects/file_entity-7.x-2.x-dev.tar.gz, actual md5sum is bdd6d0fbfada75154fcf0ccad05e1456

Using --ignore-checksums and --force-complete flags are non-functional, checksums still checked build still fails. These details are likely drush issues, the bad checksum is d.o infrastructure.

ezra-g’s picture

We're experiencing this with the Commons nightly dev snapshot, this time with:

ERROR: >> File commons_origins-7.x-3.x-dev.tar.gz?date=1375229187 is corrupt (wrong md5 checksum).

yuchuan1’s picture

I'm experiencing the following this morning.

File l10n_update-7.x-1.x-dev.tar.gz_date=1361970686 is corrupt (wrong    [error]
md5 checksum).

File hierarchical_select-7.x-3.x-dev.tar.gz_date=1339849269 is           [error]
corrupt (wrong md5 checksum).

BUILD FAILED
Drush exited with code 1

It seems to be affecting most frequently with the dev modules.
I've used --no-cache option, but the error still occurs.

jlyon’s picture

I too was getting this error with any module I specified to use the -dev branch:

File ckeditor-7.x-1.x-dev.tar.gz_date=1366763925 is corrupt (wrong   [error]
md5 checksum).

Building with the --no-cache option did fix the issue for me.

moshe weitzman’s picture

Priority:Normal» Major

I'm seeing it too with the dev snapshot of Drupal 8.x. When I download that tarball and run md5_file() on it, I get checksum of 97545a881b63c7c16c48db35b79883a0. The Update XML right now has different checksum. See the last [release] element:

<?xml version="1.0" encoding="utf-8"?>
<project xmlns:dc="http://purl.org/dc/elements/1.1/">
<title>Drupal core</title>
<short_name>drupal</short_name>
<dc:creator>Drupal</dc:creator>
<api_version>8.x</api_version>
<project_status>unsupported</project_status>
<link>http://drupal.org/project/drupal</link>
  <terms>
   <term><name>Projects</name><value>Drupal core</value></term>
   <term><name>Development status</name><value>Under active development</value></term>
   <term><name>Maintenance status</name><value>Actively maintained</value></term>
  </terms>
<releases>
<release>
  <name>drupal 8.0-alpha3</name>
  <version>8.0-alpha3</version>
  <tag>8.0-alpha3</tag>
  <version_major>8</version_major>
  <version_patch>0</version_patch>
  <version_extra>alpha3</version_extra>
  <status>published</status>
  <release_link>http://drupal.org/node/2081595</release_link>
  <download_link>http://ftp.drupal.org/files/projects/drupal-8.0-alpha3.tar.gz</download_link>
  <date>1378303307</date>
  <mdhash>c786a027b87428fef5ddd7a946dcf07c</mdhash>
  <filesize>7647641</filesize>
  <files>
   <file>
    <url>http://ftp.drupal.org/files/projects/drupal-8.0-alpha3.tar.gz</url>
    <archive_type>tar.gz</archive_type>
    <md5>c786a027b87428fef5ddd7a946dcf07c</md5>
    <size>7647641</size>
    <filedate>1378303307</filedate>
   </file>
   <file>
    <url>http://ftp.drupal.org/files/projects/drupal-8.0-alpha3.zip</url>
    <archive_type>zip</archive_type>
    <md5>2ac8bc2b9f28c2602257ad6a5d817351</md5>
    <size>12987824</size>
    <filedate>1378303309</filedate>
   </file>
  </files>
  <terms>
   <term><name>Release type</name><value>New features</value></term>
   <term><name>Release type</name><value>Bug fixes</value></term>
  </terms>
</release>
<release>
  <name>drupal 8.0-alpha2</name>
  <version>8.0-alpha2</version>
  <tag>8.0-alpha2</tag>
  <version_major>8</version_major>
  <version_patch>0</version_patch>
  <version_extra>alpha2</version_extra>
  <status>published</status>
  <release_link>http://drupal.org/node/2026719</release_link>
  <download_link>http://ftp.drupal.org/files/projects/drupal-8.0-alpha2.tar.gz</download_link>
  <date>1372069563</date>
  <mdhash>01f5589dcfd851c7d65c040f455bad19</mdhash>
  <filesize>7319631</filesize>
  <files>
   <file>
    <url>http://ftp.drupal.org/files/projects/drupal-8.0-alpha2.tar.gz</url>
    <archive_type>tar.gz</archive_type>
    <md5>01f5589dcfd851c7d65c040f455bad19</md5>
    <size>7319631</size>
    <filedate>1372069563</filedate>
   </file>
   <file>
    <url>http://ftp.drupal.org/files/projects/drupal-8.0-alpha2.zip</url>
    <archive_type>zip</archive_type>
    <md5>54ad7978910d4aab1f3f44367b0b68f5</md5>
    <size>12323909</size>
    <filedate>1372069564</filedate>
   </file>
  </files>
</release>
<release>
  <name>Drupal 8.x-dev</name>
  <version>8.x-dev</version>
  <tag>8.x</tag>
  <version_major>8</version_major>
  <version_extra>dev</version_extra>
  <status>published</status>
  <release_link>http://drupal.org/node/572834</release_link>
  <download_link>http://ftp.drupal.org/files/projects/drupal-8.x-dev.tar.gz</download_link>
  <date>1379768130</date>
  <mdhash>9e260d27c7e82299fec01c432314e4bb</mdhash>
  <filesize>7696363</filesize>
  <files>
   <file>
    <url>http://ftp.drupal.org/files/projects/drupal-8.x-dev.tar.gz</url>
    <archive_type>tar.gz</archive_type>
    <md5>9e260d27c7e82299fec01c432314e4bb</md5>
    <size>7696363</size>
    <filedate>1379768130</filedate>
   </file>
   <file>
    <url>http://ftp.drupal.org/files/projects/drupal-8.x-dev.zip</url>
    <archive_type>zip</archive_type>
    <md5>7b1a60ba9312b18ad08aa30aa4e443af</md5>
    <size>13055083</size>
    <filedate>1379768133</filedate>
   </file>
  </files>
</release>
</releases>
</project>
killes@www.drop.org’s picture

I think the problem is that Moshe looked at the XML when Drupal-dev had already been recreated but the packaging job was still running and the XML wasn't rebuilt yet. The timestamp of his comment would support this. (roughly)

This is a problem, especially since the job regularly runs over 2 hours and sometimes it gets stuck and is killed after 4 with the XML in an undefined state.

However, it only affects dev releases.

If somebody wants to resolve this, function package_releases is your friend. It would probably suffice to move the XML rebuilding of packaged projects up a bit and not do a whole-sale XML rebuilding at the end. This would minimize the time gap.

moshe weitzman’s picture

I am seeing same behavior right now. Is packaging running?

moshe weitzman’s picture

Where is package_releases(). I'm looking in project but don't see it in 7.x-2.x

killes@www.drop.org’s picture

package-release-nodes.php

has the function.

http://ftp.drupal.org/files/projects/versioncontrol_project-6.x-2.x-dev....

and yes, packaging is running..

moshe weitzman’s picture

I notice that this code has been ported to Drush in D7 as per #1800186: Update package-release-nodes.php to D7 in Drush. Yet I still see package-release-nodes.php in D7 so I'm confused about where to start for fixing this. Fix in D7 first? If so, what function?

attiks’s picture

Facing the same problem with bootstrap theme and cer project

jblumenfeld’s picture

Same here with job-scheduler module.

killes@www.drop.org’s picture

please provide detailed info on how to reproduce the problem. The XML files are update regularly.

drumm’s picture

They are all updated every 6 hours, so there is plenty of opportunity for them to get stale. Updating the release XML per-project as a queued operation.

moshe weitzman’s picture

Would be great if someone could answer my question in #14. Thanks.

drumm’s picture

The drush command, http://drupalcode.org/project/project.git/blob/refs/heads/7.x-2.x:/relea..., is the place to fix this.

Where do you see package-release-nodes.php now?

moshe weitzman’s picture

Issue summary:View changes
Status:Active» Needs review
StatusFileSize
new1.49 KB

Attached patch changes the meaning of release-package-run so that it both creates package files AND writes update XML. It does both jobs before moving on to the next project. I don't know how these commands are scheduled on drupal.org, so this might not be the optimal fix.

I also removed some redundant help.

drumm’s picture

Project:Drupal.org infrastructure» Project
Version:» 7.x-2.x-dev
Component:Packaging» Releases
Status:Needs review» Needs work

Committed http://drupalcode.org/project/project.git/commit/2b588e2 and deploying.

As a follow-up, we need to make the if (is_null($project_id)) code path optional, and not do it unless you specified --all on the command line. We no longer need or want to regenerate all history every 6 hours.

moshe weitzman’s picture

For anyone listening here, there are also upgrade related problems with dev snapshots. While the bug here is fixed, we won't see the benefit until we make progress at #2132659: [META] Problems with Project Release Packaging

AlfTheCat’s picture

I'm having this issue too, all of a sudden. A previously working makefile is now not downloading any of the dev releases anymore.
The issue mentioned in #23 is marked as fixed, what is the guidance on this issue now? I'm running Aegir and with this issue in place the platform creation workflow, which is a very important part, is basically broken.

dsnopek’s picture

@AlfTheCat: This could also just be your Drush cache getting corrupt. Try deleting the specific cached files (or even the whole cache) from ~/.drush/cache/download (where ~ is probably /var/aegir for Aegir).

geerlingguy’s picture

Installing drush via git (master branch/HEAD), on a fresh new server, and running drush dl drupal-8.x, gives me this error:

File drupal-8.x-dev.tar.gz_date=1390624108 is corrupt (wrong md5 checksum)

This same command did work on Monday, but hasn't been working tonight, and I'm guessing it's because the XML is out of sync with the actual release tarballs, correct? Using the --no-cache option did work. Weird.

ar-jan’s picture

I'm having this issue as well on the -dev release of views_matrix.

wget http://ftp.drupal.org/files/projects/views_matrix-7.x-1.x-dev.tar.gz
md5sum views_matrix-7.x-1.x-dev.tar.gz
483c97f2d26bfbc4688edc93401a2cbd  views_matrix-7.x-1.x-dev.tar.gz

md5sum according to https://www.drupal.org/node/1784126/release:
views_matrix-7.x-1.x-dev.tar.gz 11.27 KB f6ef645f48cbcd91e2ee5d889de5d0f4

This has been the case for the last two months (see #2411559), so it's not a matter of a temporary gap between build/release info.

drumm’s picture

I repackaged views_matrix and the downloaded file and Drupal.org page are now in sync.

ar-jan’s picture

Thanks @drumm!

ar-jan’s picture

Here's another one I just encountered: File node_clone-7.x-1.x-dev.tar.gz_date=1416365880 is corrupt (wrong md5 checksum).

drumm’s picture

I repackaged node_clone and the downloaded file and Drupal.org page are now in sync.

JulienF’s picture

I'm having the same issue under Drush 6.6 for entitycache 1.2 on my development environment.

File entitycache-7.x-1.2.tar.gz is corrupt (wrong md5 checksum)

the --no-cache option doesn't help

I even tried with drush 7 since this is the version used on my live environment and it still doesn't work locally, yet it works on the live environment...

Difference between drush 6 and 7 is that with version 7 the drupal folder gets created by the entitycache module isn't downloaded... I'm not sure this is the behaviour it should have (but this is probably another issue)

Any idea ?

drumm’s picture

$ curl -v http://ftp.drupal.org/files/projects/entitycache-7.x-1.2.tar.gz | md5
* Hostname was NOT found in DNS cache
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 23.235.47.249...
* Connected to ftp.drupal.org (23.235.47.249) port 80 (#0)
> GET /files/projects/entitycache-7.x-1.2.tar.gz HTTP/1.1
> User-Agent: curl/7.37.1
> Host: ftp.drupal.org
> Accept: */*
>
< HTTP/1.1 200 OK
* Server nginx/1.4.4 is not blacklisted
< Server: nginx/1.4.4
< Content-Type: application/octet-stream
< Last-Modified: Thu, 31 Oct 2013 10:55:26 GMT
< ETag: "5272371e-38df"
< Via: 1.1 varnish
< Content-Length: 14559
< Accept-Ranges: bytes
< Date: Tue, 07 Apr 2015 01:30:49 GMT
< Via: 1.1 varnish
< Age: 2172364
< Connection: keep-alive
< X-Served-By: cache-sea1923-SEA, cache-sjc3132-SJC
< X-Cache: HIT, HIT
< X-Cache-Hits: 1, 10
< X-Timer: S1428370249.461200,VS0,VE0
<
{ [data not shown]
100 14559  100 14559    0     0  55351      0 --:--:-- --:--:-- --:--:-- 55568
* Connection #0 to host ftp.drupal.org left intact
6690a64a90a057a5233121d998edd977

Matches https://www.drupal.org/node/2124735 & http://updates.drupal.org/release-history/entitycache/7.x

Can you post the file you get instead when downloading http://ftp.drupal.org/files/projects/entitycache-7.x-1.2.tar.gz? What IP does ftp.drupal.org resolve to for you?

JulienF’s picture

The file was stored as temp file, so I need to re-run the whole drush make command in debug mode to get its path etc...

So before going into this hassle I've just run the same command as you did and here is the result I have (different from yours):

curl -v http://ftp.drupal.org/files/projects/entitycache-7.x-1.2.tar.gz | md5
* Hostname was NOT found in DNS cache
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0*   Trying 185.31.17.249...
  0     0    0     0    0     0      0      0 --:--:--  0:00:06 --:--:--     0* Connected to ftp.drupal.org (185.31.17.249) port 80 (#0)
> GET /files/projects/entitycache-7.x-1.2.tar.gz HTTP/1.1
> User-Agent: curl/7.37.1
> Host: ftp.drupal.org
> Accept: */*
>
< HTTP/1.1 200 OK
* Server Varnish is not blacklisted
< Server: Varnish
< Retry-After: 0
< Via: 1.1 varnish
< Accept-Ranges: bytes
< Date: Thu, 09 Apr 2015 06:25:41 GMT
< Via: 1.1 varnish
< X-Served-By: cache-sea1927-SEA, cache-fra1229-FRA
< X-Cache: MISS, HIT
< X-Cache-Hits: 0, 1
< X-Timer: S1428560741.783991,VS0,VE0
< X-CFLO-Cache-Result: TCP_CLIENT_REFRESH
< Content-Length: 74
< Connection: Keep-Alive
< Age: 1037962
<
{ [data not shown]
100    74  100    74    0     0     10      0  0:00:07  0:00:07 --:--:--    15
* Connection #0 to host ftp.drupal.org left intact
dcec01864f86809d86b8399e11259ca3

As you can see, the IP is different and the Hash is different...
Out of curiosity I tried on a different machine under the same network and I'm getting the same result.

Any Idea on why ? and most importantly how to fix that ?

Thanks

drumm’s picture

Project:Project» Drupal.org infrastructure
Version:7.x-2.x-dev»
Component:Releases» Updates System

185.31.17.249 is a Fastly IP, which is good. However, the point of presence you are hitting is serving a cached error message:

$ curl -v http://185.31.17.249/files/projects/entitycache-7.x-1.2.tar.gz -H 'Host: ftp.drupal.org'
* Hostname was NOT found in DNS cache
*   Trying 185.31.17.249...
* Connected to 185.31.17.249 (185.31.17.249) port 80 (#0)
> GET /files/projects/entitycache-7.x-1.2.tar.gz HTTP/1.1
> User-Agent: curl/7.37.1
> Accept: */*
> Host: ftp.drupal.org
>
< HTTP/1.1 200 OK
* Server Varnish is not blacklisted
< Server: Varnish
< Retry-After: 0
< Via: 1.1 varnish
< Content-Length: 74
< Accept-Ranges: bytes
< Date: Thu, 09 Apr 2015 18:06:51 GMT
< Via: 1.1 varnish
< Age: 1080032
< Connection: keep-alive
< X-Served-By: cache-sea1927-SEA, cache-fra1243-FRA
< X-Cache: MISS, HIT
< X-Cache-Hits: 0, 1
< X-Timer: S1428602811.713931,VS0,VE0
<
* Connection #0 to host 185.31.17.249 left intact
<!DOCTYPE html>Our servers are busy, please retry in a few minutes!</html>
basic’s picture

I've opened a ticket with Fastly. I'll let you know when we've resolved the issues. Thanks for providing the debug information, it should make troubleshooting this straight forward.

Your request (#11659) has been received, and is being reviewed by our support staff.
basic’s picture

I believe we've found a solution to the problem (503 errors were being returned as 200 status instead -- and probably caching because of this).

I've updated our custom VCL with Fastly, and purged the file in question. I'm curious if there are any other files which may be invalid in our cache, please report any you find.

To purge the file after this change, I ran the following from our infrastructure:

[basic@util ~]$ curl -X PURGE http://ftp.drupal.org/files/projects/entitycache-7.x-1.2.tar.gz
{"status": "ok", "id": "57-1426568286-4540336"}
basic’s picture

Status:Needs work» Fixed
JulienF’s picture

Status:Fixed» Needs work

Hello,

I've tried again on the same machine (under the same network, yet the network doesn't have a fixed IP). here is what I'm getting now:

curl -v http://ftp.drupal.org/files/projects/entitycache-7.x-1.2.tar.gz | md5
* Hostname was NOT found in DNS cache
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 23.235.43.249...
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0* Connected to ftp.drupal.org (23.235.43.249) port 80 (#0)
> GET /files/projects/entitycache-7.x-1.2.tar.gz HTTP/1.1
> User-Agent: curl/7.37.1
> Host: ftp.drupal.org
> Accept: */*
>
< HTTP/1.1 200 OK
* Server Varnish is not blacklisted
< Server: Varnish
< Retry-After: 0
< Via: 1.1 varnish
< Accept-Ranges: bytes
< Date: Sat, 11 Apr 2015 05:46:47 GMT
< Via: 1.1 varnish
< X-Served-By: cache-sea1927-SEA, cache-fra1233-FRA
< X-Cache: MISS, HIT
< X-Cache-Hits: 0, 1
< X-Timer: S1428560948.655065,VS0,VE0
< X-CFLO-Cache-Result: TCP_HIT
< Content-Length: 74
< Connection: Keep-Alive
< Age: 1038169
<
{ [data not shown]
100    74  100    74    0     0     40      0  0:00:01  0:00:01 --:--:--    40
* Connection #0 to host ftp.drupal.org left intact
dcec01864f86809d86b8399e11259ca3

I see no particular error, the IP is not the same now (different from the one drumm had and different from the one I initially had yet the hash is still equal to the one I had with the previous fastly IP which is not the one I should obtain.

drumm’s picture

23.235.43.249 is also run by Fastly, the CDN we use for ftp.drupal.org, so that is okay. However, when I try that IP, I get the correct file now:

$ curl -v http://23.235.43.249/files/projects/entitycache-7.x-1.2.tar.gz -H 'Host: ftp.drupal.org' | md5
* Hostname was NOT found in DNS cache
*   Trying 23.235.43.249...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 23.235.43.249 (23.235.43.249) port 80 (#0)
> GET /files/projects/entitycache-7.x-1.2.tar.gz HTTP/1.1
> User-Agent: curl/7.37.1
> Accept: */*
> Host: ftp.drupal.org
>
< HTTP/1.1 200 OK
* Server nginx/1.6.0 is not blacklisted
< Server: nginx/1.6.0
< Content-Type: application/octet-stream
< Last-Modified: Thu, 31 Oct 2013 10:55:26 GMT
< ETag: "5272371e-38df"
< Via: 1.1 varnish
< Content-Length: 14559
< Accept-Ranges: bytes
< Date: Sat, 11 Apr 2015 18:57:22 GMT
< Via: 1.1 varnish
< Age: 151288
< Connection: keep-alive
< X-Served-By: cache-sea1925-SEA, cache-ams4127-AMS
< X-Cache: HIT, HIT
< X-Cache-Hits: 2, 1
< X-Timer: S1428778642.231499,VS0,VE0
<
{ [data not shown]
100 14559  100 14559    0     0  26697      0 --:--:-- --:--:-- --:--:-- 26713
* Connection #0 to host 23.235.43.249 left intact
6690a64a90a057a5233121d998edd977
JulienF’s picture

Well I just tried again, and got served back by the other fastly IP... yet the hash is still the wrong dcec01864f86809d86b8399e11259ca3 one...

After I scratched my head a little bit, I decided to not pipe the result to md5 directly and split the task... great Idea I had... here is the return I'm getting!

<!DOCTYPE html>Our servers are busy, please retry in a few minutes!</html>

Now the question is why am I constantly getting this return instead of being server with the file ?

In case someone has access to some logs, here is my current IP address: 37.209.253.48 Since I'm sitting on a dynamic IP address it is also important to note that I just run a test like now:
4:04 PM
Monday, April 13, 2015
Greenwich Mean Time (GMT)

Thanks ahead for the help!

basic’s picture

I see in our log files:

2015-04-13T15:54:47Z cache-fra1232 fastlyftp[476797]: 37.209.253.48 | "-" | "-" | 2015-04-13 | 15:54:47 +0000 | GET /files/projects/entitycache-7.x-1.2.tar.gz | 304 | (null) | curl/7.37.1
2015-04-13T15:55:53Z cache-fra1235 fastlyftp[473945]: 37.209.253.48 | "-" | "-" | 2015-04-13 | 15:55:53 +0000 | GET /files/projects/entitycache-7.x-1.2.tar.gz | 304 | (null) | curl/7.37.1
2015-04-13T16:00:37Z cache-fra1238 fastlyftp[334388]: 37.209.253.48 | "-" | "-" | 2015-04-13 | 16:00:37 +0000 | GET /files/projects/entitycache-7.x-1.2.tar.gz | 304 | (null) | curl/7.37.1

You're getting a response of 304 Not Modified -- if you tell your browser to empty caches, or try a private browsing / incognito window do you get a real file?

JulienF’s picture

Well I'm using curl to run those tests and the other case is that this file is being downloaded by drush make, in both cases it doesn't work... I tried to remove the temp file downloaded by drush but it keeps on failing at the md5 checksum check.

Any idea on how could I clear that cache on the terminal ?

Thanks

basic’s picture

@JulienF
Can you please paste new output you're receiving from running
curl -v http://ftp.drupal.org/files/projects/entitycache-7.x-1.2.tar.gz | md5

JulienF’s picture

here you go:

curl -v http://ftp.drupal.org/files/projects/entitycache-7.x-1.2.tar.gz | md5
* Hostname was NOT found in DNS cache
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0* Trying 185.31.17.249...
0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0* Connected to ftp.drupal.org (185.31.17.249) port 80 (#0)
> GET /files/projects/entitycache-7.x-1.2.tar.gz HTTP/1.1
> User-Agent: curl/7.37.1
> Host: ftp.drupal.org
> Accept: */*
>
< HTTP/1.1 200 OK
* Server nginx/1.6.0 is not blacklisted
< Server: nginx/1.6.0
< Content-Type: application/octet-stream
< Last-Modified: Thu, 31 Oct 2013 10:55:26 GMT
< ETag: "5272371e-38df"
< Via: 1.1 varnish
< Accept-Ranges: bytes
< Date: Wed, 22 Apr 2015 19:08:27 GMT
< Via: 1.1 varnish
< X-Served-By: cache-sea1922-SEA, cache-fra1246-FRA
< X-Cache: HIT, HIT
< X-Cache-Hits: 2, 8
< X-Timer: S1429729707.337656,VS0,VE0
< X-CFLO-Cache-Result: TCP_MISS
< Content-Length: 14559
< Connection: Keep-Alive
< Age: 1102352
<
{ [data not shown]
100 14559 100 14559 0 0 3707 0 0:00:03 0:00:03 --:--:-- 3706
* Connection #0 to host ftp.drupal.org left intact
6690a64a90a057a5233121d998edd977

It seems its good now!
I've also run a drush make and it ran smoothly.

I know that things are good now but i'm the kind who likes to understand, can I know what was wrong and what solved it ?

Thanks a lot for your help!

basic’s picture

Our FTP content distribution network (Fastly) is configured in a way that minimizes the connections to our origin servers. This works something like this:

your request -> (internet) -> (fastly pop closest to you) -> (fastly origin shield pop) -> ftp.drupal.org

Fastly, our CDN, is a giant distributed Varnish server, and we had some example VCL configuration which would rewrite "503 Service Unavailable" errors into a 200 response with the text "Our servers are busy, please retry in a few minutes!".

Since we're using the Origin Shield, our VCL is executed both at the fastly pop closest to you, and at the fastly origin shield pop. If the fastly origin shield pop was unable to retrieve from ftp.drupal.org it would rewrite the error into the 200 "Our servers are busy, please retry in a few minutes!" and the fastly pop closest to you would cache that errored response.

We worked with Fastly support to confirm this behavior, and their engineers have removed that example VCL from their documentation. Removing the VCL code which was causing the "Our servers are busy, please retry in a few minutes!" response to be cached, and clearing the cache, fixed the entitycache-7.x-1.2.tar.gz download.

JulienF’s picture

Thanks for the detailed explanation. Things are clear and in case I encounter this error again I'll know what to dig for first ;-)

Best,

basic’s picture

Status:Needs work» Fixed

I believe this was fixed in the last update

sobi3ch’s picture

Status:Fixed» Active

I don't know is this related but couldn't find better issue. Try to update using drush 6.6 and 6.5.

I couldn't update Drupal core nor jquery_update

Update information last refreshed: Thu, 06/18/2015 - 14:54
Name Installed Version Proposed version Message
Drupal 7.37 7.38 SECURITY UPDATE available

Code updates will be made to drupal core.
WARNING:  Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt.  If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.
Note: Updating core can potentially break your site. It is NOT recommended to update production sites without prior testing.

Do you really want to continue? (y/n): t
Do you really want to continue? (y/n): y
md5_file(/var/www/vhosts/etcc.pl/drupal-7.38.tar.gz): failed to open stream: Permission denied drush.inc:691         [warning]
File drupal-7.38.tar.gz is corrupt (wrong md5 checksum).                                                             [error]
Updating project drupal failed. Attempting to roll back to previously installed version.                             [error]
Backups were restored successfully.

basic’s picture

@sobi3ch: this appears to be a permissions issue. If i'm reading the Drush output correctly, "md5_file(/var/www/vhosts/etcc.pl/drupal-7.38.tar.gz): failed to open stream: Permission denied" is saying the md5 checksum function is unable to open the file to validate the checksum on it, which causes drush to think the file has the wrong checksum.

The file only has the wrong checksum in this case because Drush cannot calculate its checksum at all.

If you 'wget http://ftp.drupal.org/files/projects/drupal-7.38.tar.gz' I imagine this file downloads cleanly?

sobi3ch’s picture

Status:Active» Fixed

Hi @basic, thanks for explanation I don't know I didn't notice permission problem.

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.