hostname -s no longer resolvable
garazdawi opened this issue · comments
Hello,
With the release of 3.1.0 the hostname command when running travis on a ec2 docker worker changed from being a shortname to being a fqdn. This change broke our ci smoke tests at http://github.com/erlang/otp because we rely on being able to resolve both hostname -s and hostname. This was not a problem prior to 3.1.0 as hostname and hostname -s were the same thing.
I've implemented a workaround for us that skips the tests that rely on this behavior for now. But it would be great if both hostname and hostname -s could be resolvable in the container.
PS, there is no problem when running on gce, as there the shortname seems to be resolvable. DS.
@garazdawi Hello! Is the problem that it's a FQDN (which it shouldn't be) or that it has dots in the name?
hmm, good question. You can find an example of a broken build here: https://travis-ci.org/garazdawi/otp/jobs/288474994
hostname returns a fqdn, in my case travis-job.garazdawi.otp.288474994.travisci.net.
When you pointed out that it could be the dots in the name I noticed that /etc/hosts contains travis-job.garazdawi.otp.288474994 as an alias, which would have worked if it wasn't for the dots in the name.
So it would seem that it is the dots in the name that is making Erlang miss-behave.
A quick google on using dots in hostnames seems to say that you shouldn't do that as you are asking for all kinds of problems if you do. https://serverfault.com/questions/229331/can-i-have-dots-in-a-hostname
I'm guessing this means we'll have to switch from dots to dashes 😿. Ah well...