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

[javanegmond]

Describe the bug

When using hostname in formatted logs (the %h option), the hostname at build time is logged rather than the runtime hostname.

This was reported and fixed a long time ago in this issue: https://github.com/quarkusio/quarkus/issues/14423

Expected behavior

The hostname at runtime is logged.

Actual behavior

The build time hostname is logged.

How to Reproduce?

Reproducer:

I created a reproducer here: https://github.com/javanegmond/quarkus-native-hostname

Steps to reproduce:

1. Native build with mvn clean install -Pnative
2. Start the application in a docker container:

   docker run -h runtime-hostname -it --rm --entrypoint=/target/native-hostname-1.0.0-SNAPSHOT-runner -v $PWD/target:/target -p 8080:8080 quay.io/quarkus/quarkus-micro-image:2.0
   

3. Call the service with a GET at http://localhost:8080/hello
4. Observe in the logging:

   2024/06/27 14:16:12.086 buildtime-hostname Hello from host runtime-hostname
   

Output of uname -a or ver

No response

Output of java -version

java version "21" 2023-09-19 LTS

Mandrel or GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.12.0

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)

Additional information

I was not able to find at what point in time this behaviour has changed back to the old faulty behaviour. In the reproducer I found it in Quarkus 3.12.0, but the project I first found it in was on Quarkus 3.9.5.

[quarkus-bot[bot]]

/cc @Karm (mandrel), @galderz (mandrel), @zakkak (mandrel,native-image)

[sberyozkin]

@Karm @javanegmond did you have to deal with the /lib64/libc.so.6: version GLIBC_2.34' not found` problem by any chance ? FYI, I'm on Fedora 40 which which has GLIBC_2.39... Fedora 40 has 2.39.15: https://koji.fedoraproject.org/koji/buildinfo?buildID=2461703

[javanegmond]

@Karm @javanegmond did you have to deal with the /lib64/libc.so.6: version GLIBC_2.34' not found` problem by any chance ? FYI, I'm on Fedora 40 which which has GLIBC_2.39... Fedora 40 has 2.39.15: https://koji.fedoraproject.org/koji/buildinfo?buildID=2461703

I have not. Looks to me like that's a whole separate issue from what I opened this issue for.

[sberyozkin]

@javanegmond Sorry, I should've clarified, your reproducer fails on my system due to this problem...

[javanegmond]

@javanegmond Sorry, I should've clarified, your reproducer fails on my system due to this problem...

The reproducer is nothing more than a getting-started project with logging and logging config. If that fails to build/execute, I'm going assume there's a totally unrelated issue with native builds that occurs on your system.

[sberyozkin]

@javanegmond Agreed, that it is an unrelated issue, it is just that I can't confirm the problem yet, but we'll check further.

By the way, can you consider

mvn -Dquarkus.native.container-build=true -Dquarkus.package.type=native install
docker build -f src/main/docker/Dockerfile.native-micro -t quarkus/quarkus-quickstart .

as a workaround for now ?

[javanegmond]

Sure thing. Building the project this way and running it with

docker run --rm -h runtime-hostname -p 8080:8080 quarkus/quarkus-quickstart

Followed by a GET on http://localhost:8080/hello shows the following in the logs:

__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2024/07/03 11:25:24.667 b9bc600fbfab native-hostname 1.0.0-SNAPSHOT native (powered by Quarkus 3.12.0) started in 0.027s. Listening on: http://0.0.0.0:8080
2024/07/03 11:25:24.667 b9bc600fbfab Profile prod activated. 
2024/07/03 11:25:24.667 b9bc600fbfab Installed features: [cdi, rest, smallrye-context-propagation, vertx]
2024/07/03 11:25:31.835 b9bc600fbfab Hello from host runtime-hostname

I'm going out on a limb and assume b9bc600fbfab is the hostname during the native container build - it surely isn't the hostname at runtime, nor the hostname of my machine.

[zakkak]

@Karm @javanegmond did you have to deal with the /lib64/libc.so.6: version GLIBC_2.34' not found` problem by any chance ? FYI, I'm on Fedora 40 which which has GLIBC_2.39... Fedora 40 has 2.39.15: https://koji.fedoraproject.org/koji/buildinfo?buildID=2461703

@sberyozkin this looks like an incompatibility between your build system and your runtime system. I suspect you are building using the builder image and trying to run the native executable on the host machine or vice versa. I recommend either running in a container like you suggest in https://github.com/quarkusio/quarkus/issues/41535#issuecomment-2205667305 (which as stated by @javanegmond doesn't look like a workaround to the original issue) or installing mandrel or GraalVM locally on the host machine and both building and running the reproducer on the host (without the use of containers).

[sberyozkin]

@zakkak Thanks for the feedback. I just followed steps in https://github.com/javanegmond/quarkus-native-hostname, and indeed I have a local GraalVM installed.

building and running the reproducer on the host (without the use of containers).

But then the runtime and buildtime host is the same, so it is not an issue, since nothing is leaked.

[javanegmond]

Any other method to have a different hostname at runtime than at buildtime could also suffice to reproduce the issue.

In the specific project I found the issue on first we're producing the native build on a Gitlab runner and deploying the container in a k8s pod.

[sberyozkin]

@javanegmond

I'm going out on a limb and assume b9bc600fbfab is the hostname during the native container build

Sure, this is why I called it a workaround. b9bc600fbfab is not a physical host name, a random string, it is still a problem which must be fixed but I'm not worried about this particular case.

[dmlloyd]

#41664 might solve this. I think maybe the logging library switched from wildfly-common to smallrye-common-net for this at some point? Anyway there's a decent chance that this solves the problem, if #14423 was fixed by a similar change.

[javanegmond]

#41664 might solve this. I think maybe the logging library switched from wildfly-common to smallrye-common-net for this at some point? Anyway there's a decent chance that this solves the problem, if #14423 was fixed by a similar change.

This seems to be on the right path. I ran the reproducer, but with quarkus.native.additional-build-args=--initialize-at-run-time=io.smallrye.common.net.HostName in application.properties and the proper hostname gets logged:

__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2024/07/03 13:50:26.165 runtime-hostname native-hostname 1.0.0-SNAPSHOT native (powered by Quarkus 3.12.0) started in 0.045s. Listening on: http://0.0.0.0:8080
2024/07/03 13:50:26.165 runtime-hostname Profile prod activated. 
2024/07/03 13:50:26.166 runtime-hostname Installed features: [cdi, rest, smallrye-context-propagation, vertx]
2024/07/03 13:51:22.283 runtime-hostname Hello from host runtime-hostname

[sberyozkin]

Thanks @dmlloyd for the fix

[sberyozkin]

@zakkak Hi Foivos, can you give me a favour and try the reproducer with the locally installed GraalVM 21, esp if you have Fedora 40 ? It is off-topic for this issue so can open a Discussion to follow up there

[zakkak]

@zakkak Hi Foivos, can you give me a favour and try the reproducer with the locally installed GraalVM 21, esp if you have Fedora 40 ? It is off-topic for this issue so can open a Discussion to follow up there

Hi @sberyozkin, I have tried the following combinations on my Fedora machine:

$ uname -a
Linux fedora 6.9.6-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun 21 15:48:21 UTC 2024 x86_64 GNU/Linux
$ /usr/lib64/libc.so.6         
GNU C Library (GNU libc) stable release version 2.39.
...

and glibc 2.39

Build using builder-image with podman and run on local host :heavy_check_mark:

$ mvn clean install -Pnative -Dquarkus.native.container-runtime=podman
...
$ ./target/native-hostname-1.0.0-SNAPSHOT-runner
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2024/07/04 11:30:01.306 6c12df7871b2 native-hostname 1.0.0-SNAPSHOT native (powered by Quarkus 3.12.0) started in 0.033s. Listening on: http://0.0.0.0:8080
2024/07/04 11:30:01.306 6c12df7871b2 Profile prod activated. 
2024/07/04 11:30:01.306 6c12df7871b2 Installed features: [cdi, rest, smallrye-context-propagation, vertx]
^C2024/07/04 11:31:51.034 6c12df7871b2 native-hostname stopped in 0.001s

Build using local installation and run on local host :heavy_check_mark:

$ export GRAALVM_HOME=~/.sdkman/candidates/java/23.1.3.1.r21-mandrel
$ mvn clean install -Pnative
...
$ ./target/native-hostname-1.0.0-SNAPSHOT-runner
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2024/07/04 11:34:28.694 fedora native-hostname 1.0.0-SNAPSHOT native (powered by Quarkus 3.12.0) started in 0.025s. Listening on: http://0.0.0.0:8080
2024/07/04 11:34:28.694 fedora Profile prod activated. 
2024/07/04 11:34:28.694 fedora Installed features: [cdi, rest, smallrye-context-propagation, vertx]

Build using local installation and run in a container fails as expected :x:

$ mvn -Dquarkus.native.container-build=true -Dquarkus.package.type=native install
...
$ podman build -f src/main/docker/Dockerfile.native-micro -t quarkus/quarkus-quickstart .
...
$ podman run --rm -h runtime-hostname -p 8080:8080 quarkus/quarkus-quickstart
./application: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by ./application)
./application: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by ./application)
./application: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./application)

since the glibc version in quay.io/quarkus/quarkus-micro-image:2.0 is 2.28:

$ podman run --rm quay.io/quarkus/quarkus-micro-image:2.0 /usr/lib64/libc.so.6
GNU C Library (GNU libc) stable release version 2.28.
...

[sberyozkin]

Hey @zakkak, thanks for the tests, summary,

So yeah, would it make sense to have quarkus micro image shipping the latest version of this library ? I can open an enhancement request, not sure where though

[zakkak]

would it make sense to have quarkus micro image shipping the latest version of this library ? I can open an enhancement request, not sure where though

I don't know. Fedora is quite at the edge so I think that as long as we are compatible with the glibc versions shipped with LTS GNU/Linux distributions it should be fine, but in any case not my call :)

[zakkak]

FWIW I confirm that https://github.com/quarkusio/quarkus/pull/41664 resolves this issue, I can no longer reproduce it with a Quarkus build based on the main branch.

[sberyozkin]

Thanks @zakkak, sure, let's see if more users will ask about it