Reverse name lookup for hostname returns wrong IP

[pioneer2k]

Description

We are experiencing the issue that was mentioned before in issue 3185 (#3185) for over a month now. In the beginning we had the error only in some workflow runs. But this week, we had several errors in many workflow runs all over the day.
Our feeling is, that it is depending on the time of the day. The are times of the day where all our pipelines are breaking and there are times where all of them are working.

We now have implemented the workaround mentioned in issue 3185 and that is helping....

Virtual environments affected

• Ubuntu 18.04
• Ubuntu 20.04
• macOS 10.15
• macOS 11
• Windows Server 2016
• Windows Server 2019
• Windows Server 2022

Image version and build link

Virtual Environment
Environment: ubuntu-20.04
Version: 20220111.1
Virtual Environment Provisioner
1.0.0.0-main-20211214-1

Is it regression?

No response

Expected behavior

the command "hostname -i" should return the IP of the current hostname like the command "ip addr show eth0" does

Actual behavior

the command "hostname -i" returns a different IP address that does not belong to the current host.

Repro steps

add both command to a GitHub Actions workflow:
hostname -i
echo -e "$(ip addr show eth0 | grep "inet\b" | awk '{print $2}' | cut -d/ -f1)\t$(hostname -f) $(hostname -s)"

Both should show the same IP address, but sometimes they don't

[nikolai-frolov]

Hello @pioneer2k . Thanks for the issue reporting. We'll take care about this issue investigation and reply with findings.

[dmitry-shibanov]

Hello @pioneer2k. Thank you for your report. How often does it reproduce ? Could please provide link to the repository and logs from previous builds? We've tried to reproduce the issue from our side, but it works as expected. Besides, could you please provide logs from this snippet:

- run: |
      hostname -i
      echo -e "$(ip addr show eth0 | grep "inet\b" | awk '{print $2}' | cut -d/ -f1)\t$(hostname -f) $(hostname -s)"
- run: |
      cat /etc/hosts

[pioneer2k]

@dmitry-shibanov we had no problems today until now. But yesterday we had this issue multiple times all over the day.
In these cases we get the following outputs:
hostname -i ---> 10.1.0.38
echo -e "$(ip addr show eth0 | grep "inet\b" | awk '{print $2}' | cut -d/ -f1)\t$(hostname -f) $(hostname -s)" ---> 10.1.0.146 fv-az201-221.ett4tu3jvdse5ovc2mkgjqcs5a.bx.internal.cloudapp.net fv-az201-221

Our repositories are private. I don't know if you can read it.
Link to an erroneous run:
https://github.com/OttoPaymentHub/piranha_customer_context/runs/4854024549?check_suite_focus=true

I added your snipped to some of our pipelines. I come back to you when we get the error again.

[pioneer2k]

@dmitry-shibanov now I have a workflow run which shows the problem and has your code snippet available:
https://github.com/OttoPaymentHub/piranha_customer_context/runs/4880556158?check_suite_focus=true

Output:
10.1.1.110
10.1.0.190 fv-az290-692.z45yk40qnouupoc55gb0v1wkoc.jx.internal.cloudapp.net fv-az290-692
127.0.0.1 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
ff02::3 ip6-allhosts

[al-cheb]

@pioneer2k , Could you please attach a screenshot for the logs above - https://github.com/OttoPaymentHub/piranha_customer_context/runs/4880556158?check_suite_focus=true?

[pioneer2k]

@al-cheb is that enough or do you need more?

[oliver-sanders]

Here's a test run showing the results of calling the hostname and Python's socket interfaces to get the host name: https://github.com/oliver-sanders/actions-dns-test/actions/runs/1741184676

My test ran 10 jobs, 9 of which had matching configurations, one of which, test (1), differed.

hostname

test (0)

hostname -A: fv-az177-633 fv-az177-633 
hostname -d: le1l2vivn1merivib3blaulaih.cx.internal.cloudapp.net
hostname -f: fv-az177-633.le1l2vivn1merivib3blaulaih.cx.internal.cloudapp.net

test (1)

hostname -A: fv-az133-819.internal.cloudapp.net fv-az133-819 
hostname -d: ac31hddj4phu5ocom5smqd4hkf.cx.internal.cloudapp.net
hostname -f: fv-az133-819.ac31hddj4phu5ocom5smqd4hkf.cx.internal.cloudapp.net

Python socket

test (0)

socket.gethostname()                              : fv-az177-633
socket.getfqdn()                                  : fv-az177-633
socket.getfqdn(socket.gethostname())              : fv-az177-633
socket.getfqdn(socket.getfqdn())                  : fv-az177-633
socket.gethostbyname_ex(socket.gethostname())[0]  : fv-az177-633.le1l2vivn1merivib3blaulaih.cx.internal.cloudapp.net
socket.gethostbyname_ex(socket.getfqdn())[0]      : fv-az177-633.le1l2vivn1merivib3blaulaih.cx.internal.cloudapp.net

test (1)

socket.gethostname()                              : fv-az133-819
socket.getfqdn()                                  : fv-az133-819.internal.cloudapp.net
socket.getfqdn(socket.gethostname())              : fv-az133-819.internal.cloudapp.net
socket.getfqdn(socket.getfqdn())                  : fv-az133-819.internal.cloudapp.net
socket.gethostbyname_ex(socket.gethostname())[0]  : fv-az133-819.ac31hddj4phu5ocom5smqd4hkf.cx.internal.cloudapp.net
socket.gethostbyname_ex(socket.getfqdn())[0]      : fv-az133-819.internal.cloudapp.net

[miketimofeev]

@pioneer2k @oliver-sanders the root cause of the issue was fixed, but it will take some time to propagate the changes to all the environments.

[al-cheb]

@pioneer2k , Could you please check if the issue still persists?

[pioneer2k]

@al-cheb I have checked our pipeline runs of this week (about 20) and none of them had the error. Seems like your fix is working.