Hi,
After a system update 2-3 weeks ago, applications like java and firefox began to take a quite long time to start up (an extra ~10s). However this only occurs when I am connected to a network, when my laptop is running unconnected everything is fine (however it doesn't matter wether I am connected at home or in the office, so the cause is not a malfunction of my DNS server).
Today I tried to find out what is going on and it seems the applications are stalled while looking up the hostname of my own machine ("user-pc"). Shouldn't in this case the lookup return immediantly? As I haven't changed my configuration at all, any idea which update introduced this issue?
Thank you in advance, Clemens
Stacktrace of firefox starting up:
#0 0x0000003fd7aeb7fd in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x0000003fd9e0ad0d in send_dg (resplen2=0x0, anssizp2=0x0, ansp2=0x0, anscp=0x7fffeeec0970, gotsomewhere=<synthetic pointer>, v_circuit=<synthetic pointer>, ns=0, terrno=0x7fffeeebf8f0, anssizp=0x7fffeeebfa30, ansp=0x7fffeeebf8e8, buflen2=0, buf2=0x0, buflen=32, buf=0x7fffeeebfa60 ";\327\001", statp=0x3fd7dbeaa0 <_res@GLIBC_2.2.5>) at res_send.c:1059 #2 __libc_res_nsend (statp=statp@entry=0x3fd7dbeaa0 <_res@GLIBC_2.2.5>, buf=buf@entry=0x7fffeeebfa60 ";\327\001", buflen=<optimized out>, buf2=buf2@entry=0x0, buflen2=buflen2@entry=0, ans=ans@entry=0x7fffeeec0540 "", anssiz=anssiz@entry=1024, ansp=ansp@entry=0x7fffeeec0970, ansp2=ansp2@entry=0x0, nansp2=nansp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_send.c:556 #3 0x0000003fd9e08c47 in __GI___libc_res_nquery (statp=statp@entry=0x3fd7dbeaa0 <_res@GLIBC_2.2.5>, name=name@entry=0x7fffeeec00c0 "user-pc.3.home", class=class@entry=1, type=type@entry=1, answer=answer@entry=0x7fffeeec0540 "", anslen=anslen@entry=1024, answerp=answerp@entry=0x7fffeeec0970, answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_query.c:226 #4 0x0000003fd9e096ab in __libc_res_nquerydomain (resplen2=0x0, nanswerp2=0x0, answerp2=0x0, answerp=0x7fffeeec0970, anslen=1024, answer=0x7fffeeec0540 "", type=1, class=1, domain=<optimized out>, name=0x7fffeeec1538 "user-pc", statp=0x3fd7dbeaa0 <_res@GLIBC_2.2.5>) at res_query.c:582 #5 __GI___libc_res_nsearch (statp=0x3fd7dbeaa0 <_res@GLIBC_2.2.5>, name=name@entry=0x7fffeeec1538 "user-pc", class=class@entry=1, type=type@entry=1, answer=answer@entry=0x7fffeeec0540 "", anslen=anslen@entry=1024, answerp=0x7fffeeec0970, answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0) at res_query.c:416 #6 0x00007fd0409e17e4 in __GI__nss_dns_gethostbyname3_r (name=name@entry=0x7fffeeec1538 "user-pc", af=af@entry=2, result=result@entry=0x7fffeeec0f00, buffer=buffer@entry=0x7fffeeec0f20 "\177", buflen=buflen@entry=1024, errnop=errnop@entry=0x7fd04e259690, h_errnop=h_errnop@entry=0x7fffeeec0ef4, ttlp=ttlp@entry=0x0, canonp=canonp@entry=0x0) at nss_dns/dns-host.c:192 #7 0x00007fd0409e1af0 in _nss_dns_gethostbyname_r (name=0x7fffeeec1538 "user-pc", result=0x7fffeeec0f00, buffer=0x7fffeeec0f20 "\177", buflen=1024, errnop=0x7fd04e259690, h_errnop=0x7fffeeec0ef4) at nss_dns/dns-host.c:273 #8 0x0000003fd7b0ebd3 in __gethostbyname_r (name=0x7fffeeec1538 "user-pc", resbuf=0x7fffeeec0f00, buffer=0x7fffeeec0f20 "\177", buflen=1024, result=0x7fffeeec0ef8, h_errnop=0x7fffeeec0ef4) at ../nss/getXXbyYY_r.c:263 #9 0x0000003fe921b467 in PR_GetHostByName () from /lib64/libnspr4.so #10 0x00007fd04b25f8fa in nsProfileLock::LockWithSymlink(nsIFile*, bool) () from /usr/lib64/firefox/xulrunner/libxul.so #11 0x00007fd04b25fe92 in nsProfileLock::Lock(nsIFile*, nsIProfileUnlocker**) () from /usr/lib64/firefox/xulrunner/libxul.so #12 0x00007fd04b26073b in nsToolkitProfileLock::Init(nsIFile*, nsIFile*, nsIProfileUnlocker**) () from /usr/lib64/firefox/xulrunner/libxul.so #13 0x00007fd04b260784 in nsToolkitProfileLock::Init(nsToolkitProfile*, nsIProfileUnlocker**) () from /usr/lib64/firefox/xulrunner/libxul.so #14 0x00007fd04b260837 in nsToolkitProfile::Lock(nsIProfileUnlocker**, nsIProfileLock**) () from /usr/lib64/firefox/xulrunner/libxul.so #15 0x00007fd04b25a4ca in XREMain::XRE_mainStartup(bool*) () from /usr/lib64/firefox/xulrunner/libxul.so #16 0x00007fd04b25b338 in XREMain::XRE_main(int, char**, nsXREAppData const*) () from /usr/lib64/firefox/xulrunner/libxul.so #17 0x00007fd04b25b5d3 in XRE_main () from /usr/lib64/firefox/xulrunner/libxul.so #18 0x0000000000403d2f in do_main(int, char**, nsIFile*) () #19 0x00000000004034fc in main ()
Clemens,
Have you find out this on a particular network? I.e. a business, job, etc. Some companies are mostly windows shops that run extra software like AV detector, compliance rules that add overhead while you open up a browser or turn it on. Safe Connect is an example of this. Have you try this on your own home network and find any difference?
Clemens Eisserer writes:
Hi,
After a system update 2-3 weeks ago, applications like java and firefox began to take a quite long time to start up (an extra ~10s). However this only occurs when I am connected to a network, when my laptop is running unconnected everything is fine (however it doesn't matter wether I am connected at home or in the office, so the cause is not a malfunction of my DNS server).
Today I tried to find out what is going on and it seems the applications are stalled while looking up the hostname of my own machine ("user-pc"). Shouldn't in this case the lookup return immediantly?
Actually, according to your stacktrace below, the DNS lookup is for "user-pc. 3.home".
What happens when you execute
dig user-pc.3.home a
Hi Sam,
Actually, according to your stacktrace below, the DNS lookup is for "user-pc.3.home".
What happens when you execute
I get the usual lag (~5s) and after this the following output:
[ce@user-pc ~]$ dig user-pc.3.home a ; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-5.P2.fc19 <<>> user-pc.3.home a ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15712 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION: ;user-pc.3.home. IN A
;; AUTHORITY SECTION: . 3600 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013112301 1800 900 604800 86400
;; Query time: 4301 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Nov 23 14:53:06 EST 2013 ;; MSG SIZE rcvd: 107
Regards, Clemens