Slow startup because of attempt to connect to nameservers

NEW
Unassigned

Status

()

P3
normal
a year ago
3 months ago

People

(Reporter: tom.ty89, Unassigned, NeedInfo)

Tracking

57 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 attachment)

3.89 MB, text/plain
Details
(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Linux; Android 7.1.1; F5122 Build/34.3.A.0.217) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36

Steps to reproduce:

Have a static /etc/resolv.conf (using systemd-networkd but not systemd-resolved) with something like:

nameserver 8.8.8.8
nameserver 8.8.4.4

and start Firefox.


Actual results:

Firefox is takes a long time to start. With strace I can see that the stalling is due to attempts to connect to the listed nameservers. The problem would be gone if I removed /etc/resolv.conf (but certainly that won't be the solution). It seems to go away if I am connected to some oversea VPN server. Doesn't seem to help if I change the nameservers to OpenDNS ones or the local ones (well not so local but some sort of public DNS in my country, namely "114" in China).


Expected results:

I am not sure why Firefox make such attempts upon startup anyway.
Component: Untriaged → Networking
Product: Firefox → Core
Assignee: nobody → valentin.gosu
Whiteboard: [necko-active]
Thanks for reporting this.
I tried to reproduce it myself, but I've had no luck.
My connection to 8.8.8.8 is pretty fast, and when I tried with a non-existent dns server, Firefox still started up really fast.

After searching for a bit I came across something like this:
<< 2. DNS servers are poisoned if you use UDP. Anyway, if you try to use TCP to access these DNS servers, the connections are deliberately slowed down (by dropping TCP packets randomly). (For example, Google's 8.8.8.8 and 8.8.4.4) >>
https://www.quora.com/Why-is-the-Internet-so-slow-in-China-and-what-can-be-done-to-speed-it-up

The problem would probably be with very slow DNS servers. I'll try to emulate that. If a very slow DNS request is slowing down startup, that's definitely something we should look into.

Just as a curiosity, how slow is your startup?
Can you see if that matches the time it takes to do a DNS request?
And how long does this command take? time dig mozilla.org @8.8.8.8

Thanks
Flags: needinfo?(tom.ty89)
(Reporter)

Comment 2

a year ago
The startup time could range from 10s ~ 20s when the problem occurs. Without /etc/resolv.conf, or when I am connected to a VPN server, the startup time takes 1s ~ 2s.

`dig mozilla.org @8.8.8.8` right after a fresh reboot takes ~0.3s, after that each attempt takes ~0.03s.
Flags: needinfo?(tom.ty89)
Depends on: 1398646
Is this bug same as bug 1122097, which doesn't occur if setting network.dns.disableIPv6=true?
Sorry, was bug 1122907 in comment 3.
(Reporter)

Comment 6

a year ago
@Shian-Yow, network.dns.disableIPv6=true does not workaround the issue. Will see if the patch introduced in bug 1398646 fixes it.
(In reply to Tom Yan from comment #6)
> @Shian-Yow, network.dns.disableIPv6=true does not workaround the issue. Will
> see if the patch introduced in bug 1398646 fixes it.

Thanks for letting us know. You can check out the fix right now if you want, in Firefox Nightly: http://nightly.mozilla.org/

Updated

a year ago
Priority: P1 → P2
(Reporter)

Comment 8

a year ago
The issue still occurs in Firefox 57
Version: 55 Branch → 57 Branch
(Reporter)

Comment 9

a year ago
Created attachment 8929148 [details]
strace

/etc/resolv.conf has:

nameserver 114.114.114.114

The most relevant parts of the capture are probably:

...
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 7
connect(7, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("114.114.114.114")}, 16) = 0
poll([{fd=7, events=POLLOUT}], 1, 0)    = 1 ([{fd=7, revents=POLLOUT}])
sendto(7, " \337\1\0\0\1\0\0\0\0\0\0\tarchlinux\0\0\1\0\1", 27, MSG_NOSIGNAL, NULL, 0) = 27
poll([{fd=7, events=POLLIN}], 1, 5000)  = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7014, si_uid=1000, si_status=0, si_utime=2, si_stime=4} ---
restart_syscall(<... resuming interrupted poll ...>) = 0
poll([{fd=7, events=POLLOUT}], 1, 0)    = 1 ([{fd=7, revents=POLLOUT}])
sendto(7, " \337\1\0\0\1\0\0\0\0\0\0\tarchlinux\0\0\1\0\1", 27, MSG_NOSIGNAL, NULL, 0) = 27
poll([{fd=7, events=POLLIN}], 1, 5000)  = 1 ([{fd=7, revents=POLLIN}])
ioctl(7, FIONREAD, [102])               = 0
recvfrom(7, " \337\201\203\0\1\0\0\0\1\0\0\tarchlinux\0\0\1\0\1\0\0\6\0\1"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("114.114.114.114")}, [28->16]) = 102
...
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 8
connect(8, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("114.114.114.114")}, 16) = 0
poll([{fd=8, events=POLLOUT}], 1, 0)    = 1 ([{fd=8, revents=POLLOUT}])
sendto(8, "\16\237\1\0\0\1\0\0\0\0\0\0\tarchlinux\0\0\1\0\1", 27, MSG_NOSIGNAL, NULL, 0) = 27
poll([{fd=8, events=POLLIN}], 1, 5000)  = 0 (Timeout)
poll([{fd=8, events=POLLOUT}], 1, 0)    = 1 ([{fd=8, revents=POLLOUT}])
sendto(8, "\16\237\1\0\0\1\0\0\0\0\0\0\tarchlinux\0\0\1\0\1", 27, MSG_NOSIGNAL, NULL, 0) = 27
poll([{fd=8, events=POLLIN}], 1, 5000)  = 1 ([{fd=8, revents=POLLIN}])
ioctl(8, FIONREAD, [102])               = 0
recvfrom(8, "\16\237\201\203\0\1\0\0\0\1\0\0\tarchlinux\0\0\1\0\1\0\0\6\0\1"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("114.114.114.114")}, [28->16]) = 102
...
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Tom, can you tell us if this still happens with the latest Firefox?
If it does, could you also attach gdb to it, and paste the output of `thread apply all bt` ?
It might also be useful if you gathered some HTTP logs if possible: https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Assignee: valentin.gosu → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(tom.ty89)
Priority: P2 → P3
Whiteboard: [necko-active] → [necko-triaged]
You need to log in before you can comment on or make changes to this bug.