composer: Unknown SSL protocol error in connection to getcomposer.org:443
Previously working Docker build script that relies on composer failing randomly. This is happening right now, while posting this ticket, and has happened periodically over the past week with no relevant changes on our side.
My composer.json
:
{
"require": {
"ext-mbstring": "*",
"ext-gd": "*",
"ext-mcrypt": "*"
}
}
Output of composer diagnose
:
Not possible to run.
When I run this command:
curl -sS https://getcomposer.org/installer | php && mv composer.phar /usr/local/bin/composer && cd /var/www/ && composer install --no-plugins --no-scripts
I get the following output:
curl: (35) Unknown SSL protocol error in connection to getcomposer.org:443
And I expected this to happen:
Installer script should download composer.phar to the current directly.
This usually works, but we periodically run into a problem where this build step fails. This happens both locally and on AWS via Dockerfile running under Convox.
We have attempted to use composer.phar download directly from the site locally, but in this case the SSL errors prevent packages from being loaded by composer.
It looks like a server configuration error in getcomposer.org, possibly related to the server’s system time since the error seems to resolve itself after an indeterminate period of time. Just a guess though.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 15 (3 by maintainers)
I can understand that view point, but often you need a few data points to indicate something is a pervasive issue. If it’s a transient issue them sure, retry and write it off to internet gremlins. If there is some underlying issue that needs addressing then the issue reports help.
In IT in general and issue tracker comments in particular the single most unconstructive type of feedback is “Hey I’m also experiencing issue X”, as it indicates you’re expected some kind of SLA despite not paying for one. There’s nothing hostile at all about simply pointing out at that it’s not realistic to expect this kind of uptime from a free service serving terabytes of traffic per month.
I also had 2 CI jobs fail. I hit retry and they succeeded. It happens.
Seeing this randomly over the past few days as well.
@curry684 that was a particularly hostile response, I don’t think anyone is saying they expect 100% uptime.
I ran into this today, when installing Composer in a Docker container, running via “Docker In Docker” on Azure.
The workaround for me was the one described at https://github.com/moby/moby/issues/13475#issuecomment-108707488.
I changed “Docker in Docker”'s MTU to 1400.
Hope it helps.