Bug 2314175 - Regression: Hostname resolution requires that resolve times out first
Summary: Regression: Hostname resolution requires that resolve times out first
Keywords:
Status: CLOSED DUPLICATE of bug 2291062
Alias: None
Product: Fedora
Classification: Fedora
Component: authselect
Version: 40
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Pavel Březina
QA Contact: Fedora Extras Quality Assurance
URL: https://discussion.fedoraproject.org/...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-09-23 08:49 UTC by venanocta
Modified: 2024-09-23 09:17 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-09-23 09:17:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description venanocta 2024-09-23 08:49:04 UTC
When "myhostname" is move behind "resolve" as done in patch "0011-profiles-put-myhostname-before-dns.patch" dns resolution slows to a crawl (2+ min) for the hostname alone.

The public reports show this usually happens when combined with always on VPNs like in my case Wireguard.

Especially affected applications are Firefox and dnf. Additionally, it causes timeouts in the "PackageKit Daemon" service (/usr/lib/systemd/system/packagekit.service).

From what I can see this is because these applications try to resolve the hostname and they have to wait for "resolve" to time out before the local hostname can be returned!

For details see the official blog posts discovering this Regression:
https://discussion.fedoraproject.org/t/packagekit-service-fails-after-upgrade-to-f40/114173/8
https://discussion.fedoraproject.org/t/any-dnf-command-lasts-more-than-a-minute/114725
https://discussion.fedoraproject.org/t/dnf-and-firefox-take-extreemly-long-to-start-when-vpn-active-on-f40/114604/6






Reproducible: Always

Steps to Reproduce:
# /etc/nsswitch.conf
## hosts:      files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns
$ time getent hosts $(hostnamectl hostname)
Actual Results:  
fe80::5303:3bac:39e5:be66 workstation-linux

real	2m0,147s
user	0m0,002s
sys	0m0,009s

Expected Results:  
fe80::5303:3bac:39e5:be66 workstation-linux

real	0m0,090s
user	0m0,002s
sys	0m0,008s

Comment 1 venanocta 2024-09-23 09:08:05 UTC
I found another service that errors out: "NFSv4 ID-name mapping service" (/usr/lib/systemd/system/nfs-idmapd.service).

Before fixing the service log reads:
| Starting nfs-idmapd.service - NFSv4 ID-name mapping service...
| Setting log level to 0
| nfs-idmapd.service: start operation timed out. Terminating.
| nfs-idmapd.service: Failed with result 'timeout'.
| Failed to start nfs-idmapd.service - NFSv4 ID-name mapping service.

After fixing the regression the service prints the log lines and stays active:
| Starting nfs-idmapd.service - NFSv4 ID-name mapping service...
| Setting log level to 0
| libnfsidmap: Unable to determine the NFSv4 domain; Using 'localdomain' as the NFSv4 domain which means UIDs will be mapped to the 'Nobody-User' user defined in /etc/idmapd.conf
| Started nfs-idmapd.service - NFSv4 ID-name mapping service.

Therefore, the log prompts me to believe that it hoped resolve "localdomain" which originates from the hosts file but time out.

I originally thought that I misconfigured this service as I did not change the default config after installing it.
As I have been having tons of issues with my nfs shares after updating from f38 to f40 this might be the issue of my nfs troubles, but at this time I can not say if this was truly the cause.

Comment 2 Pavel Březina 2024-09-23 09:17:17 UTC

*** This bug has been marked as a duplicate of bug 2291062 ***


Note You need to log in before you can comment on or make changes to this bug.