Repository navigation
Conversation
To allow `hostname --fqdn` to work correctly. Putting myhostname early prevents lookup of canonical hostname if only shortname is provided. myhostname has been moved back and forth several times, it looks like this place is now functional and works as expected.
| shadow: files | ||
| group: files [SUCCESS=merge] {if "with-altfiles":altfiles [SUCCESS=merge] }systemd | ||
| hosts: files myhostname {if "with-libvirt":libvirt libvirt_guest }{if "with-mdns4" and "with-mdns6":mdns_minimal [NOTFOUND=return] }{if "with-mdns4" and not "with-mdns6":mdns4_minimal [NOTFOUND=return] }{if not "with-mdns4" and "with-mdns6":mdns6_minimal [NOTFOUND=return] }resolve [!UNAVAIL=return] dns | ||
| hosts: files {if "with-libvirt":libvirt libvirt_guest }{if "with-mdns4" and "with-mdns6":mdns_minimal [NOTFOUND=return] }{if "with-mdns4" and not "with-mdns6":mdns4_minimal [NOTFOUND=return] }{if not "with-mdns4" and "with-mdns6":mdns6_minimal [NOTFOUND=return] }resolve [!UNAVAIL=return] myhostname dns |
There was a problem hiding this comment.
Changing the priority of myhostname seems to negatively impact local host name look-ups when using virtual private networks (or VPNs):
https://bugzilla.redhat.com/show_bug.cgi?id=2291062
There was a problem hiding this comment.
Expanding on the problem that @debarshiray describes - the problem is that toolbox is in a different UTS namespace and the value of gethostname() inside the toolbox container is different than the value that systemd-resolved sees. A more minimal example demonstrating the issue:
$ time podman run -v /run/dbus/system_bus_socket:/run/dbus/system_bus_socket --hostname toolbox --net=host --rm fedora:40 python3 -c "import socket; print(socket.getaddrinfo('toolbox', None))"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib64/python3.12/socket.py", line 963, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
socket.gaierror: [Errno -2] Name or service not known
real 0m4.100s
user 0m0.097s
sys 0m0.069s
$ time podman run -v /run/dbus/system_bus_socket:/run/dbus/system_bus_socket --hostname toolbox --net=host --rm fedora:39 python3 -c "import socket; print(socket.getaddrinfo('toolbox', None))"
[(<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('fe80::4078:bf60:5288:fe25', 0, 0, 3)), (<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_DGRAM: 2>, 17, '', ('fe80::4078:bf60:5288:fe25', 0, 0, 3)), (<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_RAW: 3>, 0, '', ('fe80::4078:bf60:5288:fe25', 0, 0, 3)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('192.168.10.240', 0)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, '', ('192.168.10.240', 0)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_RAW: 3>, 0, '', ('192.168.10.240', 0))]
real 0m0.200s
user 0m0.045s
sys 0m0.048s
These timeouts are going to affect many programs in different ways - I encountered multi-second hangs when running mock inside a toolbox because one of its dependencies calls socket.fqdn() which triggers this.
Possible fixes:
- Revert this change entirely in Fedora (where this patch is patched in)
- Revert this fix when creating a toolbox
- Somehow make systemd-resolved sensitive to the UTS of the caller - e.g., by having nss-resolve pass the hostname value along with the request.
There was a problem hiding this comment.
Thank you for the summary. So far, I am still waiting for some resolution on the bugzilla that will clearly state if this should be reverted or not.
At the same time, I will not push it in master until there is a resolution.
|
I am closing this for the time being since this order causes issues to lots of users. This is reverted in Fedora. |
3 participants
To allow
hostname --fqdnto work correctly. Putting myhostname earlyprevents lookup of canonical hostname if only shortname is provided.
myhostname has been moved back and forth several times, it looks
like this place is now functional and works as expected.
See: https://bugzilla.redhat.com/show_bug.cgi?id=2257197#c11