Graal: [DNS issues] GraalVM 19.2.0 DNS issues with Alpine Linux

[smoell]

Hi all,

I've upgraded to GraalVM 19.2.0 and I still have DNS issues with Alpine Linux.

Dockerfile:

FROM oracle/graalvm-ce:19.2.0 AS build-aot

RUN yum clean all && yum update -y && yum install wget -y

RUN wget https://www-eu.apache.org/dist/maven/maven-3/3.6.1/binaries/apache-maven-3.6.1-bin.tar.gz -P /tmp
RUN tar xf /tmp/apache-maven-3.6.1-bin.tar.gz -C /opt
RUN ln -s /opt/apache-maven-3.6.1 /opt/maven
RUN ln -s /opt/graalvm-ce-19.2.0 /opt/graalvm

ENV GRAALVM_HOME=/opt/graalvm
ENV JAVA_HOME=/opt/graalvm
ENV M2_HOME=/opt/maven
ENV MAVEN_HOME=/opt/maven
ENV PATH=${M2_HOME}/bin:${PATH}
ENV PATH=${GRAALVM_HOME}/bin:${PATH}

COPY ./pom.xml ./pom.xml
COPY src ./src/

ENV MAVEN_OPTS='-Xmx6g'

RUN gu install native-image

RUN mvn -Dmaven.test.skip=true -Pnative-image-fargate clean package

FROM alpine:3.10
LABEL maintainer="Sascha Möllering <[email protected]>"

ENV javax.net.ssl.trustStore /cacerts
ENV javax.net.ssl.trustAnchors /cacerts

RUN apk --no-cache add curl && echo 'hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4' >> /etc/nsswitch.conf 

COPY --from=build-aot target/reactive-vertx /usr/bin/reactive-vertx
COPY --from=build-aot /opt/graalvm/jre/lib/amd64/libsunec.so /libsunec.so
COPY --from=build-aot /opt/graalvm/jre/lib/security/cacerts /cacerts

HEALTHCHECK --interval=5s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:8080/health/check || exit 1

EXPOSE 8080

CMD [ "/usr/bin/reactive-vertx" ]

My Java application still throws java.net.UnknownHostException.

[thomaswue]

Thanks for the report. This worked fine on 19.1.1?

[smoell]

Actually, I didn't try with 19.1.1, however, it didn't work with 19.1.0, I'll try.

[smoell]

Tried it, same behaviour with 19.1.1

[pmlopes]

In 19.1 ir wouldn't work because the DNS code required upd code that was not implemented. The upd missing code was added "recently"

https://github.com/oracle/graal/issues/1488

I guess this isn't enough

[pmlopes]

Hi, I've revisited my test case for the issue above:

package com.example.asyncdns;

import io.vertx.core.AbstractVerticle;
import io.vertx.core.dns.DnsClient;

public class MainVerticle extends AbstractVerticle {

  @Override
  public void start() {
    // your code goes here...
    DnsClient client = vertx.createDnsClient(53, "8.8.8.8");
    client.lookup("vertx.io", ar -> {
      if (ar.succeeded()) {
        System.out.println(ar.result());
      } else {
        ar.cause().printStackTrace();
      }
    });
  }
}

This will work on 19.2:

Aug 22, 2019 6:29:42 PM io.vertx.core.impl.launcher.commands.VertxIsolatedDeployer
INFO: Succeeded in deploying verticle
104.27.154.177

Using debian as base image but not using alpine.

[pmlopes]

This is quite odd on alpine:

/ # ldd asyncdns 
        /lib64/ld-linux-x86-64.so.2 (0x7f812e5ee000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f812e5ee000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f812e5ee000)
        libz.so.1 => /lib/libz.so.1 (0x7f812e5d4000)
        librt.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7f812e5ee000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f812e5ee000)
/ # ./asyncdns 
/bin/sh: ./asyncdns: not found
/ # 

Although it says not found... the executable is present in the correct path.

[smoell]

Debian based images work fine for me as well.

[pmlopes]

/ # ./asyncdns 
Aug 22, 2019 6:44:42 PM io.vertx.core.impl.launcher.commands.VertxIsolatedDeployer
INFO: Succeeded in deploying verticle
104.27.154.177
^C

So in order to make it work on alpine the compilation must contain --static in the command arguments, otherwise networking code still requires glibc. The dns in this case works because it's a custom client implementation.

[pmlopes]

There is still an issue (but it's not SVM related) that the default DNS servers are not always properly found (that is why the example is hardcoded to Google DNS)

[smoell]

--static is in my command argument list:

Args = --initialize-at-build-time=io.netty,io.vertx,com.fasterxml.jackson,org.slf4j,software.amazon.awssdk \
       --initialize-at-run-time=io.netty.handler.codec.http.HttpObjectEncoder,io.netty.handler.codec.http.websocketx.WebSocket00FrameEncoder,io.netty.handler.codec.http2.Http2CodecUtil,io.netty.handler.codec.http2.DefaultHttp2FrameWriter,io.netty.handler.ssl.ReferenceCountedOpenSslServerContext,io.netty.handler.ssl.JdkNpnApplicationProtocolNegotiator,io.netty.handler.ssl.ReferenceCountedOpenSslEngine,io.netty.handler.ssl.ConscryptAlpnSslEngine,io.netty.handler.ssl.JettyNpnSslEngine,io.netty.handler.ssl.ReferenceCountedOpenSslClientContext,io.vertx.core.net.impl.transport.EpollTransport,io.vertx.core.net.impl.transport.KQueueTransport \
       --enable-url-protocols=http,https \
       --static \
       -H:+UseServiceLoaderFeature \
       -H:IncludeResources=(META-INF/|vertx-default-jul-logging).* \
       -H:ReflectionConfigurationFiles=classes/${.}/reflection.json

[smoell]

Any idea how to fix this?

[olpaw]

Step 13/28 : COPY ./pom.xml ./pom.xml
COPY failed: stat /var/lib/docker/tmp/docker-builder461912118/pom.xml: no such file or directory

@smoell where do I get the pom.xml from that is referred to from your Dockerfile?

[olpaw]

If I provide my own pom.xml with a dummy project that builds with --static I do get a static image as expected. This can be verified with:

> docker run -it 263fe14f3deb sh
/ # ldd /usr/bin/myproject
/lib/ld-musl-x86_64.so.1: /usr/bin/myproject: Not a valid dynamic program

[olpaw]

As @pmlopes explained this issue is not related to SVM and --static is verified to work as expected for 19.2. Please move the discussion to the vertx project.

[cvgaviao]

@olpaw, could you point me to an example POM and Dockerfile where --static is being used and working with Alpine, please ?

[olpaw]

@cvgaviao, sorry I do not have a POM and Dockerfile example around that I could share.

[smoell]

@olpaw My pom.xml can be found here: https://gist.github.com/smoell/0a63973de88560d0acbb0b2c7a955dee

[pulasthibandara]

Had a similar issue with making a http request with http4s. Adding glibc to the alpine image fixed it. (I was using the --static flag)