HTTP requests fail when without glibc

[Blacksmoke16]

When executing an HTTP request on alpine/scratch/non glibc docker image the request fails with the error Unhandled exception: No address found for api.github.com:443 over TCP (Socket::Error)

My test scenario

With irrelevant code removed

runner.cr

require "option_parser"
require "http/client"

OptionParser.parse! do |parser|
  parser.banner = "Usage: does stuff"
  parser.on("-h", "--health", "Checks if commands can be executed") { health_check }
end

def health_check
  LOGGER.info "Fetching Github api!"
  LOGGER.info HTTP::Client.get "http://api.github.com/repos/Blacksmoke16/GESI/releases"
end

With this file included as a target in shards.yml

targets:
  Runner:
    main: src/runner.cr

Dockerfile

FROM crystallang/crystal:latest
ADD . /EveTools
WORKDIR /EveTools
RUN shards build --production --static --release --no-debug

FROM busybox:1.29.1-musl
COPY --from=0 /EveTools/bin/ /eve-tools/bin

root@foo:/home/eve-tools# docker exec api2 /eve-tools/bin/Runner --health
I, [2018-09-09 20:42:29 +00:00 #21]  INFO -- : Fetching Github api!
Unhandled exception: No address found for api.github.com:80 over TCP (Socket::Error)
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???
  from ???

However, rebuilding the image using a base of busybox:1.29.1-glibc will execute the request just fine.

Crystal Version

Crystal 0.26.1 [391785249] (2018-08-27)

LLVM: 4.0.0
Default target: x86_64-unknown-linux-gnu

[straight-shoota]

The statically compiled binary includes all libc functions and does not depend on the libc implementation available on the executing system.
There should be no difference whether the busybox image uses glibc or musl. The binary won't use either. It has everything it needs included.

So this looks like an issue with the environment (docker, busybox image, whatever) not Crystal.

I was under the impression it was built statically on Alpine with musl, which is not the case.

[j8r]

I'll bet on a DNS issue related to Docker. People has already reported similar cases.

[Blacksmoke16]

Then in that case, if the binary is statically linked, why would this be an issue in an empty container based off of scratch. Other containers are all on the same docker network and work fine. This only happens with the statically linked binaries from crystal when, as far as i can tell, libgc isnt in the container.

Granted I dont know much about this, not saying it is a crystal problem, just wondering.

[RX14]

the crystal binary isn't statically linked with musl, which means that it's not portable. This is why --static is only supported on alpine linux, because glibc still uses dlopen and depends on loading shared objects even when it's statically compiled. Not a crystal bug, it's a glibc "bug" or design issue. Glibc hasn't shown any willingness to change.

[RX14]

Oh, and you need to licence your sourcecode to GPL if you statically link glibc. Just don't do it.

[straight-shoota]

Damn, I thought it was building on Alpine with musl. Forget my previous comment.

[ysbaddaden]

An alternative is to use the alpine docker image and the official crystal package which will statically link musl-libc, which is portable across different libc (unlike glibc).

[Blacksmoke16]

Gotcha, thanks for the explanation.