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 " $HOSTNAME" >> /etc/hosts

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

entrypoint: ['/bin/bash', '-c', 'echo " $HOSTNAME" >> /etc/hosts;']
1 Like

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

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

1 Like

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


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"

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


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).


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?


No worries!

From within the Host Container       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) ....

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

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.

1 Like