$HOSTNAME Issues

Product support
1

After some experimentation, there seems to be an issue regarding localhost references from applications within containers when looking to resolve the hostname of the container. (See previous discussion here)

I am starting this thread because I’ve run across the issue again, this time when running X on a Raspberry Pi projects. Multiple references like:

xauth: (stdin):1:  bad display name "cb923e5:0" in "add" command

In order to fix this, I simply add this line to my start.sh script:

# Echo the localhost value
echo "Setting hostname..."
echo "127.0.0.1 $HOSTNAME" >> /etc/hosts

In a multicontainer format, you would have to do something like:

entrypoint: ['/bin/bash', '-c', 'echo "127.0.0.1 $HOSTNAME" >> /etc/hosts;']
2 Likes
4

Thanks for sharing a work around for this issue.

… but I think that it is not normal that the container instance can not resolve its own $HOSTNAME. So I guess that balena team needs to have a look at this.

1 Like
5

I 100% agree. Hopefully someone from the Balena team will look into this.

1 Like
6

I believe the correct way to do this is to use the Supervisor API within your container. This is what we do on our device. For instance, using curl within a service container:

curl --header "Content-Type:application/json" "$BALENA_SUPERVISOR_ADDRESS/v1/device/host-config?apikey=$BALENA_SUPERVISOR_API_KEY"

Here’s the API call documentation: https://www.balena.io/docs/reference/supervisor/supervisor-api/#patch-v1devicehost-config

8

Hey guys,

I’m fairly sure the behaviour you’re seeing is exactly what we expect, and the same behaviour is exhibited by docker too:

[12:37] ~ λ docker run -it debian /bin/sh -c "echo \$HOSTNAME"
6d87f9ae8861

The returned $HOSTNAME here is the short id of the container.

9

Sorry if I wasn’t clear as to why I started this thread - the $HOSTNAME Enviroment variable is working the way it’s supposed to, no issue there.

The problem I’m identifying is that the HOSTNAME is not automatically resolved correctly.

For example, if you try to issue a sudo command from within a vanilla balenalib container, you get an error (just like with X in the example above).

10

Hey @wwalker, ah the confusion is completely my fault, I misread the initial message, sorry!

I ran some sudo commands within a balena device container and in a local container on my laptop, and both worked without a hitch.

Could you post the output of your /etc/hosts from within the container please? I’d be interested to see the difference there.

Also any other information you could provide might be helpful, for example, are you changing the hostname of the container in the docker-compose, or doing anything else network related?

11

No worries!

From within the Host Container

127.0.0.1       localhost.localdomain           localhost

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

A great example of the issue I’m describing, is the log errors that appear when browsing the Pihole admin web control panel. The backend barfs up errors complaining that the hostname could not be resolved. The fix I posted above fixes this issue.

When I run sudo within my containers (across a variety of applications) I get the following:

root@62edf2c:/usr/src/app# sudo
sudo: unable to resolve host 62edf2c: No address associated with hostname
usage: sudo -h | -K | -k | -V
..... (more usage info) ....
14

The way I see it, a container should be able to resolve its $HOSTNAME.
Problem is that the $HOSTNAME points the the hosts name instead to the container ID as it does in docker normally.
I wonder if that is a problem in the baseimage and will confirm this with the team.

1 Like
19

Looked into it some more:
A ‘normal’ balenalib/%%BALENA_MACHINE_NAME%%-alpine:3.9 container will work as expected ($HOSTNAME = container id, gets resolved) as long as you do not enable host networking.
When host networking is enabled the $HOSTNAME becomes the name of the actual host (which makes sense) and it does not get resolved correctly any more .
I will forward this to the team to find a solution.

2 Likes
28

@wwalker

Sorry for the delay, but I think I have a handle on both what’s going on and how we can fix it. With host networking, the hostname is obviously changed to the device’s hostname, rather than the container having a specific one. As you’ve mentioned, it doesn’t appear in the balenaOS container’s /etc/hosts file.

On my desktop:

[8:54] test-repos/network λ docker run -it --net host balenalib/amd64-debian /bin/bash
root@Thor:/# cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	Thor

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

on a balena device:

root@ab3d181:~# balena exec -it main_1_1 bash    
bash-4.4# cat /etc/hosts
127.0.0.1	localhost.localdomain		localhost

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

My first thought was that the extraHosts field in the container create endpoint has some special meaning when null compared to an empty array [] (docker defaults to the former, but the supervisor defaults to the latter). I made the supervisor start using null as the default for this field, to no avail.

Other than the extraHosts field, I can’t see any other option controlling the /etc/hosts name. This leads me to believe that it’s either balenaEngine, or there’s some combination of options to container create that control this (documentation here: https://docs.docker.com/engine/api/v1.30/#operation/ContainerCreate)

Staying on the same thought process, I tried adding the following to the docker-compose of my host networked service:

    extra_hosts:
      - "ab3d181:127.0.0.1"

That’s my short uuid (or hostname) and the ip address it resolves to. And this works fine. So as a workaround, I’m sure we can get the supervisor to add this field to the extra_hosts array when using host networking, but I would much rather discover why it’s missing in the first place. In any case, I’ve made an issue to track this: https://github.com/balena-io/balena-supervisor/issues/994

I’m going to raise this internally, to see the best way to tackle it, but again, thanks so much for bringing it up. It’s these little, easy to miss bugs that can really annoy users!

1 Like