Firefox slow to start due to waiting for systemd-resolved

Ask Fedora
, , , ,
1

Problem

After starting Firefox I’m missing any feedback for a starting application. After 2 minutes or more the browser appears and seems to be working just fine.

Analysis so far

The issue seems to be related to systemd-resolved. I’ve watched Firefox syscalls:

$ strace firefox
[…]
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 15
connect(15, {sa_family=AF_UNIX, sun_path="/run/systemd/resolve/io.systemd.Resolve"}, 42) = 0
sendto(15, "{\"method\":\"io.systemd.Resolve.Re"..., 100, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 100
recvfrom(15, 0x7f26d5544000, 131072, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
ppoll([{fd=15, events=POLLIN}], 1, {tv_sec=119, tv_nsec=999945000}, NULL, 8

this ppoll does take long until the browser does continue.

As you’ll have questions regarding systemd-resolved:

$ resolvectl
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (wlp0s20f3)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.87.77.1
       DNS Servers: 10.87.77.1 fd00::2e91:abff:fe8c:e9c0
        DNS Domain: fritz.box

During the startup time the following logs are being generated by systemd-resolved:

Jun 30 10:35:52 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server fd00::2e91:abff:fe8c:e9c0.

But in my history I do find different yet similar messages:

Jun 30 10:01:03 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of TCP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:01:34 hamlet systemd-resolved[6207]: Using degraded feature set TCP instead of UDP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:02:21 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of TCP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:02:53 hamlet systemd-resolved[6207]: Using degraded feature set TCP instead of UDP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:03:39 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of TCP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:04:11 hamlet systemd-resolved[6207]: Using degraded feature set TCP instead of UDP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:24:41 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of TCP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:25:13 hamlet systemd-resolved[6207]: Using degraded feature set TCP instead of UDP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:25:38 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of TCP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:30:50 hamlet systemd-resolved[6207]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server fd00::2e91:abff:fe8c:e9c0.

Workaround

I would love to help in th underlying general issue and will attempt to workaround the issue short term by disabling systemd-resolved according to Changes/systemd-resolved:

If you do not wish to use systemd-resolved, then manual intervention will be required to disable it:

  • Disable and stop systemd-resolved.service.
  • Delete /etc/resolv.conf
  • Restart the NetworkManager service. NetworkManager will then create a traditional /etc/resolv.conf. (If you are not using NetworkManager, you may create your own /etc/resolv.conf and configure it to your liking.)
1 Like
2

Can you reproduce the issue when using Google DNS or Cloudflare DNS exclusively?

3

Thank you, I missed checking that. I used my NetworkManager connection to enforce 1.1.1.1 as exclusive DNS and I cannot reproduce the issue.

$ resolvectl 
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1

Link 2 (wlp0s20f3)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1

My local DNS server is provided by a fritz.box, really common router in german housholds and the issue occured first today. I am providing this additional info to communicate that I would consider setting another DNS server to be another workaround, not a solution.

4

There are various issues caused by fritz.box behaviour. I don’t follow the details, but search systemd upstream.

1 Like
5

This indicates the issue is not so common, and most likely specific to some router’s firmware, so it’s problematic to reproduce, and a workaround might be your best option.

6

If found multiple bug reports that could be related to my issue - given the combination that the the DNS query done by Firefox during startup is added to the mix.

And there might be more - but I realized that I would not be able to help here due to me being stuck at the 90s state of DNS.

So I do agree that the best way currently is to just set an external DNS server like Cloudflare or Google in such connections. Currently I did pin the DNS server for my Fritzbox Wifi connection only.

7

I just ran into this problem because I wanted to use DNSOverTLS.

I don’t quite understand why Firefox takes so long to start even though the dns is super fast. As soon as firefox is running, all calls are also extremely fast. Only about:config causes the browser to freeze again for 2 minutes.

8
1 Like
9

thanks, seems to have helped

1 Like
10

I did this to enable systemd-resolved, and then set manual DNS on IPv4/6 to 127.0.0.1/::1 through NetworkManager (Workstation/GNOME) distros:fedora_workstation_gnome [RoE | Wiki]

I didn’t time Firefox, but it didn’t seem like it started up any slower than without systemd-resolved and upstream DNS.

11

There’s a problem in your instruction.
systemd-resolved is configured in mandatory DoT mode.
NetworkManager pushes its resolvers to systemd-resolved.
systemd-resolved rejects resolvers pushed by NetworkManager.
Those resolvers are redundant, non-DoT, and non-responsive.

1 Like
12

I’m running fedora on my laptop without dual boot and also have like a couple of minutes load time for firefox now after the upgrade to fedora 40. Before I upgraded to fedora 40 I had no problems with firefox.

Tried the “fix” with setting myhostname before resolve in /etc/nsswitch.conf but this didn’t change anything for me.

When not using a vpn it takes a couple of minutes. But when i’m using a vpn firefox loads instantly.

Microsoft edge loads instantly without vpn and with vpn.

13

Try to change your DNS provider to Cloudflare or Google:
Public recursive name server - Wikipedia

14

I had the same issue for months!

I corrected it by adding a line to my /etc/hosts file:
127.0.1.1 fedora

“fedora” in this case is my machine hostname (as in /etc/hostname).

See this and this.

15

I wonder why this would affect some and not others?

Firefox on F40 for me doesn’t take long to start; I changed my hostname, import a huge hosts file as-is and my hostname isn’t in that file.

I did hostname -f and it reported my hostname in just under a second.

16

It looks like nss-resolve fails due to a timeout, causing the query to continue with nss-myhostname.

This is probably related to systemd-resolved and its upstream resolver settings.