Bug 2314175

Summary:	Regression: Hostname resolution requires that resolve times out first
Product:	[Fedora] Fedora	Reporter:	venanocta
Component:	authselect	Assignee:	Pavel Březina <pbrezina>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	40	CC:	pbrezina
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	All
OS:	Linux
URL:	https://discussion.fedoraproject.org/t/dnf-and-firefox-take-extreemly-long-to-start-when-vpn-active-on-f40/114604/6
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-09-23 09:17:17 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 ***