Log records show the hostname on which the native executable was generated

[vietk]

Describe the bug

When a native application is using a log pattern that includes the hostname of the machine, then the hostname displayed is the one of the machine on which the native executable has been generated.

Imagine two machines with the following hostname :

• build-time-hostname: the hostname of the computer used to build the native image
• runtime-hostname: the hostname of the machine running the native image

If the application uses the following log format :

quarkus.log.console.format=%d{yyyy/MM/dd HH:mm:ss.SSS} %h %m%n

where %h should display the hostname, then log statements as shown below

logger.info("runtime hostname:" + InetAddress.getLocalHost().getHostName());

will output the following:

Expected behavior

I would expect the runtime-hostname to be used in the logs

Actual behavior

JBoss logging system uses org.wildlfy.common.net.Hostname to get a reference on the hostname.

But the references are stored in a static field which is initialized in a static block

    static {
        String[] names = doPrivileged(new GetHostInfoAction());
        hostName = names[0];
        qualifiedHostName = names[1];
        nodeName = names[2];
    }

At native image build time, the static block is recorded in the image heap and then the same value is used for any subsequent calls during the runtime of the application notably in the log system.

To Reproduce

I have reproduced the issue by modifying the basic quickstart project here : https://github.com/vietk/quarkus-quickstarts/tree/reproducer/build-time-hostname.
I use docker containers in order to have 2 different machine

Steps to reproduce the behavior:

1. call mvn clean install -Pnative -DskipTests
2. call docker run -h runtime-host-name -it --entrypoint=/target/getting-started-1.0-SNAPSHOT-runner -v $PWD/target:/target -p 8080:8080 quay.io/quarkus/ubi-quarkus-native-image:20.2.0-java11 that override the hostname with -h runtime-host-name
3. call the service of the application http://localhost:8080/hello/greeting/helloworld

Environment (please complete the following information):

• Quarkus version or git rev: 1.10.4.Final
• Build tool: mvn

Best regards,
Kevin

[gsmet]

/cc @dmlloyd @jamezp

[dmlloyd]

This surely must be a regression; I remember testing this way back. Perhaps relating to switching over to smallrye-common for the host name - maybe a substitution is missing now (i.e. pointing at the wrong class)?

[jaikiran]

Hello @dmlloyd,

Perhaps relating to switching over to smallrye-common for the host name - maybe a substitution is missing now (i.e. pointing at the wrong class)?

I guess that's indeed the case - this substitution in smallrye-common is targetting the wrong class https://github.com/smallrye/smallrye-common/blob/master/net/src/main/java/io/smallrye/common/net/Substitutions.java#L19 (target class should have been io.smallrye.common.net.GetHostInfoAction). I haven't checked rest o the code in that project. I guess there might be more such copy/paste migration issues?

[jaikiran]

I've raised smallrye/smallrye-common#75 with a patch. Having said that, I don't see how that one substitution alone will prevent the computed host name at build time to not be stored for runtime.

[jaikiran]

I've opened #14603 with a potential fix.