envygeeks / jekyll-docker

⛴ Docker images, and CI builders for Jekyll.
ISC License
993 stars 279 forks source link

bin/connected causing unhelpful errors #286

Closed davegson closed 3 years ago

davegson commented 4 years ago

Recently, after pulling the newest jekyll/jekyll image, all of the sudden my docker-compose up failed with:

Creating website_jekyll_1 ... done
Attaching to website_jekyll_1
jekyll_1  | ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux-musl]
jekyll_1  | /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/spec_set.rb:86:in `block in materialize': Could not find concurrent-ruby-1.1.7 in any of the sources (Bundler::GemNotFound)
jekyll_1  |     from /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/spec_set.rb:80:in `map!'
jekyll_1  |     from /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/spec_set.rb:80:in `materialize'
jekyll_1  |     from /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/definition.rb:170:in `specs'
jekyll_1  |     from /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/definition.rb:237:in `specs_for'
jekyll_1  |     from /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/definition.rb:226:in `requested_specs'
jekyll_1  |     from /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:101:in `block in definition_method'
jekyll_1  |     from /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:20:in `setup'
jekyll_1  |     from /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler.rb:149:in `setup'
jekyll_1  |     from /usr/gem/gems/jekyll-4.1.0/lib/jekyll/plugin_manager.rb:52:in `require_from_bundler'
jekyll_1  |     from /usr/gem/gems/jekyll-4.1.0/exe/jekyll:11:in `<top (required)>'
jekyll_1  |     from /usr/gem/bin/jekyll:23:in `load'
jekyll_1  |     from /usr/gem/bin/jekyll:23:in `<main>'

Which led me to believe that somehow the gems were not correctly installed. After investigating the wrong problem we lastly ended up finding the actual cause, being:

bin/connected [file]

url=https://www.google.com
if wget -q --spider "$url" -O /dev/null 2>/dev/null; then
  su-exec jekyll touch "$connected"
  exit 0
else
  su-exec jekyll touch $disconnected
  exit 1
fi

When running wget -q --spider https://www.google.com from within the container manually, the handshake ended up failing. I have no idea what happened, maybe they dislike my ip?

bash-5.0# wget -q --spider https://www.google.com
ssl_client: www.google.com: handshake failed: No error information
wget: error getting response: Connection reset by peer

but calling any other site (http or https) did work without error.

Solution

My quickfix locally was to mount my docker-compose.yml file into the /connected dir so it will always be there:

volumes:
  - .:/srv/jekyll
  - ./docker-compose.yml:/var/jekyll/connected:ro

To fix this issue for others too, I created a PR where the test url simply is changed to another domain created for connectivity checks.

Why Have This Check?

But I also wanted to raise the issue of why such a check is needed? Without it, wouldn't a useful error be raised anyway if iE. a connection to rubygems failed? Why have this check which ended up pointing me in a completely wrong direction?


Addendum: Even though some hours were lost, you have enabled me and so many others to speed up dev process over many years. A big THANK YOU for all your work! 👏😄🎉 (you hear this too seldom)

envygeeks commented 4 years ago

Hopefully your PR will fix this, thanks for that!

davegson commented 3 years ago

got around to testing it today. The PR fixed it, thanks! Closing.

So even though it works, I'd still want to ping the question of:

why such a check is needed? Without it, wouldn't a useful error be raised anyway if iE. a connection to rubygems failed?

Even the Firefox could trip up in the future. Just some well-meant input for the future ;) cheers!