Hi all, It was fast ! thanks for your commitment!
May I ask for enlightenment (just so I better understand the thing): When the condition "if (!__res_sync)" is fulfilled ? Also, just to be sure: with the current fix for reloading resolv.conf, the call to stat() function will be done For each ns lookup call (each gethost* call). Is this a prb ? (performance issue I mean: it accesses the file system and all...) That is why I proposed to actually reload the resolv.conf only on ns lookup failure. I am not saying it is better or worse, this is an open question :) Note: drawback with reload on failure: the file is reloaded on every failure even though resolv.conf did not change it will not reload the resolv.conf if the previous nameserver are still valid potential drawback with reload on change: need to call stat() for every request (performance issue?) Regards, C. -----Message d'origine----- De : uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] De la part de Bernhard Reutner-Fischer Envoyé : mercredi 14 octobre 2009 08:31 À : tgh1...@acm.org Cc : uclibc@uclibc.org Objet : Re: gethostbyname Huh? Why on earth would we care about a missing resolv.conf there? On Oct 14, 2009 2:21 AM, "Timothy Holdener" <tgh1...@acm.org> wrote: On Tue, Oct 13, 2009 at 09:02:10PM +0200, Denys Vlasenko wrote: >Perhaps I thought time() is cheaper than stat(), but that's what i thought, yes :) >this patch will make us see new /etc/resolv.conf >at once -> better user experience. I like it. > > >+ static time_t resolv_conf_mtime; >... >+ struct stat sb; >+ stat("/etc/resolv.conf", &sb); >+ if ((difftime(resolv_conf_mtime, sb.st_mtime)) < 0) { > I came up with the same solution to this problem a month or two ago. (i.e. using 'stat' to determine if resolv.conf has changed.) Since we are using a 3-year-old version of uclibc, I never got around to making a patch compatible with the current code and submitting it. Bernhard's solution has one problem in that the call to stat will fail if /etc/resolv.conf does not exist. In that case, the value of sb.st_mtime is indeterminate. Here is a patch that should account for that case: --------------------------------------- --- a/libc/inet/resolv.c 2009-10-13 16:47:31.000000000 -0700 +++ b/libc/inet/resolv.c 2009-10-13 16:50:34.000000000 -0700 @@ -959,8 +959,13 @@ if (!__res_sync) { /* Reread /etc/resolv.conf if it was modified. */ struct stat sb; - stat("/etc/resolv.conf", &sb); - if (resolv_conf_mtime != (uint32_t)sb.st_mtime) { + if (stat("/etc/resolv.conf", &sb) < 0) { +#ifdef FALLBACK_TO_CONFIG_RESOLVCONF + if (stat("/etc/config/resolv.conf", &sb) < 0) +#endif + sb.st_mtime = 0; + } + if ((sb.st_mtime != 0) && (resolv_conf_mtime != (uint32_t)sb.st_mtime)) { resolv_conf_mtime = sb.st_mtime; __close_nameservers(); /* force config reread */ } --------------------------------------- -- _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc