Closed Bug 117628 (resinit) Opened 24 years ago Closed 23 years ago

Conn: Fatal DNS error causes future lookups to fail

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: bugs, Assigned: dougt)

References

Details

(Whiteboard: [adt2] [driver:asa] [Needs r=] [ETA 05/03])

Attachments

(2 files, 9 obsolete files)

second try
4.87 KB, patch
Details | Diff | Splinter Review
Final Patch with shaver's configure suggestion
5.80 KB, patch
brendan
: review+
brendan
: superreview+
asa
: approval+
Details | Diff | Splinter Review
* OVERVIEW DESCRIPTION: A DNS lookup failure caused by network problems (e.g. not connected to a network) causes ALL future DNS lookups to fail even when the network problem is resolved. Requires a restart to clear. * STEPS TO REPRODUCE: 1. Adjust your networking situation such that there is no route to your DNS server(s). For dialup users, this simply means ensuring you are not connected to the Internet. 2. Open Mozilla and attempt to visit any Internet URL (this may happen simply by starting the browser, if you have a home page defined). You will (correctly) receive the message "www.example.com could not be found. Please check the name and try again." 3. Restore your network connectivity. 4. Again attempt to visit any URL (not necessarily the one you tried before). * ACTUAL RESULTS The DNS lookup will again fail, without any network activity taking place. No sites can be visited without restarting Mozilla. Especially annoying if you have many windows open. * EXPECTED RESULTS The DNS lookup should take place as normal and Mozilla should work normally. * BUILD DATE AND PLATFORM 2001122617 (rev 0.9.7). Installed from RPMs (from ftp.mozilla.org), running on a RedHat 7.2 machine. Also confirmed on 0.9.6 installed in a similar manner. Confirmed that it affects other applications using the Mozilla engine - confirmed on Galeon 1.0.2.
*** This bug has been marked as a duplicate of 64857 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
REOPEN: nsbeta1 This problem is probably fixable by doing what Darin proposes in bug 64857 (reseting the DNS list by using res_init), I think this is a distinct problem from what is being discussed in that bug. I'd like to have this problem considered separately, because we don't really know what is going on (for example, if this failure is ungraceful, restarting DNS w/in the application may not solve the problem). This would also explain some people's comments scattered in the dupes about how DNS just stops working in some situations.
Status: RESOLVED → UNCONFIRMED
Keywords: nsbeta1
Resolution: DUPLICATE → ---
Summary: Fatal DNS error causes future lookups to fail → Conn: Fatal DNS error causes future lookups to fail
this is a dupe of bug 117628 i didn't want to hurry and mark it as dupe of that one because this bug is nominated for nsbeta1 and the other is not. Benjamin, what should happen here? This becomes a dupe of that one or vice-versa?
->doug
Assignee: neeti → dougt
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
i meant bug 117613. sorry.
I think this is killing me. It certainly messes up autocomplete after I disconnect my laptop for long enough to lose the host route to my home router. When I reconnect, I can't hit Enter after typing in any URL that needs some kind of fixup (e.g., mozillazine.org/jason) but if I type http://www. at the front (http://www.mozillazine.org/jason) and hit Enter, the URL loads. Worse, the same bad state seems to cause Find, Save-As, and other dialogs to get stuck: to refuse to dismiss by any means (Cancel, x-button). I personally want this fixed instanter, for mozilla1.0 for sure. Cc'ing a bunch of people. This bug may be a dup of the unconfirmed bug 117613. /be
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oh, I forgot to mention this odd correlation: I can't left-click-and-hold on scrollbar arrows and auto-scroll, either, once my system gets into this bad state after disconnecting from the network and losing the host route. So: 1. Auto-complete doesn't work and Enter for entering URLs is useless unless the URL is "complete enough" (not sure if that means just well-formed by a string check for "http://" or even "http://www." at the front, or a cached DNS hit of some sort). 2. Dialogs cannot be dismissed. 3. Scrollbar arrow click-and-hold doesn't continuously scroll, it scrolls just one line or row. Cc'ing more folks. /be
we need to detect the dns failures, and at some point, we need to call res_init().
resolving this bug will be tricky. we should not call res_init ourselves since we don't know the thread-safety-ness of that function. we do know from past experience that glibc-2.2.4 (and above, i presume) will call res_init automatically the first time gethostbyname is called on a new thread. this means that we could solve this bug by restarting the DNS service (which drops the current DNS thread and creates a new one). this would only benefit newer systems like redhat 7.2 which include glibc-2.2.4, but i think that should cover the majority of our users. we would also want to do this only if we detect that /etc/resolv.conf has been modified after getting any sort of error returned from gethostbyname. so, we'd need to stat /etc/resolv.conf at startup.
(wonders why so much stuff breaks here...) Does IP addressed URL's still work?
I asked Ulrich Drepper at red hat about this and he said that "res_init() is an exported and supported interface. It is the right function to use. The libc simply cannot do this on its own." stating resolv.conf is not a thing that we should have to do.
if we don't stat resolv.conf, then how do we know when to call res_init? should we call res_init and retry gethostbyname (once) after each gethostbyname failure? it seems like it would be much better if we stat'd /etc/resolv.conf since we can therefore know when it makes sense to call res_init (or spawn a new DNS thread). as i said before, glibc-2.2.4 "effectively calls res_init" on its own the first time gethostbyname is called on a given thread. i'm concerned about calling res_init because we don't know how portable that function is and we also don't know if it is thread-safe. maybe it is thread-safe in glibc-2.2.x, but what about other libc's? maybe we should only try to solve this problem for linux (and any other platforms that support res_init via resolv.h, which definitely includes Darwin/OSX).
a conversation between darin and I: darinf19: stat on startup and then stat on failure, yes DougTnscp: what about smart browsing and other situations that cause dns failures? darinf19: np DougTnscp: seriously? darinf19: stat would reveal that there was no DNS settings changed DougTnscp: i know. what I am getting at is that there will be more stat() calls. darinf19: are you afraid that we'd end up stating too frequently? darinf19: ic DougTnscp: nod DougTnscp: page loader would not show us this. DougTnscp: it is probably noise. darinf19: maybe we shouldn't stat more than once per 30 seconds or something like that DougTnscp: that would suck. DougTnscp: well maybe. darinf19: no more than once per 5 seconds would even suffice DougTnscp: DNS fails - stat w/ some time restriction - if modified since, call res_init() on the main thread - requeue requests? DougTnscp: (is the above what you think should happen?) darinf19: yes darinf19: that sounds correct to me... DougTnscp: I wonder if we can just call res_init() instead of this stat-ing DougTnscp: but how will we know if the dns has changed, right? darinf19: you mean with the frequency restriction? DougTnscp: yes darinf19: right DougTnscp: we need to know if we should retry [the request].
gethostbyname isn't just about DNS, and therefore not just about resolv.conf. Changes in nsswitch.conf or yp configuration or whatever else can also manifest themselves this way. Calling res_init after every failure seems like a good thing (I don't think we need to retry -- the user can do so, and usually will). We can serialize it with a lock of our own, if we're concerned about tripping threadsafety problems.
Yeah, hostname lookups can come from a variety of places, including things you've never thought of ( it's an extensable mechanism with shared libraries, at least on linux. ) I'm not sure what the right mechanism here is, exactly. Maybe call it after a failure, but not more than X times an hour?
sounds even simplier. Does res_init have to be called from the main thread, or can it be called from the dns thread?
seems likely that no other components or plugins will ever try to call res_init, so a lock of our own would work (or no lock at all if we always call this from one thread), but can we get away with this assumption? probably.
what about other calls which call res_init? You mentioned gethostbyname()
good point! the man pages for res_init say that it will be called the first time gethostbyname is called. they don't mention per thread, but that is what i have observed w/ glibc-2.2.4.
Checking resolv.conf is the best way of seeing if there is a change in DNS servers because that is where the data is stored. name resolution does include other services, but nobody is complaining about them, and I don't think their info is cached anyhow (trying to remember w/o having DNS & BIND book handy). Checking on error AND providing a user-interface refresh is probably the best way to go. I wish there were a system service that told you when this changes, but there isn't (I don't know of many processes that persist across network changes while using DNS the way a browser does). There is no way to have Mozilla know the network has changed, unless we get more integration with dialers, DHCP and VPN clients. In this world, we can figure out (sometimes) when to refresh the DNS list, but we also need to give the user a button.
ben, please read comments #14 and #15. providing a user-interface refresh is really bad. If we handle this cause properly, the user should not have to do anything but reload the pages (or whatever) which caused the failed dns request.
dougt: There are situations mentioned in other bugs that are not referred to here. For example, if you are on the public network, but then switch to a VPN or private dialup, your existing DNS entries will probably continue to "work", because the external servers will be visible and respond. Except they won't use internal DNS, so they probably will not see any internal domains and/or internal hosts in "shadow" domains. I'm not sure what you mean by "bad". Some UI is probably needed. Some people reported that the proposed solution (hooking into Online/Offline) was working before, and there did not seem to be major objections (nobody filed a bug saying: clicking offline/online refreshed by DNS settings and it shouldn't have). (BTW: I try to read everything before I comment)
>Except they won't use internal DNS, so they probably will not see any internal domains and/or internal hosts in "shadow" domains. and when there is a dns lookup failure, we reinit the resolve. Where is the problem? >I'm not sure what you mean by "bad". Why should an application display a UI for extraordinary situations when they can be handle it programmatically?
Doug: Not all firewalls cut off internal users from external DNS. There will be no lookup failure in the situation I describe.
Attached patch proposed patch v.1 (obsolete) — — Splinter Review
note that you have to run autoconf to produce a updated configure file. cd ~/mozilla autoconf configure.in > configure
Woohoo! Alright dougt! I've been dying on account of this bug. Gordon and darin, can you r= and sr=? I'll add my 2 cents in a minute, and stand ready to a= for 1.0 if this tests well. We should get it into the trunk as soon as it's reviewed and smoketested. /be
Blocks: 138000
Keywords: mozilla1.0+
Comment on attachment 80960 [details] [diff] [review] proposed patch v.1 >@@ -59,7 +70,6 @@ > #endif > #include "prsystem.h" > #include "nsNetCID.h" >- > /****************************************************************************** > * Platform specific defines and includes > *****************************************************************************/ Nit: why lose that empty line? It looks better to me with a vertical space there. Accidental? >@@ -903,6 +916,10 @@ > PR_INIT_CLIST(&mPendingQ); > PR_INIT_CLIST(&mEvictionQ); > >+ // Lets say that the most times a reset can happen is one time every second. Nit: s/Lets/Let's/ >@@ -1130,6 +1147,27 @@ > } > } > >+#ifdef DNS_RESET >+void >+nsDNSService::Reset() >+{ >+#ifdef HAVE_RES_INIT >+ // On platforms where res_init() is available and supported >+ // by Mozilla, we shall attempt to reinitialize the dns >+ // resolver. Since this method may be called many times in >+ // a row, we shall restrict calling into res_init no more than >+ // once every mResetMaxInterval >+ if (gService && ( (PR_IntervalNow() - gService->mLastReset) >+ >= gService->mResetMaxInterval)) { Nit: it's easier to read if you break after the && and eliminate all the unnecessary parens, so the condition fits on one line: if (gService && PR_IntervalNow() - gService->mLastReset >= gService->mResetMaxInterval) { We've found the hard way that PRIntervalTime can fly, therefore wrap in 32 bits. Good to see that this comparison is immune to bad wrapping effects. >+ >+ _res.options &= ~RES_INIT; // XXX not sure if we need to clear this bit. Mebbe shaver knows. You could always check the open source and fine out. /be
I'll fix the nits. I sent mail to Ulrich regarding clearing that bit.
oh, the most imporant thing to mention is that i have not verified that this fixes the bug. I need testers. If it works for you, please indicate this fact in the bug.
this only sort of fixes the bug. if i enter "status" in the URL bar and am not behind the netscape firewall, mozilla will fail to resolve "status" and will try www.status.com instead. www.status.com is a registered domain name so the DNS lookup succeeds (even though the connection attempt fails in this particular example). if i then go behind the netscape firewall, and load "status" i again get redirected to www.status.com. this happens because the DNS lookup of "status" again fails. we call res_init, but docshell sees the error and continues to retry as www.status.com. on the next attempt of loading "status", i finally get status.mcom.com as desired. so, the patch works as designed, but it still sort of sucks for users. also, suppose "status" resolves correctly when i'm not behind the netscape firewall, and suppose i have a local caching-only DNS server that i use when not connected to the netscape firewall. my local caching-only DNS server will still work great when i go behind the netscape firewall (cuz it'll be able to see the root DNS servers, etc). gethostbyname will not fail in this case, and we'll never call res_init. this example may be a bit contrived, but i can certainly think of many other wacky examples (some of which might just show up in the real world). i guess my point is that we should provide some button that the user can press to forcibly call res_init (and flush our DNS cache?). how about the offline/online button? maybe something for another bug...
Comment on attachment 80960 [details] [diff] [review] proposed patch v.1 sr=darin
Attachment #80960 - Flags: superreview+
From darin's comments, do we need two bugs (which may already be on file -- if anyone knows of them, please cite them here)? 1. The docshell layer should transparently retry after a DNS miss failure that led to a successful Reset (res_init) call. 2. The work offline/online menu item should handle the local caching dns server case darin mentions, and others like it. /be
Mmmm, configure. /be
i think we should retry the DNS lookup after calling res_init. that would solve the wierd docshell interactions in a clean way. of course, we'd only want to retry once before failing for real.
Darin: agreed. Dougt, how about a revised patch that retries once after resetting, in the dns service layer? /be
Attached patch netwerk/dns/src patch (obsolete) — — Splinter Review
this does not include the config love. This patch will attempt another dns resolution if the first fails (still bounded by our mResetMaxInterval). untested.
Comment on attachment 80960 [details] [diff] [review] proposed patch v.1 We really shouldn't be checking for symbols that start with __. Those are internal glibc functions and are prone to change. To properly check for res_init, you'll need to use a AC_TRY_LINK test and #include <resolv.h> so that res_init is properly defined.
Attachment #80960 - Flags: needs-work+
could you hit me with a better configure.in? Please?
patch looks good, but why this change: - if (NS_FAILED(status)) MarkNotCacheable(); + if (NS_FAILED(status)) + MarkNotCacheable(); + else + MarkCacheable();
Brendan: re #2, bug 140232.
darin - ignore that changes. Was thinking about making DoSyncLookup reentrant but opt'ed out. I will remove the change: + else + MarkCacheable();
Attached patch Comprehensive Patch v.1 (obsolete) — — Splinter Review
Incorporates Darin's and Chris's suggestion. Also includes diffs to mozilla/configure.
Attachment #80960 - Attachment is obsolete: true
Attachment #81090 - Attachment is obsolete: true
Attachment #81115 - Attachment is obsolete: true
Comment on attachment 81167 [details] [diff] [review] Comprehensive Patch v.1 sr=darin w/o changes to configure of course =)
Attachment #81167 - Flags: superreview+
Attached patch w/o configure changes (obsolete) — — Splinter Review
Attachment #81167 - Attachment is obsolete: true
Comment on attachment 81184 [details] [diff] [review] w/o configure changes darin's sr
Attachment #81184 - Flags: superreview+
Target Milestone: --- → mozilla1.0
dougt, can you give us an update here, what we're waiting on? thanks.
Whiteboard: [adt2] → [adt2] [driver:asa]
Asa, this patch will cause race conditions. There is more work to be done. I will see if I can bang it out in the next day or two. From email between darin and I: Darin Fisher wrote: Yes, I agree (sort of). I don't think other threads will be calling res_init, but other threads might call gethostbyname while _the_ DNS thread is calling res_init, which might be an issue (see for example nsDNSService::Resolve). Resolve is called by a socket transport when opening a blocking input or output stream (IMAP opens blocking output streams, I think... or does it now use AsyncWrite... hmm). PAC also calls Resolve, which is triggered via preferences. Darin Doug Turner wrote: Ick! Why can't we queue this dns request and block the caller of Resolve()? Darin Fisher wrote: we certainly could do that, and maybe we should?! what about the LDAP SDK... does it call gethostbyname? darin
Attached patch uses res_ninit() (obsolete) — — Splinter Review
This should be *much* safer. Thanks mike for the pointer. One thing that this patch doesn't do but should is clear the dns cache if res_ninit is successful. If we don't do this, we can get into a situation where we don't resolve shadow domains correctly. This could be done later I guess as what we got here is *much* better for linux users than what is in the tree.
Attachment #81184 - Attachment is obsolete: true
Darin, Brendan, we need good turnaround on r= and sr= so this can land before tomorrow. Can you please take a look? Thanks.
Comment on attachment 81989 [details] [diff] [review] uses res_ninit() nice!! i'll test this out today.
Comment on attachment 81989 [details] [diff] [review] uses res_ninit() patch works great! sr=darin
Attachment #81989 - Flags: superreview+
dp - can you r= this one.
brendan or shaver should be the reviewers of this bug. They are the ones that have been on the many discussions we have had over email (bad bad) and know the threading problems that we are worried about. Instead of finding a body to review stuff, lets put pressure on the people that have reviewed previous version of the patch ! Brendan, Mike, please review or defer. Thanks. (no offense dp)
Keywords: nsdogfood
Whiteboard: [adt2] [driver:asa] → [adt2] [driver:asa] [Needs r=] [ETA 05/03]
Comment on attachment 81989 [details] [diff] [review] uses res_ninit() >+# note that DNS_RESET is only supported on Linux currently. This is due >+# to our available to test other platforms at this time. >+ifeq ($(OS_ARCH), Linux) >+DEFINES += -D_BSD_SOURCE -DDNS_RESET >+endif Why don't we just condition that on HAS_RES_NINIT, as tested by autoconf, rather than hardcoding in platform knowledge? >+PRStatus >+nsDNSLookup::DoSyncLookupInternal() I'm not a huge fan of trading in PRStatus result codes, when we have nsresults in use in the rest of the code, but I'll let it slide. Just this once! >Index: netwerk/dns//src/nsDnsService.h >=================================================================== >RCS file: /cvsroot/mozilla/netwerk/dns/src/nsDnsService.h,v >retrieving revision 1.34 >diff -u -r1.34 nsDnsService.h >--- netwerk/dns//src/nsDnsService.h 27 Mar 2002 04:09:17 -0000 1.34 >+++ netwerk/dns//src/nsDnsService.h 2 May 2002 06:00:59 -0000 >@@ -91,6 +91,13 @@ > static void Lock(); > static void Unlock(); > >+#ifdef DNS_RESET >+ // Attempts to reinitialize the dns resolver. This method must be called >+ // within the nsDNSService lock. >+ // Returns true if the dns resolves has been reset, otherwise false. >+ static PRBool Reset(); >+#endif Please don't ifdef the interface method. Let it just return NS_ERROR_NOT_IMPLEMENTED ifndef HAVE_RES_NINIT, and then as other platforms find a way to do threadsafe resolver resets they don't have to change code in more than one place.
I would argue that having an additional DNS_RESET define along with the HAS_RES_NINIT defeats the point of using autoconf. Shouldn't this all be conditionalized on HAS_RES_NINIT? Given that part of the reason for existence of res_ninit is threadsafety, are we actually worried that there are going to be platforms that both pass the HAS_RES_NINIT test and yet still fail here? I'm also a little leery (probably unnecessarily so) that we're gonna compile this file with _BSD_SOURCE, even though most of the rest of the tree isn't build that way. However, dougt assures me that lots of necko already is. fwiw, resolv.h on my linux box doesn't look like it needs this defined.
> Why don't we just condition that on HAS_RES_NINIT, as tested by autoconf, rather than hardcoding in platform knowledge? We didn't want to add risk to platforms that we didn't test. >Please don't ifdef the interface method. Let it just return NS_ERROR_NOT_IMPLEMENTED ifndef HAVE_RES_NINIT, and then as other platforms find a way to do threadsafe resolver resets they don't have to change code in more than one place. Okay. Fixed
>I would argue that having an additional DNS_RESET define along with the HAS_RES_NINIT defeats the point of using autoconf. Shouldn't this all be conditionalized on HAS_RES_NINIT? Feel free to test all the platforms that you are interested and remove this DNS_RESET. The check was added so that we didn't regress some platforms that we won't test. >I'm also a little leery (probably unnecessarily so) that we're gonna compile this file with _BSD_SOURCE, even though most of the rest of the tree isn't build that way. However, dougt assures me that lots of necko already is. fwiw, resolv.h on my linux box doesn't look like it needs this defined. File another bug. We should look into this at some point. Assign it to darin. :-)
Only includes changes from netwerk/dns/src/
resolv.h depends on some typedef's being defined (like u_char) that only get defined if _BSD_SOURCE is defined. normally, when you compile an app under redhat linux, _BSD_SOURCE is already defined. but, for the general mozilla codebase, we define _POSIX_SOURCE, which causes _BSD_SOURCE to not be automatically defined -- or something like that. so, defining _BSD_SOURCE is absolutely required. we also have to define _BSD_SOURCE in nsFileStreams.cpp to pick up the ftruncate library function.
Attachment #81989 - Attachment is obsolete: true
Attachment #82272 - Attachment is obsolete: true
Comment on attachment 82275 [details] [diff] [review] removes DNS_RESET - complete patch sr=darin
Attachment #82275 - Flags: superreview+
If I'm understanding what Darin and Dougt said correctly, the latest patch needs to be modified to have _BSD_SOURCE always be defined when HAS_RES_NINIT is defined. Otherwise it seems likely that we would break non-Linux platforms.
I think dmose is onto the right track: if we test for res_ninit with -D_BSD_SOURCE, then we need to always -D_BSD_SOURCE when we use it. Alternatively, we can #ifdef linux #define _BSD_SOURCE #endif in the autoconf test. I think I like the former option better, but I won't be picky. (No, really!)
Attachment #82275 - Attachment is obsolete: true
Attached patch second try — — Splinter Review
Attachment #82294 - Attachment is obsolete: true
Attachment #82296 - Flags: needs-work+
Comment on attachment 82298 [details] [diff] [review] Final Patch with shaver's configure suggestion +# note that DNS_RESET is only supported on Linux currently. This is due +# to our available to test other platforms at this time. Re-word starting at "This is due..." along these lines: "We're wrapping up 1.0 and we don't have time to test on other platforms right now." Bonus points: Capitalize "Note" at start of comment. - if (NS_FAILED(status)) MarkNotCacheable(); + if (NS_FAILED(status)) MarkNotCacheable(); Nit: for breakpointing, put the then part on its own line. Re-recording stamps. /be
Attachment #82298 - Flags: superreview+
Attachment #82298 - Flags: review+
Comment on attachment 82298 [details] [diff] [review] Final Patch with shaver's configure suggestion a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #82298 - Flags: approval+
cvs commit: Examining . Checking in Makefile.in; /cvsroot/mozilla/netwerk/dns/src/Makefile.in,v <-- Makefile.in new revision: 1.16; previous revision: 1.15 done Checking in nsDnsService.cpp; /cvsroot/mozilla/netwerk/dns/src/nsDnsService.cpp,v <-- nsDnsService.cpp new revision: 1.104; previous revision: 1.103 done Checking in nsDnsService.h; /cvsroot/mozilla/netwerk/dns/src/nsDnsService.h,v <-- nsDnsService.h new revision: 1.35; previous revision: 1.34 done Checking in configure.in; /cvsroot/mozilla/configure.in,v <-- configure.in new revision: 1.1037; previous revision: 1.1036 done Checking in configure; /cvsroot/mozilla/configure,v <-- configure new revision: 1.957; previous revision: 1.956 done Landed on trunk. I don't have time to check this in on the branch right now. Maybe next week.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Blocks: 143120
Landed on branch per asa: Checking in configure.in; /cvsroot/mozilla/configure.in,v <-- configure.in new revision: 1.1031.2.3; previous revision: 1.1031.2.2 done Checking in configure; /cvsroot/mozilla/configure,v <-- configure new revision: 1.949.2.4; previous revision: 1.949.2.3 done Checking in netwerk/dns/src/nsDnsService.cpp; /cvsroot/mozilla/netwerk/dns/src/nsDnsService.cpp,v <-- nsDnsService.cpp new revision: 1.103.2.2; previous revision: 1.103.2.1 done Checking in netwerk/dns/src/nsDnsService.h; /cvsroot/mozilla/netwerk/dns/src/nsDnsService.h,v <-- nsDnsService.h new revision: 1.34.2.2; previous revision: 1.34.2.1 done Checking in netwerk/dns/src/Makefile.in; /cvsroot/mozilla/netwerk/dns/src/Makefile.in,v <-- Makefile.in new revision: 1.15.16.2; previous revision: 1.15.16.1 done
Keywords: fixed1.0.0
Has there been any testing on the trunk to verify that the patch works and it hasn't regressed anything? Is this patch Linux only?
> Has there been any testing on the trunk to verify that the patch works and it hasn't regressed anything? Yes. Ask darin, brendan, or shaver. All who have run with this patch for a while. > Is this patch Linux only? basically. any system that defines res_ninit() via libc.
gordon/dougt -- can we close 63564 as a dup of this?
*** Bug 63564 has been marked as a duplicate of this bug. ***
This patch is the bee's knees for laptop roaming. Without it, you get hung windows, stuck modal dialogs, autocomplete failures, scrollbar malfunctions (one click per row scrolled in outliner, no continuous scroll on arrow click and hold), and other stuff seemingly unrelated to DNS. With this patch, roaming one's laptop from home to work, rebinding DNS automagically, works like a dream. /be
yup, this patch works great! now to break my habbit of closing mozilla before typing open_tunnel ;-) shaver: yeah, definitely a dupe.. thx!
(still wants to know why so much stuff breaks w/o DNS...)
I'm a dialup user and I'm still seeing the problem as described in the overview with RC3 (on Linux 2.4.4). Should'nt this be fixed in RC3???
This bug was fixed before rc3, so if you're seeing something like it, please open a new bug. Don't reopen this one, I can testify (from daily laptop roaming from work to home and back) that it's fixed. /be
In spite of the last comment, I don't believe that this bug is fixed. I'm seeing exactly what is described in the original bug report. The key is that the network connection must be down when mozilla is started. Things have been working when the network is up on startup and is taken down, then up again, as in a typical modem user's profile. (Haven't confirmed this on my latest build - 2002052708.) But that's not the problem reported here.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Peter, What OS? This will only work for those OS's that have a res_ninit() defined via libc (eg. not requiring additional linkages).
peter, please reopen a new bug with a complete description of the problem you are seeing. cite this bug if you like. marking as fixed *again*. If you have other problem similar to this bug ---- reopen a NEW bug
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
benc - can you verify this on the 1.0 branch, then remove fixed1.0.0, and replace it with verified1.0.0? thanks!
Keywords: verifyme
Doug T, I'm sorry I did not respond earlier, but I was off the CC list, for some reason. Before I start, please take this in the slightly jocular spirit in which it is written. My OS is linux, Redhat 7.3. My buildID is 2002052918. I have a ppp modem connection only. I still have this problem. I will not open a NEW bug, because I have a perfectly serviceable one right in front of me. I do not have a similar problem to this one, I have this problem. I do not need to completely re-describe my problem, because it is completely described at beginning of this bug. If you don't believe that I have this bug, why will you believe that I have a new bug with the identical description? I have just installed 1.0; I have completely rebuilt my profile; I have provided a separate profile for Netscape 7.0PR1, which I use rarely anyway. I still experience this problem. And I can't even get around it, as I once, long ago, could do, by toggling Offline/Online. Maybe it's my fault. Maybe I'm a bad person. Maybe I'm the only one in Christendom who experiences this. But experience it I do. I'm not going to re-open this bug. I'm going to leave that decision to you. BTW. This is a fabulous piece of software, and I am appropriately awe-struck with everyone involved. Congratulations on the release.
Here's the confusing from #83... "reopen a new bug" Peter, get a 1.0 build or later, create a new bug, and reference this bug and put a regression keyword in the bug. This problem was hard to isolate, the fix was hard to engineer, and I rarely saw clean problem descriptions or isolations in any of the duplicate bugs. I do not want to have this bug morph or triage multiple problem reports.
Raised #151683
Alias: resinit
Brendan: if I test RC3, should I be able to verify this build? I'm having problems verifying, and I think the problem is that I'm turning off my DNS server, rather than switching networks. Are there different errors returned for UDP that is non responsive (timeout) and not reachable (no route)? What are the error conditions where this change calls resinit()?
any DNS lookup failure will result in res_ninit being called.
VERFIED: 2002-09-04 (trunk) + Mozilla 1.0RC3 If a DNS server is working, then is unreachable (I used ifconfig eth0 down), then a new DNS entry will be read from /etc/resolv.conf. I used "pump" to fix my interface and update the /etc/resolv.conf, because it was faster than typing things by hand, and by my limited dialup knowledge, it is what some dialers use ij Linux. This means the DNS server down or timed out case is the regession/unfixed bug, depending on how you define the problem we solved here. This would explain why the duplicates have not been clean nor verified quickly. That is bug 166479.
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.0, verifyme → verified1.0.0
UPDATE: The code works, but only for certain versions of Linux. My testcase was actually incorrect, because I was trying to hack a simulation of other people's environments by configuring and hacking on my corporate network. So this bug remains VERIFIED, but not because of the case I provided above. Please see bug 166479 for any further details. Read that bug before commenting here or filing new regressions or related bugs.
Blocks: 120105
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: