From libc-alpha-return-22754-pasky=ucw.cz@sourceware.org Tue Mar 16 00:47:00 2010 Return-Path: X-Original-To: pasky@pasky.or.cz Delivered-To: pasky@pasky.or.cz Received: from nikam.ms.mff.cuni.cz (nikam-dmz.ms.mff.cuni.cz [195.113.20.16]) by machine.or.cz (Postfix) with ESMTPS id C1B8586202A for ; Tue, 16 Mar 2010 00:47:00 +0100 (CET) Received: by nikam.ms.mff.cuni.cz (Postfix) id 9CDEC9AC7A4; Tue, 16 Mar 2010 00:47:00 +0100 (CET) Delivered-To: pasky@kam.mff.cuni.cz Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [89.250.246.4]) by nikam.ms.mff.cuni.cz (Postfix) with ESMTP id 99F0E9AC77B for ; Tue, 16 Mar 2010 00:47:00 +0100 (CET) Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by jabberwock.ucw.cz (Postfix) with SMTP id 14E1ACF040 for ; Tue, 16 Mar 2010 00:46:59 +0100 (CET) Received: (qmail 18956 invoked by alias); 15 Mar 2010 23:46:58 -0000 Delivered-To: moderator for libc-alpha@sourceware.org Received: (qmail 15843 invoked by uid 22791); 15 Mar 2010 17:23:15 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Message-ID: <4B9E6CFA.7020002@riot.org> Date: Mon, 15 Mar 2010 18:23:06 +0100 From: Sebastian Kienzl User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: libc-alpha@sourceware.org Subject: Reloading of /etc/resolv.conf Content-Type: multipart/mixed; boundary="------------060407080409020101000002" Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org This is a multi-part message in MIME format. --------------060407080409020101000002 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hello! There's a patch in the wild against the resolver which makes it reload /etc/resolv.conf on change, see http://sources.redhat.com/ml/libc-alpha/2004-09/msg00130.html However, this patch actually doesn't work properly for multi-threaded programs, as only one thread will notice the change and refresh its resolver state. I've attached a proper patch. It's for 2.5 but it should work with current versions, too. Even though the patch may not be interesting for upstream, I decided to let you know about this problem, since the mentioned patch seems to be used by at least Debian and Ubuntu. Regards, Seb. --------------060407080409020101000002 Content-Type: text/plain; name="glibc-2.5-resolvconf.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="glibc-2.5-resolvconf.patch" Index: glibc-2.17.90/resolv/res_libc.c =================================================================== --- glibc-2.17.90.orig/resolv/res_libc.c +++ glibc-2.17.90/resolv/res_libc.c @@ -22,6 +22,7 @@ #include #include #include +#include extern unsigned long long int __res_initstamp attribute_hidden; /* We have atomic increment operations on 64-bit platforms. */ @@ -89,12 +89,34 @@ res_init(void) { return (__res_vinit(&_res, 1)); } +static time_t resconf_mtime; +__libc_lock_define_initialized (static, resconf_mtime_lock); + +/* Check if the modification time of resolv.conf has changed. + If so, have all threads re-initialize their resolver states */ +static void +__res_check_resconf (void) +{ + struct stat statbuf; + if (stat (_PATH_RESCONF, &statbuf) == 0) { + __libc_lock_lock (resconf_mtime_lock); + if (statbuf.st_mtime != resconf_mtime) { + resconf_mtime = statbuf.st_mtime; + atomicinclock (lock); + atomicinc (__res_initstamp); + atomicincunlock (lock); + } + __libc_lock_unlock (resconf_mtime_lock); + } +} + /* Initialize resp if RES_INIT is not yet set or if res_init in some other thread requested re-initializing. */ int __res_maybe_init (res_state resp, int preinit) { if (resp->options & RES_INIT) { + __res_check_resconf (); if (__res_initstamp != resp->_u._ext.initstamp) { if (resp->nscount > 0) __res_iclose (resp, true);