From owner-freebsd-arch@freebsd.org Wed Oct 7 21:02:41 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DED799D14F7 for ; Wed, 7 Oct 2015 21:02:41 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id C8651F32 for ; Wed, 7 Oct 2015 21:02:41 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from marvin.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id C62B456483 for ; Wed, 7 Oct 2015 16:02:40 -0500 (CDT) From: Eric van Gyzen Subject: RFC: Automatically Reloading /etc/resolv.conf X-Enigmail-Draft-Status: N1110 To: freebsd-arch@freebsd.org Message-ID: <5615886F.3060601@FreeBSD.org> Date: Wed, 7 Oct 2015 16:02:39 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 21:02:42 -0000 I would like to change the libc resolver to automatically reload /etc/resolv.conf when the latter changes. I would like to hear opinions about the implementation. Broadly, I see two approaches. == "stat" == When loading the file, record the mod time. Before each query, stat() the file to see if it has changed. Advantage: It uses no extra persistently allocated objects. Disadvantage: It incurs a stat() on every query. I don't see this as a major disadvantage, since the resolver already does a lot of work on every query. (For example, it creates and destroys a kqueue and a socket.) OpenBSD uses this approach. It also uses clock_gettime(CLOCK_MONOTONIC) to rate-limit the stat() calls to one per several seconds. == "kqueue" == When loading the file, open a kqueue and register for the appropriate events. Before each query, check for kevents. Advantage: The per-query overhead is fairly small. Disadvantage: This would persistently allocate an open file and a kqueue for every thread that ever uses the resolver, for the life of the thread. This seems fairly expensive. NetBSD uses this approach. It mitigates most of the space-cost by using a shared pool of res_state objects, instead of one per thread [that uses the resolver]. On each query, a thread allocates/borrows a res_state from the pool, uses it, and returns it. So, the number of objects is only the high water mark of the number of threads _concurrently_ issuing resolver queries. There are probably several variations on each theme, of course. I would appreciate your thoughts on these approaches and others I missed, as well as variations and details. FYI, I'm leaning toward the "stat" approach. Cheers, Eric From owner-freebsd-arch@freebsd.org Wed Oct 7 21:56:02 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 940399D17FB for ; Wed, 7 Oct 2015 21:56:02 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D7D8E9E; Wed, 7 Oct 2015 21:56:02 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 0499DB8098; Wed, 7 Oct 2015 23:55:59 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id DE50928494; Wed, 7 Oct 2015 23:55:58 +0200 (CEST) Date: Wed, 7 Oct 2015 23:55:58 +0200 From: Jilles Tjoelker To: Eric van Gyzen Cc: freebsd-arch@freebsd.org Subject: Re: RFC: Automatically Reloading /etc/resolv.conf Message-ID: <20151007215558.GA41787@stack.nl> References: <5615886F.3060601@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5615886F.3060601@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 21:56:02 -0000 On Wed, Oct 07, 2015 at 04:02:39PM -0500, Eric van Gyzen wrote: > I would like to change the libc resolver to automatically reload > /etc/resolv.conf when the latter changes. I would like to hear opinions > about the implementation. Broadly, I see two approaches. > == "stat" == > When loading the file, record the mod time. Before each query, stat() > the file to see if it has changed. > Advantage: It uses no extra persistently allocated objects. > Disadvantage: It incurs a stat() on every query. I don't see this as a > major disadvantage, since the resolver already does a lot of work on > every query. (For example, it creates and destroys a kqueue and a socket.) > OpenBSD uses this approach. It also uses clock_gettime(CLOCK_MONOTONIC) > to rate-limit the stat() calls to one per several seconds. This looks reasonable. Nitpick: the resolver has used poll instead of kqueue for a while, but that does not fundamentally change your argument. Some glibc people think the extra stat may be too slow, though: https://sourceware.org/bugzilla/show_bug.cgi?id=984 > == "kqueue" == > When loading the file, open a kqueue and register for the appropriate > events. Before each query, check for kevents. > Advantage: The per-query overhead is fairly small. > Disadvantage: This would persistently allocate an open file and a > kqueue for every thread that ever uses the resolver, for the life of the > thread. This seems fairly expensive. This sounds a bit scary in conjunction with code that bluntly closes file descriptors it does not know about. Also, kqueues do not inherit across fork, so the resolver needs some sort of atfork handler. > NetBSD uses this approach. It mitigates most of the space-cost by using > a shared pool of res_state objects, instead of one per thread [that uses > the resolver]. On each query, a thread allocates/borrows a res_state > from the pool, uses it, and returns it. So, the number of objects is > only the high water mark of the number of threads _concurrently_ issuing > resolver queries. Is there code that depends on implicit per-thread res_state objects? If so, this will break it. > There are probably several variations on each theme, of course. I would > appreciate your thoughts on these approaches and others I missed, as > well as variations and details. > FYI, I'm leaning toward the "stat" approach. This seems safe, and being able to rely on automatic /etc/resolv.conf reloading can simplify application code considerably. The NextBSD people have a more efficient alternative notify(3). Using that, resolvconf(8) can cause a counter in shared memory to be incremented, which can be detected efficiently by the resolver in each process. The stat() approach need not wait for this, though. -- Jilles Tjoelker From owner-freebsd-arch@freebsd.org Thu Oct 8 16:18:56 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4713B9D2B04 for ; Thu, 8 Oct 2015 16:18:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BD108D9 for ; Thu, 8 Oct 2015 16:18:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgt47 with SMTP id 47so46217520qgt.2 for ; Thu, 08 Oct 2015 09:18:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9jt3h8ygyKLpASM8q3xbYoqMOesQg2a2gKNXuhupiss=; b=FHSLB/g8LpvkoiM2bSuqZbvIhmdTFsxF4JPpHOKEPZCLiBEwzOhk9aApyRfixqIv9O oVh3pHV4bcK1EP1Vl4O3mLr5mhtwxkoivl7yQMlCWJMdpDL+R1sGNliiEJSx3QCM2+S0 Wb4yEm/noYxsv8jSppBLsjBzMaFCzIaf1gjvXyNPr/i5nA0rKD7ndxvkdfRNNlU8biJx UjcY0/RB1ZMDAOIhc5EZL5e5TG/chGNZUCFA3nQAE06d9Vqpw3K8ihT2UoWwwcI6er4y iO9vnfmsHaR1+Zm97zn9q3fM0n3I610Pv55LKO0s+e29p1sOJXhNLKBelpASUuO9xxMX 6y+A== X-Gm-Message-State: ALoCoQm4j27cS6GUX2pFA1CQDpoN2KdUVmEFTGCWCUm5cPIYiGdv+CbnvI7h1+sGIX+mf0feoZjC MIME-Version: 1.0 X-Received: by 10.140.232.210 with SMTP id d201mr9858780qhc.94.1444320782834; Thu, 08 Oct 2015 09:13:02 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.80.167 with HTTP; Thu, 8 Oct 2015 09:13:02 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <5615886F.3060601@FreeBSD.org> References: <5615886F.3060601@FreeBSD.org> Date: Thu, 8 Oct 2015 10:13:02 -0600 X-Google-Sender-Auth: SxBNzAZeLrTrYBCfk1fNUHGv8Rs Message-ID: Subject: Re: RFC: Automatically Reloading /etc/resolv.conf From: Warner Losh To: Eric van Gyzen Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 16:18:56 -0000 On Wed, Oct 7, 2015 at 3:02 PM, Eric van Gyzen wrote: > I would like to change the libc resolver to automatically reload > /etc/resolv.conf when the latter changes. I would like to hear opinions > about the implementation. Broadly, I see two approaches. > > == "stat" == > > When loading the file, record the mod time. Before each query, stat() > the file to see if it has changed. > > Advantage: It uses no extra persistently allocated objects. > > Disadvantage: It incurs a stat() on every query. I don't see this as a > major disadvantage, since the resolver already does a lot of work on > every query. (For example, it creates and destroys a kqueue and a socket.) > > OpenBSD uses this approach. It also uses clock_gettime(CLOCK_MONOTONIC) > to rate-limit the stat() calls to one per several seconds. > Make sure you rate limit it. Calling stat at a high rate from multiple CPUs exposes poor locking scaleability and eats a lot of CPU. We had some setting wrong on NGINX at work that lead to large NGINX latency spikes because this contention was blocking the worker threads. Correcting the settings to cache the results of stat made this problem disappear. > == "kqueue" == > > When loading the file, open a kqueue and register for the appropriate > events. Before each query, check for kevents. > > Advantage: The per-query overhead is fairly small. > > Disadvantage: This would persistently allocate an open file and a > kqueue for every thread that ever uses the resolver, for the life of the > thread. This seems fairly expensive. > Why does this follow? Can't you have a global one for the process? > NetBSD uses this approach. It mitigates most of the space-cost by using > a shared pool of res_state objects, instead of one per thread [that uses > the resolver]. On each query, a thread allocates/borrows a res_state > from the pool, uses it, and returns it. So, the number of objects is > only the high water mark of the number of threads _concurrently_ issuing > resolver queries.n > What's the locking scaleability here when resolv.conf changes? There are probably several variations on each theme, of course. I would > appreciate your thoughts on these approaches and others I missed, as > well as variations and details. > > FYI, I'm leaning toward the "stat" approach. > It sounds simpler to implement, but likely a higher overhead than the kqueue approach. resolv.conf changes on an time scale measured in minutes or hours for the mobile user, and on the scale of years for servers. Polling on the scale of seconds (at least two orders of magnitude faster than the rate of change) seems like a lot of extra work over the life of resolv.conf. Warner From owner-freebsd-arch@freebsd.org Thu Oct 8 16:30:58 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 531739D0180 for ; Thu, 8 Oct 2015 16:30:58 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EF69FFB7; Thu, 8 Oct 2015 16:30:57 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from vsuiko.mahoroba.org (vsuiko.mahoroba.org [IPv6:2001:2f0:104:8010:a00:27ff:feb0:c2e]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.15.2/8.15.2) with ESMTPSA/inet6 id t98GUjjS047713 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 9 Oct 2015 01:30:49 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 09 Oct 2015 01:30:44 +0900 Message-ID: From: Hajimu UMEMOTO To: Eric van Gyzen Cc: freebsd-arch@freebsd.org Subject: Re: RFC: Automatically Reloading /etc/resolv.conf In-Reply-To: <5615886F.3060601@FreeBSD.org> References: <5615886F.3060601@FreeBSD.org> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 10.2-STABLE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Fri, 09 Oct 2015 01:30:49 +0900 (JST) X-Virus-Scanned: clamav-milter 0.98.7 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on asuka.mahoroba.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 16:30:58 -0000 Hi, >>>>> On Wed, 7 Oct 2015 16:02:39 -0500 >>>>> Eric van Gyzen said: vangyzen> I would like to change the libc resolver to automatically reload vangyzen> /etc/resolv.conf when the latter changes. I would like to hear opinions vangyzen> about the implementation. When I proposed it in the past, it ended up with dns/nss_resinit port. Please take a look at it for reference. Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-arch@freebsd.org Thu Oct 8 19:50:43 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFC529B671F for ; Thu, 8 Oct 2015 19:50:43 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id D803B1308 for ; Thu, 8 Oct 2015 19:50:43 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from marvin.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id E3C2C564B3; Thu, 8 Oct 2015 14:50:42 -0500 (CDT) Subject: Re: RFC: Automatically Reloading /etc/resolv.conf To: freebsd-arch@freebsd.org, Jilles Tjoelker References: <5615886F.3060601@FreeBSD.org> <20151007215558.GA41787@stack.nl> From: Eric van Gyzen X-Enigmail-Draft-Status: N1110 Message-ID: <5616C90E.6090509@FreeBSD.org> Date: Thu, 8 Oct 2015 14:50:38 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151007215558.GA41787@stack.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 19:50:44 -0000 > Nitpick: the resolver has used poll instead of kqueue for a while, but > that does not fundamentally change your argument. I was looking at a 10.2-RELEASE system. Indeed, I see it using poll on head. Thanks. > Some glibc people think the extra stat may be too slow, though: > https://sourceware.org/bugzilla/show_bug.cgi?id=984 I added simple code to call stat() on every query and ran a benchmark. It reduces queries-per-second by 15.87%, so I definitely won't take that approach. >> When loading the file, open a kqueue and register for the appropriate >> events. Before each query, check for kevents. > > This sounds a bit scary in conjunction with code that bluntly closes > file descriptors it does not know about. That's true, but such code would break a variety of other facilities, such as syslog. I'll keep this in mind. > Also, kqueues do not inherit across fork, so the resolver needs some > sort of atfork handler. I hadn't thought of that. Thanks. >> NetBSD uses this approach. It mitigates most of the space-cost by using >> a shared pool of res_state objects, instead of one per thread [that uses >> the resolver]. On each query, a thread allocates/borrows a res_state >> from the pool, uses it, and returns it. So, the number of objects is >> only the high water mark of the number of threads _concurrently_ issuing >> resolver queries. > > Is there code that depends on implicit per-thread res_state objects? If > so, this will break it. I'm just describing NetBSD's current approach. I don't plan to adopt this in FreeBSD. To answer your question, though, I don't know if such code exists. > The NextBSD people have a more efficient alternative notify(3). Using > that, resolvconf(8) can cause a counter in shared memory to be > incremented, which can be detected efficiently by the resolver in each > process. The stat() approach need not wait for this, though. I didn't know about this. It sounds rather useful. Thanks! Eric From owner-freebsd-arch@freebsd.org Thu Oct 8 21:27:31 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1A199D1B1B for ; Thu, 8 Oct 2015 21:27:31 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 8A11C8E6 for ; Thu, 8 Oct 2015 21:27:31 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from marvin.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id E3E53564B3; Thu, 8 Oct 2015 16:27:29 -0500 (CDT) Subject: Re: RFC: Automatically Reloading /etc/resolv.conf To: freebsd-arch@freebsd.org, Warner Losh References: <5615886F.3060601@FreeBSD.org> From: Eric van Gyzen X-Enigmail-Draft-Status: N1110 Message-ID: <5616DFC0.8070404@FreeBSD.org> Date: Thu, 8 Oct 2015 16:27:28 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 21:27:31 -0000 On 10/08/2015 11:13, Warner Losh wrote: > > Make sure you rate limit it. Agreed. As I just wrote in my other reply, calling stat() on every query reduces queries-per-second by 15.87%. Rate-limiting to one stat() every ten seconds fixes it. That is, by manually running three or four benchmarks with and without my changes, I see no real difference. This was on amd64 where the cost of clock_gettime() is trivialized by vdso. >> Disadvantage: This would persistently allocate an open file and a >> kqueue for every thread that ever uses the resolver, for the life of the >> thread. This seems fairly expensive. >> > > Why does this follow? Can't you have a global one for the process? Well, gee, that seems like a good compromise, now that you mention it. ;-) Seriously, I simply didn't consider that. Given that the rate-limited stat() approach is so cheap, I wonder if it's worth the trouble to try the global kqueue approach. >> NetBSD uses this approach. It mitigates most of the space-cost by using >> a shared pool of res_state objects, instead of one per thread [that uses >> the resolver]. On each query, a thread allocates/borrows a res_state >> from the pool, uses it, and returns it. So, the number of objects is >> only the high water mark of the number of threads _concurrently_ issuing >> resolver queries.n >> > > What's the locking scaleability here when resolv.conf changes? The mutex is only held during one or two SLIST operations, so the locking is independent of resolv.conf changing. Maybe I misunderstood your question? >> FYI, I'm leaning toward the "stat" approach. >> > > It sounds simpler to implement, but likely a higher overhead than the > kqueue approach. resolv.conf changes on an time scale measured in minutes > or hours for the mobile user, and on the scale of years for servers. > Polling on the scale of seconds (at least two orders of magnitude faster > than the rate of change) seems like a lot of extra work over the life of > resolv.conf. On the other hand, when changes _are_ needed, you don't want to restart critical services in order to make them effective. (This is my motivation, in fact.) It would be trivial to add a "no-reload" option so performance-sensitive users can turn it off. In fact, I half expected this request from someone focused on embedded work, such as yourself. ;-) Eric From owner-freebsd-arch@freebsd.org Thu Oct 8 21:45:48 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28CDA9D29C1 for ; Thu, 8 Oct 2015 21:45:48 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 123826D8; Thu, 8 Oct 2015 21:45:47 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from marvin.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id CBA21564B3; Thu, 8 Oct 2015 16:45:46 -0500 (CDT) Subject: Re: RFC: Automatically Reloading /etc/resolv.conf To: Hajimu UMEMOTO References: <5615886F.3060601@FreeBSD.org> Cc: freebsd-arch@freebsd.org From: Eric van Gyzen X-Enigmail-Draft-Status: N1110 Message-ID: <5616E40A.2060400@FreeBSD.org> Date: Thu, 8 Oct 2015 16:45:46 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 21:45:48 -0000 On 10/08/2015 11:30, Hajimu UMEMOTO wrote: > vangyzen> I would like to change the libc resolver to automatically reload > vangyzen> /etc/resolv.conf when the latter changes. I would like to hear opinions > vangyzen> about the implementation. > > When I proposed it in the past, it ended up with dns/nss_resinit port. > Please take a look at it for reference. Nice. That's exactly what I want to do in libc. Doing it in nss is a clever way to avoid changing libc. Thanks for the pointer. Eric