From owner-freebsd-arch@FreeBSD.ORG Sun Aug 21 04:04:58 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4586716A420; Sun, 21 Aug 2005 04:04:58 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail25.syd.optusnet.com.au (mail25.syd.optusnet.com.au [211.29.133.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96F3443D45; Sun, 21 Aug 2005 04:04:57 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail25.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j7L44tI5021732 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 21 Aug 2005 14:04:55 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j7L44tSR035637; Sun, 21 Aug 2005 14:04:55 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j7L44sXD035636; Sun, 21 Aug 2005 14:04:54 +1000 (EST) (envelope-from pjeremy) Date: Sun, 21 Aug 2005 14:04:54 +1000 From: Peter Jeremy To: Robert Watson Message-ID: <20050821040454.GP13959@cirb503493.alcatel.com.au> References: <20050821003536.P14178@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050821003536.P14178@fledge.watson.org> User-Agent: Mutt/1.4.2i Cc: arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2005 04:04:58 -0000 Overall, I think that having applications see changes to /etc/resolv.conf is a good idea. On Sun, 2005-Aug-21 00:37:56 +0100, Robert Watson wrote: >(1) Has anyone characterized the significant of the cost of doing a stat() > for every DNS lookup for a significant workload? Does it matter? I wrote a short program to run stat("/etc/resolv.conf") in a loop. On a P-233 running 4.9, I got about 45000 iterations/sec. On a P-120 running 5.4, I got about 10500 iterations/sec. I don't think this matters - especially compared to the overheads involved in sending and receiving the DNS UDP packets. If you are stating the same name frequently, it will be in the name cache so the name lookups are fairly cheap. >(2) By reading the configuration file more frequently and more quickly > after a change, we increase the chances of a race condition in which > the resolve reads a partially written resolv.conf file during an > update. Does this happen in practice? This could be more of an issue, though I have no idea whether it really is. The easy work-around is to avoid updates. Instead create /etc/resolv.conf.tmp and rename it. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Sun Aug 21 05:05:28 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78EB516A41F; Sun, 21 Aug 2005 05:05:28 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id E51CC43D45; Sun, 21 Aug 2005 05:05:27 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:XEy4x/CvWqtqnRZmodDXx20AiXa+UzzMczEiFCxB8jME8yvwy3B3/pYiQZrlUE4i@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7L55FoB014958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Aug 2005 14:05:19 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 21 Aug 2005 14:05:15 +0900 Message-ID: From: Hajimu UMEMOTO To: Peter Jeremy In-Reply-To: <20050821040454.GP13959@cirb503493.alcatel.com.au> References: <20050821003536.P14178@fledge.watson.org> <20050821040454.GP13959@cirb503493.alcatel.com.au> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sun, 21 Aug 2005 14:05:20 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: arch@freebsd.org, Robert Watson Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2005 05:05:28 -0000 Hi, >>>>> On Sun, 21 Aug 2005 14:04:54 +1000 >>>>> Peter Jeremy said: PeterJeremy> Overall, I think that having applications see changes to /etc/resolv.conf PeterJeremy> is a good idea. Thanks. PeterJeremy> On Sun, 2005-Aug-21 00:37:56 +0100, Robert Watson wrote: >(1) Has anyone characterized the significant of the cost of doing a stat() > for every DNS lookup for a significant workload? Does it matter? PeterJeremy> I wrote a short program to run stat("/etc/resolv.conf") in a loop. PeterJeremy> On a P-233 running 4.9, I got about 45000 iterations/sec. PeterJeremy> On a P-120 running 5.4, I got about 10500 iterations/sec. PeterJeremy> I don't think this matters - especially compared to the overheads PeterJeremy> involved in sending and receiving the DNS UDP packets. If you are PeterJeremy> stating the same name frequently, it will be in the name cache so PeterJeremy> the name lookups are fairly cheap. Yes, I think a cost for stat() is considerably low than actuall DNS lookup. >(2) By reading the configuration file more frequently and more quickly > after a change, we increase the chances of a race condition in which > the resolve reads a partially written resolv.conf file during an > update. Does this happen in practice? I had care to don't update during the critical path. For example, I didn't change to use _res_init() in res_send(). I have been using this patch for myself about 3 months without any problem. PeterJeremy> This could be more of an issue, though I have no idea whether it PeterJeremy> really is. The easy work-around is to avoid updates. Instead create PeterJeremy> /etc/resolv.conf.tmp and rename it. Yup, I forgot to mention. Our dhclient updates resolv.conf frequently even when it is not changed. I think it is redundant, and I applied following patch: Index: sbin/dhclient/dhclient-script diff -u sbin/dhclient/dhclient-script.orig sbin/dhclient/dhclient-script --- sbin/dhclient/dhclient-script.orig Fri Jun 10 12:41:18 2005 +++ sbin/dhclient/dhclient-script Wed Jun 29 06:13:14 2005 @@ -152,6 +152,11 @@ cat /etc/resolv.conf.tail >>/etc/resolv.conf.std fi + if diff /etc/resolv.conf.std /etc/resolv.conf >/dev/null 2>&1; then + rm -f /etc/resolv.conf.std + return 0 + fi + # In case (e.g. during OpenBSD installs) /etc/resolv.conf # is a symbolic link, take care to preserve the link and write # the new data in the correct location. I wish to commit this, too. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Sun Aug 21 09:55:41 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BB6B16A41F; Sun, 21 Aug 2005 09:55:41 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED36D43D46; Sun, 21 Aug 2005 09:55:40 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5FCB8.dip.t-dialin.net [84.165.252.184]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id j7L9mk6q027270; Sun, 21 Aug 2005 11:48:58 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j7L9ssfG008708; Sun, 21 Aug 2005 11:54:54 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 21 Aug 2005 11:54:54 +0200 From: Alexander Leidinger To: Robert Watson Message-ID: <20050821115454.55441a64@Magellan.Leidinger.net> In-Reply-To: <20050821003536.P14178@fledge.watson.org> References: <20050821003536.P14178@fledge.watson.org> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2005 09:55:41 -0000 On Sun, 21 Aug 2005 00:37:56 +0100 (BST) Robert Watson wrote: > (2) By reading the configuration file more frequently and more quickly > after a change, we increase the chances of a race condition in which > the resolve reads a partially written resolv.conf file during an > update. Does this happen in practice? I've always been very leery of > re-reading configuration files automatically based on a time-stamp, as > updates to files are not atomic at all. Can kqueue be used instead of polling? Bye, Alexander. -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-arch@FreeBSD.ORG Sun Aug 21 10:27:21 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5020316A41F; Sun, 21 Aug 2005 10:27:21 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4366343D5E; Sun, 21 Aug 2005 10:27:17 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:mcApKJC6DYGNCGYHGRRVZVHahdRrbovVL+c+PvHnYW4GsHJt6SbaFOrcFwlsXk3F@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7LAR8mZ020053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Aug 2005 19:27:08 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 21 Aug 2005 19:27:07 +0900 Message-ID: From: Hajimu UMEMOTO To: Alexander Leidinger In-Reply-To: <20050821115454.55441a64@Magellan.Leidinger.net> References: <20050821003536.P14178@fledge.watson.org> <20050821115454.55441a64@Magellan.Leidinger.net> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sun, 21 Aug 2005 19:27:08 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: arch@freebsd.org, Robert Watson Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2005 10:27:21 -0000 Hi, >>>>> On Sun, 21 Aug 2005 11:54:54 +0200 >>>>> Alexander Leidinger said: Alexander> Can kqueue be used instead of polling? It may be able to use kqueue. However, I'm not sure how kevent() is cheap than stat(). It requires holding a file descriptor for monitoring change of resolv.conf. The logic will be slightly complicate, and it may cause memory leak. So, unless there is significant advantage to use kqueue, stat() is better here, IMHO. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Sun Aug 21 10:54:57 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFB5116A41F; Sun, 21 Aug 2005 10:54:57 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26C3543D46; Sun, 21 Aug 2005 10:54:56 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5FCB8.dip.t-dialin.net [84.165.252.184]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id j7LAm31p027505; Sun, 21 Aug 2005 12:48:14 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j7LAsC8D017734; Sun, 21 Aug 2005 12:54:12 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 21 Aug 2005 12:54:12 +0200 From: Alexander Leidinger To: Hajimu UMEMOTO Message-ID: <20050821125412.0de6b890@Magellan.Leidinger.net> In-Reply-To: References: <20050821003536.P14178@fledge.watson.org> <20050821115454.55441a64@Magellan.Leidinger.net> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Cc: arch@freebsd.org, Robert Watson Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2005 10:54:57 -0000 On Sun, 21 Aug 2005 19:27:07 +0900 Hajimu UMEMOTO wrote: > Hi, >=20 > >>>>> On Sun, 21 Aug 2005 11:54:54 +0200 > >>>>> Alexander Leidinger said: >=20 > Alexander> Can kqueue be used instead of polling? >=20 > It may be able to use kqueue. However, I'm not sure how kevent() is > cheap than stat(). It requires holding a file descriptor for =46rom a high level perspective (I don't know the code), kevent() only has to lookup an event in a queue (if the file hasn't changed, which is the typical case), while stat() has to go through the VFS subsystem until it reaches the cache (or the disk). Bye, Alexander. --=20 http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint =3D C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-arch@FreeBSD.ORG Sun Aug 21 12:19:47 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B518216A41F; Sun, 21 Aug 2005 12:19:47 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C15943D53; Sun, 21 Aug 2005 12:19:47 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1E6oni-000FDX-Sv; Sun, 21 Aug 2005 12:19:46 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1E6oni-000Dpz-GX; Sun, 21 Aug 2005 02:19:46 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17160.29026.1724.73259@roam.psg.com> Date: Sun, 21 Aug 2005 12:19:46 +0000 To: Robert Watson References: <20050821003536.P14178@fledge.watson.org> Cc: arch@FreeBSD.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2005 12:19:47 -0000 > (1) Has anyone characterized the significant of the cost of doing a stat() > for every DNS lookup for a significant workload? Does it matter? > Most performance-critical network paths don't do name lookups in order > to prevent indefinite stalls in lookup, but doing, say, 1,000 > additional stats a second is not a small issue. are you gonna be doing all that many of them, given that the dns queries over the net will not be blindingly fast to say the least? > (2) By reading the configuration file more frequently and more quickly > after a change, we increase the chances of a race condition in which > the resolve reads a partially written resolv.conf file during an > update. Does this happen in practice? I've always been very leery of > re-reading configuration files automatically based on a time-stamp, as > updates to files are not atomic at all. hmmmmm dunno about others' use patterns, but in my world, resolv.conf only changes when my mobile platform moves layer three binding (i.e. not an an 802.11 access point move). so the frequency is low, and it is usually not issuing dns queries as i move. but when i get to the new binding, i am annoyed if i have to whack the resolver. randy From owner-freebsd-arch@FreeBSD.ORG Sun Aug 21 17:17:10 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CCA116A41F; Sun, 21 Aug 2005 17:17:10 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id E521043D45; Sun, 21 Aug 2005 17:17:09 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 93F1DBC66; Sun, 21 Aug 2005 17:17:06 +0000 (UTC) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 21 Aug 2005 11:54:54 +0200." <20050821115454.55441a64@Magellan.Leidinger.net> Date: Sun, 21 Aug 2005 19:17:06 +0200 Message-ID: <58449.1124644626@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: arch@freebsd.org, Robert Watson Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2005 17:17:10 -0000 In message <20050821115454.55441a64@Magellan.Leidinger.net>, Alexander Leidinger writes: >On Sun, 21 Aug 2005 00:37:56 +0100 (BST) >Robert Watson wrote: > >> (2) By reading the configuration file more frequently and more quickly >> after a change, we increase the chances of a race condition in which >> the resolve reads a partially written resolv.conf file during an >> update. Does this happen in practice? I've always been very leery of >> re-reading configuration files automatically based on a time-stamp, as >> updates to files are not atomic at all. > >Can kqueue be used instead of polling? Programs writing resolv.conf should just this the right way: 1. Write new contents to temorary file. 2. Rename temporary file to resolv.conf. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 10:00:59 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1033) id A07A816A420; Mon, 22 Aug 2005 10:00:59 +0000 (GMT) Date: Mon, 22 Aug 2005 10:00:59 +0000 From: Alexey Dokuchaev To: arch@freebsd.org Message-ID: <20050822100059.GA24626@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: fdesc allocation optimization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 10:00:59 -0000 hi there, i've been browsing some of dfbsd resources recently, and found this one being pretty interesting: http://leaf.dragonflybsd.org/mailarchive/commits/2005-06/msg00526.html however, it seemingly did not get attention in our lists. so i am wondering if there are work/plans on porting hsu@'s work? i remember that at some point we adopted some openbsd-derived algorithm, but since matt states that this is "far better algorithm then anything we or freebsd thought up before", i figured it worth a look. ./danfe From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 10:51:05 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31E1A16A41F for ; Mon, 22 Aug 2005 10:51:05 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 790ED43D53 for ; Mon, 22 Aug 2005 10:51:04 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 15696 invoked from network); 22 Aug 2005 10:30:32 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Aug 2005 10:30:32 -0000 Message-ID: <4309AE1E.8FCC9E1E@freebsd.org> Date: Mon, 22 Aug 2005 12:51:10 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexey Dokuchaev References: <20050822100059.GA24626@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: fdesc allocation optimization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 10:51:05 -0000 Alexey Dokuchaev wrote: > > hi there, > > i've been browsing some of dfbsd resources recently, and found this one > being pretty interesting: > > http://leaf.dragonflybsd.org/mailarchive/commits/2005-06/msg00526.html > > however, it seemingly did not get attention in our lists. so i am > wondering if there are work/plans on porting hsu@'s work? i remember > that at some point we adopted some openbsd-derived algorithm, but since > matt states that this is "far better algorithm then anything we or > freebsd thought up before", i figured it worth a look. Looks certainly good. Why don't you go ahead and port it over? -- Andre From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 10:59:05 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 175C816A41F; Mon, 22 Aug 2005 10:59:05 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 866AE43D49; Mon, 22 Aug 2005 10:59:04 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id D42EEBC66; Mon, 22 Aug 2005 10:59:02 +0000 (UTC) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 22 Aug 2005 12:51:10 +0200." <4309AE1E.8FCC9E1E@freebsd.org> Date: Mon, 22 Aug 2005 12:58:59 +0200 Message-ID: <63334.1124708339@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: arch@freebsd.org, Alexey Dokuchaev Subject: Re: fdesc allocation optimization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 10:59:05 -0000 In message <4309AE1E.8FCC9E1E@freebsd.org>, Andre Oppermann writes: >Alexey Dokuchaev wrote: >> >> hi there, >> >> i've been browsing some of dfbsd resources recently, and found this one >> being pretty interesting: >> >> http://leaf.dragonflybsd.org/mailarchive/commits/2005-06/msg00526.html >> >> however, it seemingly did not get attention in our lists. so i am >> wondering if there are work/plans on porting hsu@'s work? i remember >> that at some point we adopted some openbsd-derived algorithm, but since >> matt states that this is "far better algorithm then anything we or >> freebsd thought up before", i figured it worth a look. > >Looks certainly good. Why don't you go ahead and port it over? It might be worth trying the alloc_unr() code first, it allocates in O(1) time but takes the hit when freeing. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 11:07:47 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1033) id D840116A420; Mon, 22 Aug 2005 11:07:47 +0000 (GMT) Date: Mon, 22 Aug 2005 11:07:47 +0000 From: Alexey Dokuchaev To: Andre Oppermann Message-ID: <20050822110747.GA32862@FreeBSD.org> References: <20050822100059.GA24626@FreeBSD.org> <4309AE1E.8FCC9E1E@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4309AE1E.8FCC9E1E@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: arch@freebsd.org Subject: Re: fdesc allocation optimization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 11:07:48 -0000 On Mon, Aug 22, 2005 at 12:51:10PM +0200, Andre Oppermann wrote: > Alexey Dokuchaev wrote: > > > > hi there, > > > > i've been browsing some of dfbsd resources recently, and found this one > > being pretty interesting: > > > > http://leaf.dragonflybsd.org/mailarchive/commits/2005-06/msg00526.html > > > > however, it seemingly did not get attention in our lists. so i am > > wondering if there are work/plans on porting hsu@'s work? i remember > > that at some point we adopted some openbsd-derived algorithm, but since > > matt states that this is "far better algorithm then anything we or > > freebsd thought up before", i figured it worth a look. > > Looks certainly good. Why don't you go ahead and port it over? i was thinking about porting it myself, but just wanted to check maybe someone or even hsu@ already does the work. plus, i'm not really fdesc guru after all. ./danfe From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 13:04:46 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FC2016A41F; Mon, 22 Aug 2005 13:04:46 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18FAC43D46; Mon, 22 Aug 2005 13:04:46 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id BD12A6147; Mon, 22 Aug 2005 15:04:29 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id A41D260F8; Mon, 22 Aug 2005 15:04:29 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id F070233D44; Mon, 22 Aug 2005 15:04:40 +0200 (CEST) To: Hajimu UMEMOTO References: <20050821003536.P14178@fledge.watson.org> <20050821040454.GP13959@cirb503493.alcatel.com.au> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 22 Aug 2005 15:04:40 +0200 In-Reply-To: (Hajimu UMEMOTO's message of "Sun, 21 Aug 2005 14:05:15 +0900") Message-ID: <867jee5dhz.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -5.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on tim.des.no Cc: Peter Jeremy , Robert Watson , arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 13:04:46 -0000 Hajimu UMEMOTO writes: > + if diff /etc/resolv.conf.std /etc/resolv.conf >/dev/null 2>&1; then > + rm -f /etc/resolv.conf.std > + return 0 > + fi > + use 'cmp -s' instead of diff. It returns 0 when the files are identical, 1 when they differ and 2 when one of the files does not exist or is not readable, and never prints anything. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 13:32:33 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CACC816A41F; Mon, 22 Aug 2005 13:32:33 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AFFE43D48; Mon, 22 Aug 2005 13:32:33 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2D93F61C3; Mon, 22 Aug 2005 15:32:11 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 1974561C1; Mon, 22 Aug 2005 15:32:11 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 66F1533D44; Mon, 22 Aug 2005 15:32:22 +0200 (CEST) To: Alexey Dokuchaev References: <20050822100059.GA24626@FreeBSD.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 22 Aug 2005 15:32:22 +0200 In-Reply-To: <20050822100059.GA24626@FreeBSD.org> (Alexey Dokuchaev's message of "Mon, 22 Aug 2005 10:00:59 +0000") Message-ID: <863bp25c7t.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -5.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on tim.des.no Cc: arch@freebsd.org Subject: Re: fdesc allocation optimization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 13:32:33 -0000 Alexey Dokuchaev writes: > i've been browsing some of dfbsd resources recently, and found this one > being pretty interesting: > > http://leaf.dragonflybsd.org/mailarchive/commits/2005-06/msg00526.html > > however, it seemingly did not get attention in our lists. so i am > wondering if there are work/plans on porting hsu@'s work? i remember > that at some point we adopted some openbsd-derived algorithm, but since > matt states that this is "far better algorithm then anything we or > freebsd thought up before", i figured it worth a look. Bollocks. Our current algorithm (which I wrote) is so fast you don't even notice it's there. It's actually simpler than the OpenBSD code from which it was inspired, and in theory it should be slower, but I discovered that the overhead of the "better" algorithm was so high that it consistently lost to the simpler one for reasonable amounts of file descriptors (up to about 100,000 per process). The source code for the microbenchmark I used, and selected graphs comparing my code to the previous implementation, are available at . (the strange artifacts you see on the red graphs are the result of the file descriptor table overrunning the CPU cache) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 13:40:34 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69E1D16A41F for ; Mon, 22 Aug 2005 13:40:34 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92A7B43D48 for ; Mon, 22 Aug 2005 13:40:33 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 16951 invoked from network); 22 Aug 2005 13:20:00 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Aug 2005 13:20:00 -0000 Message-ID: <4309D5D7.C7C76B5B@freebsd.org> Date: Mon, 22 Aug 2005 15:40:39 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= References: <20050822100059.GA24626@FreeBSD.org> <863bp25c7t.fsf@xps.des.no> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: arch@freebsd.org, Alexey Dokuchaev Subject: Re: fdesc allocation optimization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 13:40:34 -0000 Dag-Erling Smørgrav wrote: > > Alexey Dokuchaev writes: > > i've been browsing some of dfbsd resources recently, and found this one > > being pretty interesting: > > > > http://leaf.dragonflybsd.org/mailarchive/commits/2005-06/msg00526.html > > > > however, it seemingly did not get attention in our lists. so i am > > wondering if there are work/plans on porting hsu@'s work? i remember > > that at some point we adopted some openbsd-derived algorithm, but since > > matt states that this is "far better algorithm then anything we or > > freebsd thought up before", i figured it worth a look. > > Bollocks. Our current algorithm (which I wrote) is so fast you don't > even notice it's there. It's actually simpler than the OpenBSD code > from which it was inspired, and in theory it should be slower, but I > discovered that the overhead of the "better" algorithm was so high > that it consistently lost to the simpler one for reasonable amounts of > file descriptors (up to about 100,000 per process). > > The source code for the microbenchmark I used, and selected graphs > comparing my code to the previous implementation, are available at > . Wow, impressive! > (the strange artifacts you see on the red graphs are the result of the > file descriptor table overrunning the CPU cache) When did you commit this? Is it only in post 5.0 releases? -- Andre From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 13:49:32 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FE4716A41F; Mon, 22 Aug 2005 13:49:32 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2810143D46; Mon, 22 Aug 2005 13:49:32 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 13A9661C3; Mon, 22 Aug 2005 15:49:16 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id A5D2260F1; Mon, 22 Aug 2005 15:49:15 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 0AC3833D44; Mon, 22 Aug 2005 15:49:27 +0200 (CEST) To: Andre Oppermann References: <20050822100059.GA24626@FreeBSD.org> <863bp25c7t.fsf@xps.des.no> <4309D5D7.C7C76B5B@freebsd.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 22 Aug 2005 15:49:27 +0200 In-Reply-To: <4309D5D7.C7C76B5B@freebsd.org> (Andre Oppermann's message of "Mon, 22 Aug 2005 15:40:39 +0200") Message-ID: <86d5o63wuw.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -5.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on tim.des.no Cc: arch@freebsd.org, Alexey Dokuchaev Subject: Re: fdesc allocation optimization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 13:49:32 -0000 Andre Oppermann writes: > When did you commit this? Is it only in post 5.0 releases? Early 2004, before RELENG_5 was branched. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 14:20:03 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34E7716A41F for ; Mon, 22 Aug 2005 14:20:03 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A05D943D6E for ; Mon, 22 Aug 2005 14:19:59 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 21858 invoked from network); 22 Aug 2005 13:59:25 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Aug 2005 13:59:25 -0000 Message-ID: <4309DF15.FD4D6C56@freebsd.org> Date: Mon, 22 Aug 2005 16:20:05 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= References: <20050822100059.GA24626@FreeBSD.org> <863bp25c7t.fsf@xps.des.no> <4309D5D7.C7C76B5B@freebsd.org> <86d5o63wuw.fsf@xps.des.no> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: arch@freebsd.org, Alexey Dokuchaev Subject: Re: fdesc allocation optimization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 14:20:03 -0000 Dag-Erling Smørgrav wrote: > > Andre Oppermann writes: > > When did you commit this? Is it only in post 5.0 releases? > > Early 2004, before RELENG_5 was branched. That explains why DFBSD didn't have it. So we are better off in anything >5.x despite the uninformed comments on the DFBSD lists. -- Andre From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 14:27:57 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDD4A16A421; Mon, 22 Aug 2005 14:27:57 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from raqdevil.offmyserver.com (ext-unused-110.ixsystems.net [206.40.55.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3488943D5E; Mon, 22 Aug 2005 14:27:50 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from raqdevil.offmyserver.com (dho@localhost [127.0.0.1]) by raqdevil.offmyserver.com (8.13.1/8.13.1) with ESMTP id j7MER13w035762; Mon, 22 Aug 2005 07:27:01 -0700 (PDT) (envelope-from dodell@offmyserver.com) Received: (from dho@localhost) by raqdevil.offmyserver.com (8.13.1/8.13.1/Submit) id j7MER1X0035761; Mon, 22 Aug 2005 07:27:01 -0700 (PDT) (envelope-from dodell@offmyserver.com) X-Authentication-Warning: raqdevil.offmyserver.com: dho set sender to dodell@offmyserver.com using -f Date: Mon, 22 Aug 2005 07:27:01 -0700 From: "Devon H. O'Dell" To: Andre Oppermann Message-ID: <20050822142701.GD27233@raqdevil.offmyserver.com> References: <20050822100059.GA24626@FreeBSD.org> <863bp25c7t.fsf@xps.des.no> <4309D5D7.C7C76B5B@freebsd.org> <86d5o63wuw.fsf@xps.des.no> <4309DF15.FD4D6C56@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4309DF15.FD4D6C56@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: Dag-Erling Sm?rgrav , Alexey Dokuchaev , arch@freebsd.org Subject: Re: fdesc allocation optimization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 14:27:58 -0000 On Mon, Aug 22, 2005 at 04:20:05PM +0200, Andre Oppermann wrote: > Dag-Erling Sm?rgrav wrote: > > > > Andre Oppermann writes: > > > When did you commit this? Is it only in post 5.0 releases? > > > > Early 2004, before RELENG_5 was branched. > > That explains why DFBSD didn't have it. So we are better off in > anything >5.x despite the uninformed comments on the DFBSD lists. > > -- > Andre I think that they actually did a good bit of research into all of the fdalloc implementations in the BSDs before choosing their path. Perhaps misunderstood is a more accurate word than uninformed. --Devon From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 14:40:14 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43B9E16A41F; Mon, 22 Aug 2005 14:40:14 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9746A43D53; Mon, 22 Aug 2005 14:40:12 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:LTEta71ZjCZrGbvsPV3P+ES3FTDOR6PDPFPqH+1aDRVfR/WlD4hTUNbEYMPCnp2M@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7MEdv13085988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Aug 2005 23:40:02 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 22 Aug 2005 23:39:57 +0900 Message-ID: From: Hajimu UMEMOTO To: des@des.no (Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?=) In-Reply-To: <867jee5dhz.fsf@xps.des.no> References: <20050821003536.P14178@fledge.watson.org> <20050821040454.GP13959@cirb503493.alcatel.com.au> <867jee5dhz.fsf@xps.des.no> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA3 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Mon, 22 Aug 2005 23:40:03 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: Peter Jeremy , Robert Watson , arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 14:40:14 -0000 Hi, >>>>> On Mon, 22 Aug 2005 15:04:40 +0200 >>>>> Dag-Erling Sm=F8rgrav said: des> use 'cmp -s' instead of diff. It returns 0 when the files are des> identical, 1 when they differ and 2 when one of the files does not des> exist or is not readable, and never prints anything. Ah, yes. it was fixed locally. Thanks. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 15:13:04 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9F1816A420; Mon, 22 Aug 2005 15:13:04 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D15143D49; Mon, 22 Aug 2005 15:13:04 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7MFCsQv024124; Mon, 22 Aug 2005 08:12:54 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7MFCsbE024123; Mon, 22 Aug 2005 08:12:54 -0700 Date: Mon, 22 Aug 2005 08:12:54 -0700 From: Brooks Davis To: Hajimu UMEMOTO Message-ID: <20050822151254.GA22948@odin.ac.hmc.edu> References: <20050821003536.P14178@fledge.watson.org> <20050821040454.GP13959@cirb503493.alcatel.com.au> <867jee5dhz.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: arch@freebsd.org, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Robert Watson , Peter Jeremy Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 15:13:05 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2005 at 11:39:57PM +0900, Hajimu UMEMOTO wrote: > Hi, >=20 > >>>>> On Mon, 22 Aug 2005 15:04:40 +0200 > >>>>> Dag-Erling Sm=F8rgrav said: >=20 > des> use 'cmp -s' instead of diff. It returns 0 when the files are > des> identical, 1 when they differ and 2 when one of the files does not > des> exist or is not readable, and never prints anything. >=20 > Ah, yes. it was fixed locally. Thanks. I'm fine with the cmp version of the change so long as you only perform the test if /usr/bin/cmp exists. dhclient-script may be called before /usr exists and must not misbehave under those circumstances. --- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDCet1XY6L6fI4GtQRAs/OAJ9MUokKgONlLn3yupPZIgC4QrhTwgCgj/fg vZB61Xy8CCZjhfIxCo05shQ= =iwnc -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 15:16:46 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE55416A41F; Mon, 22 Aug 2005 15:16:46 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7991543D48; Mon, 22 Aug 2005 15:16:46 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7MFGjYI024461; Mon, 22 Aug 2005 08:16:46 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7MFGjKm024460; Mon, 22 Aug 2005 08:16:45 -0700 Date: Mon, 22 Aug 2005 08:16:45 -0700 From: Brooks Davis To: Poul-Henning Kamp Message-ID: <20050822151645.GB22948@odin.ac.hmc.edu> References: <20050821115454.55441a64@Magellan.Leidinger.net> <58449.1124644626@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8GpibOaaTibBMecb" Content-Disposition: inline In-Reply-To: <58449.1124644626@phk.freebsd.dk> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Alexander Leidinger , Robert Watson , arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 15:16:46 -0000 --8GpibOaaTibBMecb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 21, 2005 at 07:17:06PM +0200, Poul-Henning Kamp wrote: > In message <20050821115454.55441a64@Magellan.Leidinger.net>, Alexander Le= idinger writes: > >On Sun, 21 Aug 2005 00:37:56 +0100 (BST) > >Robert Watson wrote: > > > >> (2) By reading the configuration file more frequently and more quickly > >> after a change, we increase the chances of a race condition in wh= ich > >> the resolve reads a partially written resolv.conf file during an > >> update. Does this happen in practice? I've always been very lee= ry of > >> re-reading configuration files automatically based on a time-stam= p, as > >> updates to files are not atomic at all. > > > >Can kqueue be used instead of polling? >=20 > Programs writing resolv.conf should just this the right way: >=20 > 1. Write new contents to temorary file. > 2. Rename temporary file to resolv.conf. The one issue with this is that we sortof support a read-only /etc with resolv.conf as a symlink to somewhere else. Short of following the symlink by hand in dhclient-script, you have to do the current cat trick. It should cause the file to be replaced in one write() though so I don't think the race exists (unless someone comes up with a dhclient config that generates a resolv.conf larger then 512-bytes). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --8GpibOaaTibBMecb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDCexcXY6L6fI4GtQRAnwpAKCppisI64Yt7wN2AlCC3V13GguoQQCgg2se +exN5BjjU6bSp+PppwuYHGE= =U4Lu -----END PGP SIGNATURE----- --8GpibOaaTibBMecb-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 15:34:40 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F31416A41F; Mon, 22 Aug 2005 15:34:40 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E56D43D45; Mon, 22 Aug 2005 15:34:39 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:liTcRVTSkVqD1tuAJEpm5pwxNM6i025vS6Ncr6c0gcrvn5eslfs95wQpQvC+X9ir@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7MFYTXH079047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2005 00:34:32 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 23 Aug 2005 00:34:28 +0900 Message-ID: From: Hajimu UMEMOTO To: Brooks Davis In-Reply-To: <20050822151254.GA22948@odin.ac.hmc.edu> References: <20050821003536.P14178@fledge.watson.org> <20050821040454.GP13959@cirb503493.alcatel.com.au> <867jee5dhz.fsf@xps.des.no> <20050822151254.GA22948@odin.ac.hmc.edu> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA3 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 23 Aug 2005 00:34:32 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: arch@freebsd.org, Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= , Robert Watson , Peter Jeremy Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 15:34:40 -0000 Hi, >>>>> On Mon, 22 Aug 2005 08:12:54 -0700 >>>>> Brooks Davis said: brooks> I'm fine with the cmp version of the change so long as you only perform brooks> the test if /usr/bin/cmp exists. dhclient-script may be called before brooks> /usr exists and must not misbehave under those circumstances. If /usr/bin/cmp does not exist, The whole test will fail, then it will work as heretofore. So, I think we don't need to test if /usr/bin/cmp exists. However, if /usr/bin/cmp does not exist, error message will out. So, we need to supress it as following: if cmp -s /etc/resolv.conf.std /etc/resolv.conf; then rm -f /etc/resolv.conf.std return 0 fi 2>/dev/null Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 16:02:09 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D9F016A41F; Mon, 22 Aug 2005 16:02:09 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id A997C43D45; Mon, 22 Aug 2005 16:02:08 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-1.free.fr (Postfix) with ESMTP id 84A831734D1; Mon, 22 Aug 2005 18:02:05 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id A52AF405A; Mon, 22 Aug 2005 18:02:31 +0200 (CEST) Date: Mon, 22 Aug 2005 18:02:31 +0200 From: Jeremie Le Hen To: Hajimu UMEMOTO Message-ID: <20050822160231.GK659@obiwan.tataz.chchile.org> References: <20050821003536.P14178@fledge.watson.org> <20050821040454.GP13959@cirb503493.alcatel.com.au> <867jee5dhz.fsf@xps.des.no> <20050822151254.GA22948@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: arch@freebsd.org, Peter Jeremy , Robert Watson , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 16:02:09 -0000 Hi Hajimu-san, > If /usr/bin/cmp does not exist, The whole test will fail, then it will > work as heretofore. So, I think we don't need to test if /usr/bin/cmp > exists. > However, if /usr/bin/cmp does not exist, error message will out. So, > we need to supress it as following: > > if cmp -s /etc/resolv.conf.std /etc/resolv.conf; then > rm -f /etc/resolv.conf.std > return 0 > fi 2>/dev/null It would be good to put a comment in front of this block to explain this, or it has good chances to generates some mails in the future. Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 16:37:58 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE0BB16A41F; Mon, 22 Aug 2005 16:37:58 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51CD243D48; Mon, 22 Aug 2005 16:37:58 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 77D48BC6B; Mon, 22 Aug 2005 16:37:53 +0000 (UTC) To: Brooks Davis From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 22 Aug 2005 08:16:45 PDT." <20050822151645.GB22948@odin.ac.hmc.edu> Date: Mon, 22 Aug 2005 18:37:48 +0200 Message-ID: <65320.1124728668@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: Alexander Leidinger , Robert Watson , arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 16:37:58 -0000 In message <20050822151645.GB22948@odin.ac.hmc.edu>, Brooks Davis writes: >The one issue with this is that we sortof support a read-only /etc with >resolv.conf as a symlink to somewhere else. The question then is if the time has come to permanently symlink /etc/resolv.conf to /var/db/resolv.conf ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 17:11:52 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4CC816A41F; Mon, 22 Aug 2005 17:11:52 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FEA443D48; Mon, 22 Aug 2005 17:11:52 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7MHBpLn003634; Mon, 22 Aug 2005 10:11:51 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7MHBptC003633; Mon, 22 Aug 2005 10:11:51 -0700 Date: Mon, 22 Aug 2005 10:11:51 -0700 From: Brooks Davis To: Poul-Henning Kamp Message-ID: <20050822171151.GC22948@odin.ac.hmc.edu> References: <20050822151645.GB22948@odin.ac.hmc.edu> <65320.1124728668@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0lnxQi9hkpPO77W3" Content-Disposition: inline In-Reply-To: <65320.1124728668@phk.freebsd.dk> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Alexander Leidinger , Robert Watson , arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 17:11:53 -0000 --0lnxQi9hkpPO77W3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2005 at 06:37:48PM +0200, Poul-Henning Kamp wrote: > In message <20050822151645.GB22948@odin.ac.hmc.edu>, Brooks Davis writes: >=20 > >The one issue with this is that we sortof support a read-only /etc with > >resolv.conf as a symlink to somewhere else. >=20 > The question then is if the time has come to permanently symlink > /etc/resolv.conf to /var/db/resolv.conf ? I'd say there's a good argument for that as the default. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --0lnxQi9hkpPO77W3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDCgdWXY6L6fI4GtQRAmiLAKDPiOHZynTy3LoGGK0P3yaUd/oO0gCg38CL LwlvYazIaOA6W1X/2BarN4c= =b76X -----END PGP SIGNATURE----- --0lnxQi9hkpPO77W3-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 17:46:46 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F80016A41F; Mon, 22 Aug 2005 17:46:46 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 234DD43D45; Mon, 22 Aug 2005 17:46:46 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9p2/8.12.9) with ESMTP id j7MHkfYk050609; Mon, 22 Aug 2005 10:46:41 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id j7MHkfgY050608; Mon, 22 Aug 2005 10:46:41 -0700 (PDT) (envelope-from dillon) Date: Mon, 22 Aug 2005 10:46:41 -0700 (PDT) From: Matthew Dillon Message-Id: <200508221746.j7MHkfgY050608@apollo.backplane.com> To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) References: <20050822100059.GA24626@FreeBSD.org> <863bp25c7t.fsf@xps.des.no> Cc: arch@freebsd.org, Alexey Dokuchaev Subject: Re: fdesc allocation optimization X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 17:46:46 -0000 :Alexey Dokuchaev writes: :> i've been browsing some of dfbsd resources recently, and found this one :> being pretty interesting: :> :> http://leaf.dragonflybsd.org/mailarchive/commits/2005-06/msg00526.html :> :> however, it seemingly did not get attention in our lists. so i am :> wondering if there are work/plans on porting hsu@'s work? i remember :> that at some point we adopted some openbsd-derived algorithm, but since :> matt states that this is "far better algorithm then anything we or :> freebsd thought up before", i figured it worth a look. : :Bollocks. Our current algorithm (which I wrote) is so fast you don't :even notice it's there. It's actually simpler than the OpenBSD code :from which it was inspired, and in theory it should be slower, but I :discovered that the overhead of the "better" algorithm was so high :that it consistently lost to the simpler one for reasonable amounts of :file descriptors (up to about 100,000 per process). : :The source code for the microbenchmark I used, and selected graphs :comparing my code to the previous implementation, are available at :. : :(the strange artifacts you see on the red graphs are the result of the :file descriptor table overrunning the CPU cache) : :DES :-- :Dag-Erling Smørgrav - des@des.no Well, I expect that once you get past a pure linear search any algorithm will fast enough that it probably doesn't matter in real life. But I would not pooh-pooh Jeff's implementation of the Solaris algorithm so quickly. It is the fastest, cleanest, most elegant implementation of a file descriptor handling algorithm that I've ever seen in my life. Anyone who actually reads the code will come away wondering why FreeBSD is still screwing around with linear bitmaps. -Matt Matthew Dillon From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 20:18:59 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E47716A41F for ; Mon, 22 Aug 2005 20:18:59 +0000 (GMT) (envelope-from mreimer@vpop.net) Received: from ring.vpop.net (ring.vpop.net [207.178.248.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41A2343D46 for ; Mon, 22 Aug 2005 20:18:59 +0000 (GMT) (envelope-from mreimer@vpop.net) Received: from bilbo.vpop.net (bilbo.vpop.net [70.56.77.194]) by ring.vpop.net (Postfix) with ESMTP id 09DABAFADFB for ; Mon, 22 Aug 2005 13:18:52 -0700 (PDT) From: Matthew Reimer Organization: VPOP Technologies, Inc. To: arch@freebsd.org Date: Mon, 22 Aug 2005 13:18:46 -0700 User-Agent: KMail/1.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508221318.46908.mreimer@vpop.net> Cc: Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 20:18:59 -0000 Robert Watson wrote: > > On Sat, 20 Aug 2005, Hajimu UMEMOTO wrote: > >> Our resolver reads resolv.conf once, and never re-read it. Recent >> OpenBSD changed to re-read resolv.conf when it is updated. I believe it >> is useful specially for mobile environment. So, I made a patch for our >> resolver. Please review it. > > Two concerns: > > (1) Has anyone characterized the significant of the cost of doing a stat() > for every DNS lookup for a significant workload? Does it matter? > Most performance-critical network paths don't do name lookups in > order to prevent indefinite stalls in lookup, but doing, say, 1,000 > additional stats a second is not a small issue. > > (2) By reading the configuration file more frequently and more quickly > after a change, we increase the chances of a race condition in which > the resolve reads a partially written resolv.conf file during an > update. Does this happen in practice? I've always been very leery > of re-reading configuration files automatically based on a > time-stamp, as updates to files are not atomic at all. How about just stat'ing resolv.conf if more than X seconds has passed since the last stat, rather than for every lookup? Matt From owner-freebsd-arch@FreeBSD.ORG Mon Aug 22 21:30:55 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9C7816A41F for ; Mon, 22 Aug 2005 21:30:55 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33A1443D5A for ; Mon, 22 Aug 2005 21:30:55 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9AD3552C3F; Mon, 22 Aug 2005 23:30:53 +0200 (CEST) Received: from localhost (dlk229.neoplus.adsl.tpnet.pl [83.24.40.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4365D52BC4 for ; Mon, 22 Aug 2005 23:30:47 +0200 (CEST) Date: Mon, 22 Aug 2005 23:30:28 +0200 From: Pawel Jakub Dawidek To: FreeBSD-arch Message-ID: <20050822213028.GB4812@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng devel (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Subject: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 21:30:56 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I'd like to commit a small library for handling "pidfiles". It is something that is used by quite every daemon, but most of them don't do it right. Most important thing about this library, is that created pidfile is flock(2)ed, so we can easly detect is daemon is already running. Another interesting thing is that I've also modified pkill(1)'s '-F' option to take advantage of libpidfile and only kill process from the given pidfile if we cannot flock it. This ensures, that we don't kill some random process when daemon is already dead. Libpidfile has four functions to offer, but it will be easiest to just show an example of use (this is from manual page): pid_t otherpid, childpid; if (pidfile_open("/var/run/daemon.pid", 0644, &otherpid) =3D=3D -1) { if (errno =3D=3D EEXIST) { errx(EXIT_FAILURE, "Daemon already running, pid: %d.", otherpid); } /* If we cannot create pidfile from other reasons, only warn. */ warn("Cannot open or create pidfile"); } if (daemon(0, 0) =3D=3D -1) { warn("Cannot daemonize"); pidfile_remove(1); exit(EXIT_FAILURE); } pidfile_write(); for (;;) { /* Do work. */ childpid =3D fork(); switch (childpid) { case -1: syslog(LOG_ERR, "Cannot fork(): %s.", strerror(errno)); break; case 0: pidfile_close(); /* Do child work. */ break; default: syslog(LOG_INFO, "Child %d started.", childpid); break; } } pidfile_remove(0); /* Not really needed. */ exit(EXIT_SUCCESS); As you can see, it easy to use. Note that return values from functions other than pidfile_open() can be ignored, as they were implemented to handle previous pidfile_open() failure. The work is finished. It was implemented in FreeBSD's perforce in pjd_pidfile branch. I also converted few daemons: - devd(8), - cron(8), - syslogd(8), - moused(8), - powerd(8). Reimplementation of pkill(1)'s '-F' option is also there. The source code is availabe here: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/user/pjd/p= idfile/lib/libpidfile&HIDEDEL=3DNO --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDCkP0ForvXbEpPzQRAv2zAKCohm/SOykgxcL6sbio5irUEG4HHwCfVBFV sBKLUPC4qYYJ3WLH6Xb0FKc= =iCAd -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 02:51:12 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9242E16A41F for ; Tue, 23 Aug 2005 02:51:12 +0000 (GMT) (envelope-from tjr@freebsd.org) Received: from mail.netspace.net.au (thunder.netspace.net.au [203.10.110.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C2BD43D62 for ; Tue, 23 Aug 2005 02:51:07 +0000 (GMT) (envelope-from tjr@freebsd.org) Received: from [192.168.0.2] (220-253-61-65.VIC.netspace.net.au [220.253.61.65]) by mail.netspace.net.au (Postfix) with ESMTP id 430A649476 for ; Tue, 23 Aug 2005 12:51:05 +1000 (EST) Message-ID: <430A8F1A.6090607@freebsd.org> Date: Tue, 23 Aug 2005 12:51:06 +1000 From: Tim Robbins User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD-arch References: <20050822213028.GB4812@garage.freebsd.pl> In-Reply-To: <20050822213028.GB4812@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 02:51:12 -0000 Pawel Jakub Dawidek wrote: >I'd like to commit a small library for handling "pidfiles". > This sounds like a good idea to me, but you might consider putting the functionality in libutil instead of creating a separate library. Tim From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 03:01:24 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1A8F16A41F; Tue, 23 Aug 2005 03:01:23 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A76943D45; Tue, 23 Aug 2005 03:01:22 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from gothmog.gr (patr530-a212.otenet.gr [212.205.215.212]) by kane.otenet.gr (8.13.4/8.13.4/Debian-1) with ESMTP id j7N31Knn026453; Tue, 23 Aug 2005 06:01:21 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.4/8.13.4) with ESMTP id j7N31JkW007126; Tue, 23 Aug 2005 06:01:19 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.4/8.13.4/Submit) id j7N31JVX007125; Tue, 23 Aug 2005 06:01:19 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Tue, 23 Aug 2005 06:01:18 +0300 From: Giorgos Keramidas To: Tim Robbins Message-ID: <20050823030118.GB7028@gothmog.gr> References: <20050822213028.GB4812@garage.freebsd.pl> <430A8F1A.6090607@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <430A8F1A.6090607@freebsd.org> Cc: FreeBSD-arch Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 03:01:24 -0000 On 2005-08-23 12:51, Tim Robbins wrote: > Pawel Jakub Dawidek wrote: > >I'd like to commit a small library for handling "pidfiles". > > This sounds like a good idea to me, but you might consider putting the > functionality in libutil instead of creating a separate library. Hmmm, not that you mention libutil, I was only yesterday thinking that it's a bit annoying that "man libutil" doesn't bring up a useful manpage. Are there any objections to making a manpage that doesn't include *all* the details for the libutil functions but just pointers to the functions it currently implements? This is slightly different from, say, editline(3). This is why I'm asking. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 03:46:58 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BBB716A41F; Tue, 23 Aug 2005 03:46:58 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8830443D45; Tue, 23 Aug 2005 03:46:56 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:6mHxpoDzlB93nF9dZNOklAlJGlUfTVZf64EoC9NoTiltursLMeV+XLEeJMqAWL0o@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7N3kq5v023699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2005 12:46:52 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 23 Aug 2005 12:46:52 +0900 Message-ID: From: Hajimu UMEMOTO To: Pawel Jakub Dawidek In-Reply-To: <20050822213028.GB4812@garage.freebsd.pl> References: <20050822213028.GB4812@garage.freebsd.pl> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA3 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 23 Aug 2005 12:46:52 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: FreeBSD-arch Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 03:46:58 -0000 Hi, >>>>> On Mon, 22 Aug 2005 23:30:28 +0200 >>>>> Pawel Jakub Dawidek said: pjd> I'd like to commit a small library for handling "pidfiles". NetBSD and OpenBSD has similar functions already in libutil. I think we alone have a different API is bad idea. So, it is good to bring them into FreeBSD from NetBSD or OpenBSD, IMHO. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 07:47:47 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D09A116A41F for ; Tue, 23 Aug 2005 07:47:47 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3852143D45 for ; Tue, 23 Aug 2005 07:47:47 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail12.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j7N7lidZ020763 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 23 Aug 2005 17:47:45 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j7N7liSR038861; Tue, 23 Aug 2005 17:47:44 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j7N7lhcY038860; Tue, 23 Aug 2005 17:47:43 +1000 (EST) (envelope-from pjeremy) Date: Tue, 23 Aug 2005 17:47:43 +1000 From: Peter Jeremy To: Matthew Reimer Message-ID: <20050823074743.GC37107@cirb503493.alcatel.com.au> References: <200508221318.46908.mreimer@vpop.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508221318.46908.mreimer@vpop.net> User-Agent: Mutt/1.4.2i Cc: arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 07:47:47 -0000 On Mon, 2005-Aug-22 13:18:46 -0700, Matthew Reimer wrote: >How about just stat'ing resolv.conf if more than X seconds has passed since >the last stat, rather than for every lookup? That reduces the number of stat() calls but doesn't resolve the possibility of reading a half-written resolv.conf. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 08:08:23 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6BB316A41F; Tue, 23 Aug 2005 08:08:23 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA61043D45; Tue, 23 Aug 2005 08:08:22 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3136652C95; Tue, 23 Aug 2005 10:08:21 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 84F4652C2F; Tue, 23 Aug 2005 10:08:13 +0200 (CEST) Date: Tue, 23 Aug 2005 10:07:54 +0200 From: Pawel Jakub Dawidek To: Hajimu UMEMOTO Message-ID: <20050823080754.GA47261@garage.freebsd.pl> References: <20050822213028.GB4812@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng devel (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: FreeBSD-arch Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 08:08:23 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2005 at 12:46:52PM +0900, Hajimu UMEMOTO wrote: +> Hi, +>=20 +> >>>>> On Mon, 22 Aug 2005 23:30:28 +0200 +> >>>>> Pawel Jakub Dawidek said: +>=20 +> pjd> I'd like to commit a small library for handling "pidfiles". +>=20 +> NetBSD and OpenBSD has similar functions already in libutil. I think +> we alone have a different API is bad idea. So, it is good to bring +> them into FreeBSD from NetBSD or OpenBSD, IMHO. I assume you're talking about NetBSD's pidlock(3). This is exactly an example of a bad way of doing it, as I understand the code. It doesn't use flock(2), instead, it reads PID from the file and checks if process with this PID is alive. *SOME* process, not necessarily already running instance of the daemon, but some process which has the same PID. This is most important in case of pkill(1), when we don't want to kill some random process. This of course is also racy - daamon could be started between checking is process is alive and renaming (lock|pid)file. It only provides one function which writes the PID of the current process into the file. With libpidfile(3), you can open the pidfile before fork()ing, so daemon can report if another copy is already running before going into the background. In general NetBSD's pidlock(3) isn't a complete solution (there is no function to remove just remove pidfile on exit, etc. In OpenBSD pidfile(3) exists, but it is even worser. It doesn't even check if daemon is already running... It also doesn't support any pidfile name, you may specify only 'basename' and it creates pidfile in a form "/var/run/.pid", so it won't work if most of our daemon where you can specify alternate pidfile location. Anyway. There is no one API they share and none of them is a sufficient solution. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDCtlaForvXbEpPzQRAv+9AJ47qctXXJ5wuri2kjOhntJk+o3eAwCg5N7u MImy9zs00ROvV7ALDHWjl6c= =YdgF -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 08:18:27 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B029716A41F; Tue, 23 Aug 2005 08:18:27 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32B5A43D58; Tue, 23 Aug 2005 08:18:26 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id CBE9A52C95; Tue, 23 Aug 2005 10:18:24 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8BD1D52C2F; Tue, 23 Aug 2005 10:18:17 +0200 (CEST) Date: Tue, 23 Aug 2005 10:17:58 +0200 From: Pawel Jakub Dawidek To: Tim Robbins Message-ID: <20050823081758.GB47261@garage.freebsd.pl> References: <20050822213028.GB4812@garage.freebsd.pl> <430A8F1A.6090607@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QKdGvSO+nmPlgiQ/" Content-Disposition: inline In-Reply-To: <430A8F1A.6090607@freebsd.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng devel (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: FreeBSD-arch Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 08:18:27 -0000 --QKdGvSO+nmPlgiQ/ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2005 at 12:51:06PM +1000, Tim Robbins wrote: +> Pawel Jakub Dawidek wrote: +>=20 +> >I'd like to commit a small library for handling "pidfiles". +> This sounds like a good idea to me, but you might consider putting the f= unctionality in libutil instead of creating a separate library. If you look at the perforce logs, you'll see it was in libutil at first. While I like libutil for some single functions (I added humanize_number(3) in there), but I don't like putting there everything. In my first concept (when it was part of libutil) I allocated memory to store needed informations, because I didn't wanted to use preallocated memory (someone linking libutil doesn't have to use pidfile functionality). Now, when it is a small library I can use preallocated memory and eliminate one point of potential failure. It also now has 4 functions, which makes it a good candidate of small, nice, lightweight library:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --QKdGvSO+nmPlgiQ/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDCtu2ForvXbEpPzQRAo6iAKDcKPIkRn6EzdvQ4+odiKUgyW/emACg7KRG cAkpIhRfq9DdADBqpFABqVI= =rAE+ -----END PGP SIGNATURE----- --QKdGvSO+nmPlgiQ/-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 08:25:09 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB23D16A41F; Tue, 23 Aug 2005 08:25:09 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from rohrpostix.tallence.de (rohrpostix.tallence.de [212.12.62.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BFC643D46; Tue, 23 Aug 2005 08:25:09 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [44.128.40.11] (janus.spock.tallence.de [44.128.40.11]) by rohrpostix.tallence.de (Postfix) with ESMTP id 5FC401AD91C; Tue, 23 Aug 2005 10:25:07 +0200 (CEST) In-Reply-To: <20050822213028.GB4812@garage.freebsd.pl> References: <20050822213028.GB4812@garage.freebsd.pl> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Tue, 23 Aug 2005 10:25:09 +0200 To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.733) Cc: FreeBSD-arch Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 08:25:09 -0000 Random thoughts: Am 22.08.2005 um 23:30 schrieb Pawel Jakub Dawidek: > if (pidfile_open("/var/run/daemon.pid", 0644, &otherpid) == -1) { > pidfile_write(); > pidfile_close(); I can't really think of a case that would need it, but wouldn't it make sense to have pidfile_open return a handle, and use that in the subsequent calls? Just in case anyone would ever need more than one... Does this API have any implications for privsep'ed daemons? Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 09:42:35 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C14A416A41F; Tue, 23 Aug 2005 09:42:35 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DDD043D49; Tue, 23 Aug 2005 09:42:34 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail15.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j7N9gRBI006630 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 23 Aug 2005 19:42:28 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j7N9gRSR038969; Tue, 23 Aug 2005 19:42:27 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j7N9gQCo038968; Tue, 23 Aug 2005 19:42:26 +1000 (EST) (envelope-from pjeremy) Date: Tue, 23 Aug 2005 19:42:26 +1000 From: Peter Jeremy To: Pawel Jakub Dawidek Message-ID: <20050823094226.GD37107@cirb503493.alcatel.com.au> References: <20050822213028.GB4812@garage.freebsd.pl> <430A8F1A.6090607@freebsd.org> <20050823081758.GB47261@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050823081758.GB47261@garage.freebsd.pl> User-Agent: Mutt/1.4.2i Cc: FreeBSD-arch Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 09:42:35 -0000 Firstly, I think that this is useful. Writing code to correctly ensure that no more than one copy of a process is running is very easy to get wrong - and I've seen lots of examples of how not to do it. On Tue, 2005-Aug-23 10:17:58 +0200, Pawel Jakub Dawidek wrote: >In my first concept (when it was part of libutil) I allocated memory >to store needed informations, because I didn't wanted to use preallocated >memory (someone linking libutil doesn't have to use pidfile >functionality). Since there's an initialisation function, why not just malloc whatever memory you need? You can either store the pointer in a local static or have pidfile_open() return it as an opaque pointer that the user has to pass into other pidfile_XXX functions. >It also now has 4 functions, which makes it a good candidate of small, >nice, lightweight library:) IMHO, 4 functions is too small. I would prefer to have a smaller number of larger libraries and think this belongs in an existing library - eg libutil. Whilst this may form a nice lightweight library, if everyone wrote small, lightweight libraries, linking an application would require a mile-long command line. Can I suggest two enhancements: 1) Allow NULL to be passed to pidfile_open() to indicate that the pidfile should be in /var/run/PROCESS_NAME.pid (and/or if the name doesn't include any '/' then default to /var/run) 2) Write a wrapper function that calls pidfile_open() and if it's successful, exec's the rest of the command line. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 15:26:23 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3E0516A41F for ; Tue, 23 Aug 2005 15:26:23 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3525A43D48 for ; Tue, 23 Aug 2005 15:26:23 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j7NFQKkS071113; Tue, 23 Aug 2005 10:26:20 -0500 (CDT) (envelope-from dan) Date: Tue, 23 Aug 2005 10:26:20 -0500 From: Dan Nelson To: Peter Jeremy Message-ID: <20050823152619.GC44859@dan.emsphone.com> References: <200508221318.46908.mreimer@vpop.net> <20050823074743.GC37107@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050823074743.GC37107@cirb503493.alcatel.com.au> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: arch@freebsd.org, Matthew Reimer Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 15:26:23 -0000 In the last episode (Aug 23), Peter Jeremy said: > On Mon, 2005-Aug-22 13:18:46 -0700, Matthew Reimer wrote: > >How about just stat'ing resolv.conf if more than X seconds has > >passed since the last stat, rather than for every lookup? > > That reduces the number of stat() calls but doesn't resolve the > possibility of reading a half-written resolv.conf. Easy enough to only reread the file if stat tells you it's more than 2 seconds old. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 16:56:37 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D18E516A41F for ; Tue, 23 Aug 2005 16:56:37 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms048pub.verizon.net (vms048pub.verizon.net [206.46.252.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CE4E43D48 for ; Tue, 23 Aug 2005 16:56:37 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms070.mailsrvcs.net ([192.168.1.3]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0ILO000Q7PQDEBA0@vms048.mailsrvcs.net> for arch@freebsd.org; Tue, 23 Aug 2005 11:56:37 -0500 (CDT) Date: Tue, 23 Aug 2005 11:56:37 -0500 (CDT) From: Sergey Babkin To: Dan Nelson , Peter Jeremy Message-id: <1347627.1124816197248.JavaMail.root@vms070.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: arch@freebsd.org, Matthew Reimer Subject: Re: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 16:56:37 -0000 >In the last episode (Aug 23), Peter Jeremy said: >> On Mon, 2005-Aug-22 13:18:46 -0700, Matthew Reimer wrote: >> >How about just stat'ing resolv.conf if more than X seconds has >> >passed since the last stat, rather than for every lookup? >> >> That reduces the number of stat() calls but doesn't resolve the >> possibility of reading a half-written resolv.conf. > >Easy enough to only reread the file if stat tells you it's more than 2 >seconds old. Won't reliably help: the file might change after you've done stat. The real solution would be to : * do stat, see that the file has changed * read the file into an intermediate buffer * wait 1 or 2 seconds * do stat again, if the time has not changed since the first stat then the contents of your buffer is valid and yu can use it -SB From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 20:27:01 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9112E16A41F; Tue, 23 Aug 2005 20:27:01 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5599C43D45; Tue, 23 Aug 2005 20:26:58 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j7NKQu9d056511; Tue, 23 Aug 2005 13:26:56 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j7NKQuMu056510; Tue, 23 Aug 2005 13:26:56 -0700 (PDT) (envelope-from jmg) Date: Tue, 23 Aug 2005 13:26:56 -0700 From: John-Mark Gurney To: Pawel Jakub Dawidek Message-ID: <20050823202656.GB30465@funkthat.com> Mail-Followup-To: Pawel Jakub Dawidek , Hajimu UMEMOTO , FreeBSD-arch References: <20050822213028.GB4812@garage.freebsd.pl> <20050823080754.GA47261@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050823080754.GA47261@garage.freebsd.pl> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p1 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Hajimu UMEMOTO , FreeBSD-arch Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 20:27:01 -0000 Pawel Jakub Dawidek wrote this message on Tue, Aug 23, 2005 at 10:07 +0200: > On Tue, Aug 23, 2005 at 12:46:52PM +0900, Hajimu UMEMOTO wrote: > +> Hi, > +> > +> >>>>> On Mon, 22 Aug 2005 23:30:28 +0200 > +> >>>>> Pawel Jakub Dawidek said: > +> > +> pjd> I'd like to commit a small library for handling "pidfiles". > +> > +> NetBSD and OpenBSD has similar functions already in libutil. I think > +> we alone have a different API is bad idea. So, it is good to bring > +> them into FreeBSD from NetBSD or OpenBSD, IMHO. > > I assume you're talking about NetBSD's pidlock(3). > > This is exactly an example of a bad way of doing it, as I understand the > code. /me just checked NetBSD and OpenBSD's code at: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libutil/pidfile.c?rev=1.7&content-type=text/x-cvsweb-markup http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libutil/pidfile.c?rev=1.7&content-type=text/x-cvsweb-markup Neither, of these are safe to prevent multiple daemons from starting up at the same time... Both NetBSD and OpenBSD doesn't even check if a daemon is running.. it just blindly splats the pid into the file.. > It doesn't use flock(2), instead, it reads PID from the file and checks > if process with this PID is alive. *SOME* process, not necessarily already > running instance of the daemon, but some process which has the same PID. > This is most important in case of pkill(1), when we don't want to kill > some random process. > > This of course is also racy - daamon could be started between checking > is process is alive and renaming (lock|pid)file. > > It only provides one function which writes the PID of the current process > into the file. With libpidfile(3), you can open the pidfile before > fork()ing, so daemon can report if another copy is already running before > going into the background. > > In general NetBSD's pidlock(3) isn't a complete solution (there is no > function to remove just remove pidfile on exit, etc. > > In OpenBSD pidfile(3) exists, but it is even worser. It doesn't even check > if daemon is already running... > It also doesn't support any pidfile name, you may specify only 'basename' > and it creates pidfile in a form "/var/run/.pid", so it won't > work if most of our daemon where you can specify alternate pidfile location. > > Anyway. There is no one API they share and none of them is a sufficient > solution. Just so others know, the method that pjd used was suggested by me after seeing various issues where a pid file was stale from a previous boot stopped a daemon from starting because another daemon "got" that pid... using a lock has the automatic benifit that if the process dies for any reason the next time the daemon starts up, since it can lock the file, it knows that there isn't a daemon running, and it doesn't even care about the file contents... Splitting the function into two parts also gives you the ability to print out an error message saying that another daemon is already running... if you wait to do the pidfile till you've daemonized, then you can't send any message to the user unless you have a complicated pipe system to send back status... I would like to see us adopt this... I don't care which library it is in... It'll make daemon start up more reliable by using these routines.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Tue Aug 23 23:19:18 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7795F16A41F for ; Tue, 23 Aug 2005 23:19:18 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id B69F043D45 for ; Tue, 23 Aug 2005 23:19:17 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5F84E52C3F; Wed, 24 Aug 2005 01:19:15 +0200 (CEST) Received: from localhost (dks251.neoplus.adsl.tpnet.pl [83.24.22.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id BC8E952BC4; Wed, 24 Aug 2005 01:19:08 +0200 (CEST) Date: Wed, 24 Aug 2005 01:18:48 +0200 From: Pawel Jakub Dawidek To: Peter Jeremy Message-ID: <20050823231848.GD65338@garage.freebsd.pl> References: <20050822213028.GB4812@garage.freebsd.pl> <430A8F1A.6090607@freebsd.org> <20050823081758.GB47261@garage.freebsd.pl> <20050823094226.GD37107@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NklN7DEeGtkPCoo3" Content-Disposition: inline In-Reply-To: <20050823094226.GD37107@cirb503493.alcatel.com.au> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng devel (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: FreeBSD-arch Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 23:19:18 -0000 --NklN7DEeGtkPCoo3 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2005 at 07:42:26PM +1000, Peter Jeremy wrote: +> On Tue, 2005-Aug-23 10:17:58 +0200, Pawel Jakub Dawidek wrote: +> >In my first concept (when it was part of libutil) I allocated memory +> >to store needed informations, because I didn't wanted to use preallocat= ed +> >memory (someone linking libutil doesn't have to use pidfile +> >functionality). +>=20 +> Since there's an initialisation function, why not just malloc whatever +> memory you need? You can either store the pointer in a local static +> or have pidfile_open() return it as an opaque pointer that the user +> has to pass into other pidfile_XXX functions. I added a handle, so now it goes like this: struct pidfh *pfh; pid_t otherpid, childpid; pfh =3D pidfile_open("/var/run/daemon.pid", 0644, &otherpid); if (pfh =3D=3D NULL) { if (errno =3D=3D EEXIST) errx(EXIT_FAILURE, "Daemon already running, pid: %d.", otherpid); /* If we cannot create pidfile from other reasons, only warn. */ warn("Cannot open or create pidfile"); } if (daemon(0, 0) =3D=3D -1) { warn("Cannot daemonize"); pidfile_remove(pfh); exit(EXIT_FAILURE); } pidfile_write(pfh); for (;;) { /* Do work. */ childpid =3D fork(); switch (childpid) { case -1: syslog(LOG_ERR, "Cannot fork(): %s.", strerror(errno)); break; case 0: pidfile_close(pfh); /* Do child work. */ break; default: syslog(LOG_INFO, "Child %d started.", childpid); break; } } pidfile_remove(pfh); exit(EXIT_SUCCESS); I can't use atexit(3) anymore to remove pidfile, but I like it this way better, anyway. +> >It also now has 4 functions, which makes it a good candidate of small, +> >nice, lightweight library:) +>=20 +> IMHO, 4 functions is too small. I would prefer to have a smaller +> number of larger libraries and think this belongs in an existing +> library - eg libutil. Whilst this may form a nice lightweight +> library, if everyone wrote small, lightweight libraries, linking +> an application would require a mile-long command line. I talked about this with few more guys and they agree it should be a part of libutil, so I moved it there. +> Can I suggest two enhancements: +> 1) Allow NULL to be passed to pidfile_open() to indicate that the +> pidfile should be in /var/run/PROCESS_NAME.pid (and/or if the +> name doesn't include any '/' then default to /var/run) I implemented NULL behaviour, but I'm not sure about the second thing. I'd like to avoid it. +> 2) Write a wrapper function that calls pidfile_open() and if it's +> successful, exec's the rest of the command line. There is simlar wrapper: lockf(1), so I'll not duplicate functionality, but I changed daemon(8) to use pidfile(3). Thanks for all suggestions. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --NklN7DEeGtkPCoo3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDC67YForvXbEpPzQRAi+nAJ0VNjhiOJJHFp43yZbKXiwQLT2OBACdHbzn sHKDzW9qI1cS3j76ssUyzAo= =kLCP -----END PGP SIGNATURE----- --NklN7DEeGtkPCoo3-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 24 13:45:45 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38A0D16A41F; Wed, 24 Aug 2005 13:45:45 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E03043D45; Wed, 24 Aug 2005 13:45:43 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j7ODjf78097506; Wed, 24 Aug 2005 17:45:42 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j7ODjfe6097505; Wed, 24 Aug 2005 17:45:41 +0400 (MSD) (envelope-from yar) Date: Wed, 24 Aug 2005 17:45:40 +0400 From: Yar Tikhiy To: Pawel Jakub Dawidek , Hajimu UMEMOTO , FreeBSD-arch Message-ID: <20050824134540.GA94265@comp.chem.msu.su> References: <20050822213028.GB4812@garage.freebsd.pl> <20050823080754.GA47261@garage.freebsd.pl> <20050823202656.GB30465@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050823202656.GB30465@funkthat.com> User-Agent: Mutt/1.5.9i Cc: Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2005 13:45:45 -0000 On Tue, Aug 23, 2005 at 01:26:56PM -0700, John-Mark Gurney wrote: > Pawel Jakub Dawidek wrote this message on Tue, Aug 23, 2005 at 10:07 +0200: > > On Tue, Aug 23, 2005 at 12:46:52PM +0900, Hajimu UMEMOTO wrote: > > +> Hi, > > +> > > +> >>>>> On Mon, 22 Aug 2005 23:30:28 +0200 > > +> >>>>> Pawel Jakub Dawidek said: > > +> > > +> pjd> I'd like to commit a small library for handling "pidfiles". > > +> > > +> NetBSD and OpenBSD has similar functions already in libutil. I think > > +> we alone have a different API is bad idea. So, it is good to bring > > +> them into FreeBSD from NetBSD or OpenBSD, IMHO. > > > > I assume you're talking about NetBSD's pidlock(3). > > > > This is exactly an example of a bad way of doing it, as I understand the > > code. > > /me just checked NetBSD and OpenBSD's code at: > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libutil/pidfile.c?rev=1.7&content-type=text/x-cvsweb-markup > http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libutil/pidfile.c?rev=1.7&content-type=text/x-cvsweb-markup > > Neither, of these are safe to prevent multiple daemons from starting > up at the same time... Both NetBSD and OpenBSD doesn't even check if > a daemon is running.. it just blindly splats the pid into the file.. Of course, giving advices is much easier than doing the real work, but I dare suggest cooperation with NetBSD and OpenBSD on this issue so that eventually we have a good and compatible implementation of the pidfile API in *BSD. I believe that the NetBSD and OpenBSD folks won't take offence if approached with a well-grounded explanation of why their current pidfile functions suck. -- Yar From owner-freebsd-arch@FreeBSD.ORG Wed Aug 24 17:15:07 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 539F616A41F; Wed, 24 Aug 2005 17:15:07 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54DDE43D46; Wed, 24 Aug 2005 17:15:06 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C4CB852CA4; Wed, 24 Aug 2005 19:15:04 +0200 (CEST) Received: from localhost (djy66.neoplus.adsl.tpnet.pl [83.24.2.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A04A452BC8; Wed, 24 Aug 2005 19:14:58 +0200 (CEST) Date: Wed, 24 Aug 2005 19:14:37 +0200 From: Pawel Jakub Dawidek To: Yar Tikhiy Message-ID: <20050824171437.GA755@garage.freebsd.pl> References: <20050822213028.GB4812@garage.freebsd.pl> <20050823080754.GA47261@garage.freebsd.pl> <20050823202656.GB30465@funkthat.com> <20050824134540.GA94265@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <20050824134540.GA94265@comp.chem.msu.su> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng devel (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Hajimu UMEMOTO , FreeBSD-arch Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2005 17:15:07 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2005 at 05:45:40PM +0400, Yar Tikhiy wrote: +> > /me just checked NetBSD and OpenBSD's code at: +> > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libutil/pidfile.c?rev=3D1.= 7&content-type=3Dtext/x-cvsweb-markup +> > http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libutil/pidfile.c?rev=3D= 1.7&content-type=3Dtext/x-cvsweb-markup +> >=20 +> > Neither, of these are safe to prevent multiple daemons from starting +> > up at the same time... Both NetBSD and OpenBSD doesn't even check if +> > a daemon is running.. it just blindly splats the pid into the file.. +>=20 +> Of course, giving advices is much easier than doing the real work, +> but I dare suggest cooperation with NetBSD and OpenBSD on this issue +> so that eventually we have a good and compatible implementation of +> the pidfile API in *BSD. I believe that the NetBSD and OpenBSD +> folks won't take offence if approached with a well-grounded explanation +> of why their current pidfile functions suck. They are of course free to adpot pidfile(3) and I'll gladly provide all needed explanations if they'll ask me. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDDKr9ForvXbEpPzQRAtyJAJ9QH9CixrM4vgH6g2qwoAVvvmQBcgCg9zjc +V5BcBYqgYbb86d7nMY4GjA= =saAv -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-freebsd-arch@FreeBSD.ORG Thu Aug 25 14:47:41 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C06316A41F; Thu, 25 Aug 2005 14:47:41 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id E744343D45; Thu, 25 Aug 2005 14:47:39 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j7PElaCE061623; Thu, 25 Aug 2005 18:47:36 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j7PElZgt061622; Thu, 25 Aug 2005 18:47:35 +0400 (MSD) (envelope-from yar) Date: Thu, 25 Aug 2005 18:47:35 +0400 From: Yar Tikhiy To: Pawel Jakub Dawidek Message-ID: <20050825144735.GA59955@comp.chem.msu.su> References: <20050822213028.GB4812@garage.freebsd.pl> <20050823080754.GA47261@garage.freebsd.pl> <20050823202656.GB30465@funkthat.com> <20050824134540.GA94265@comp.chem.msu.su> <20050824171437.GA755@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050824171437.GA755@garage.freebsd.pl> User-Agent: Mutt/1.5.9i Cc: FreeBSD-arch Subject: Re: New library: libpidfile. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2005 14:47:41 -0000 On Wed, Aug 24, 2005 at 07:14:37PM +0200, Pawel Jakub Dawidek wrote: > On Wed, Aug 24, 2005 at 05:45:40PM +0400, Yar Tikhiy wrote: > +> > > +> > Neither, of these are safe to prevent multiple daemons from starting > +> > up at the same time... Both NetBSD and OpenBSD doesn't even check if > +> > a daemon is running.. it just blindly splats the pid into the file.. > +> > +> Of course, giving advices is much easier than doing the real work, > +> but I dare suggest cooperation with NetBSD and OpenBSD on this issue > +> so that eventually we have a good and compatible implementation of > +> the pidfile API in *BSD. I believe that the NetBSD and OpenBSD > +> folks won't take offence if approached with a well-grounded explanation > +> of why their current pidfile functions suck. > > They are of course free to adpot pidfile(3) and I'll gladly provide > all needed explanations if they'll ask me. And what if they miss your effort and don't ask you in the first place? My point is that a bit of good will won't hurt when we see evidently rotten code in other projects and have a better solution to offer. This is particularly true for *BSD since we all grow from the same root. In addition, by taking the initiative you'll encourage *BSD folks to provide useful feedback on your work. To my mind, it is a wonderful opportunity that as little as a mere email can help to make *BSD a tad better and more compatible. -- Yar From owner-freebsd-arch@FreeBSD.ORG Fri Aug 26 06:44:34 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79F2116A41F; Fri, 26 Aug 2005 06:44:34 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A9F943D48; Fri, 26 Aug 2005 06:44:33 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.15.2] (d216-232-211-96.bchsia.telus.net [216.232.211.96]) (authenticated bits=0) by orthanc.ca (8.13.3/8.13.3) with ESMTP id j7Q6iSl6043452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2005 00:44:29 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Message-ID: <430EBA46.2060307@orthanc.ca> Date: Thu, 25 Aug 2005 23:44:22 -0700 From: Lyndon Nerenberg User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Robbins References: <21744.1123267707@phk.freebsd.dk> <20050805214650.H46767@fledge.watson.org> <42F5AA8D.3060201@freebsd.org> In-Reply-To: <42F5AA8D.3060201@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on orthanc.ca Cc: arch@freebsd.org Subject: splitting off RPC and friends X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2005 06:44:34 -0000 > The same could be done with NIS/YP, which would allow us to slim down > libc by moving xdr & rpc into a separate librpc, and yp into a separate > libyp. RPC and XDR are far from dead. Are you sure splitting these out is wise? We have to keep the code around, for NFS if nothing else. What's the benefit of moving the routines into a separate library? This just seems to make work for Makefile maintainers. --lyndon From owner-freebsd-arch@FreeBSD.ORG Fri Aug 26 11:04:09 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B77916A41F; Fri, 26 Aug 2005 11:04:09 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8A4043D4C; Fri, 26 Aug 2005 11:04:08 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 8B46A61D1; Fri, 26 Aug 2005 13:03:52 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 75CE261CA; Fri, 26 Aug 2005 13:03:52 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 7705533CA7; Fri, 26 Aug 2005 13:04:03 +0200 (CEST) To: Lyndon Nerenberg References: <21744.1123267707@phk.freebsd.dk> <20050805214650.H46767@fledge.watson.org> <42F5AA8D.3060201@freebsd.org> <430EBA46.2060307@orthanc.ca> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 26 Aug 2005 13:04:03 +0200 In-Reply-To: <430EBA46.2060307@orthanc.ca> (Lyndon Nerenberg's message of "Thu, 25 Aug 2005 23:44:22 -0700") Message-ID: <86d5o1q7rw.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -5.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on tim.des.no Cc: arch@freebsd.org Subject: Re: splitting off RPC and friends X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2005 11:04:09 -0000 Lyndon Nerenberg writes: > RPC and XDR are far from dead. Are you sure splitting these out is > wise? We have to keep the code around, for NFS if nothing else. What's > the benefit of moving the routines into a separate library? Faster load times for the great majority of libc consumers which do not need XDR, RPC or NIS? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Aug 26 11:05:55 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D908B16A41F for ; Fri, 26 Aug 2005 11:05:55 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40E0F43D53 for ; Fri, 26 Aug 2005 11:05:55 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id A6BB7BC66; Fri, 26 Aug 2005 11:05:52 +0000 (UTC) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 26 Aug 2005 13:04:03 +0200." <86d5o1q7rw.fsf@xps.des.no> Date: Fri, 26 Aug 2005 13:05:52 +0200 Message-ID: <99653.1125054352@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: arch@freebsd.org, Lyndon Nerenberg Subject: Re: splitting off RPC and friends X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2005 11:05:56 -0000 In message <86d5o1q7rw.fsf@xps.des.no>, =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: >Lyndon Nerenberg writes: >> RPC and XDR are far from dead. Are you sure splitting these out is >> wise? We have to keep the code around, for NFS if nothing else. What's >> the benefit of moving the routines into a separate library? > >Faster load times for the great majority of libc consumers which do >not need XDR, RPC or NIS? Very few programs are impacted by code in libc which they don't use, libc tends to be in-core most of the time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 26 17:40:03 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECBFB16A41F for ; Fri, 26 Aug 2005 17:40:03 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40B1443D45 for ; Fri, 26 Aug 2005 17:40:02 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:aTsrsm/2YNfv3l/XIY4lWNtpERGxV65/BajFdDV3vx1Yq2rqcdyEbli3wi+YLiK0@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7QHdPV7005715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Aug 2005 02:39:47 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 27 Aug 2005 02:39:25 +0900 Message-ID: From: Hajimu UMEMOTO To: "Poul-Henning Kamp" In-Reply-To: <99653.1125054352@phk.freebsd.dk> References: <86d5o1q7rw.fsf@xps.des.no> <99653.1125054352@phk.freebsd.dk> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA3 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sat, 27 Aug 2005 02:39:49 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= , Lyndon Nerenberg , arch@freebsd.org Subject: Re: splitting off RPC and friends X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2005 17:40:04 -0000 Hi, >>>>> On Fri, 26 Aug 2005 13:05:52 +0200 >>>>> "Poul-Henning Kamp" said: phk> In message <86d5o1q7rw.fsf@xps.des.no>, =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: >Lyndon Nerenberg writes: >> RPC and XDR are far from dead. Are you sure splitting these out is >> wise? We have to keep the code around, for NFS if nothing else. What's >> the benefit of moving the routines into a separate library? > >Faster load times for the great majority of libc consumers which do >not need XDR, RPC or NIS? phk> Very few programs are impacted by code in libc which they don't use, phk> libc tends to be in-core most of the time. I think netdb is tightly depending on NIS unless you specify -DNO_NIS when building libc. I'm not sure how many users are actually using NIS, though. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Fri Aug 26 18:19:49 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 612FD16A41F; Fri, 26 Aug 2005 18:19:49 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07F3243D46; Fri, 26 Aug 2005 18:19:48 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7QIJkAO030198; Fri, 26 Aug 2005 11:19:46 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7QIJjFx030197; Fri, 26 Aug 2005 11:19:45 -0700 Date: Fri, 26 Aug 2005 11:19:45 -0700 From: Brooks Davis To: Hajimu UMEMOTO Message-ID: <20050826181945.GB10222@odin.ac.hmc.edu> References: <86d5o1q7rw.fsf@xps.des.no> <99653.1125054352@phk.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9zSXsLTf0vkW971A" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: arch@freebsd.org, Poul-Henning Kamp , Lyndon Nerenberg , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: splitting off RPC and friends X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2005 18:19:49 -0000 --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 27, 2005 at 02:39:25AM +0900, Hajimu UMEMOTO wrote: > Hi, >=20 > >>>>> On Fri, 26 Aug 2005 13:05:52 +0200 > >>>>> "Poul-Henning Kamp" said: >=20 > phk> In message <86d5o1q7rw.fsf@xps.des.no>, =3D?iso-8859-1?q?Dag-Erling_= Sm=3DF8rgrav?=3D writes: > >Lyndon Nerenberg writes: > >> RPC and XDR are far from dead. Are you sure splitting these out is > >> wise? We have to keep the code around, for NFS if nothing else. What's > >> the benefit of moving the routines into a separate library? > > > >Faster load times for the great majority of libc consumers which do > >not need XDR, RPC or NIS? >=20 > phk> Very few programs are impacted by code in libc which they don't use, > phk> libc tends to be in-core most of the time. >=20 > I think netdb is tightly depending on NIS unless you specify -DNO_NIS > when building libc. I'm not sure how many users are actually using > NIS, though. I do. It's lightweight, fairly easy to configure, cross platform, and entierly in the base system. It would be nice though if we could move the nsswitch support for NIS into it's own module at some point so it's only inflicted on people who actually do use it. :) -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --9zSXsLTf0vkW971A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDD11AXY6L6fI4GtQRAlKJAJ9KzJ8iO6TSyVm/y6aQu4XIxB5jwACfbp2A JWb9OVMGq1QzyJPfqK6/cpo= =TQMK -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 26 22:01:11 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0486916A41F; Fri, 26 Aug 2005 22:01:11 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C3D043D53; Fri, 26 Aug 2005 22:01:10 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from peregrin.orthanc.ca (d216-232-211-96.bchsia.telus.net [216.232.211.96]) (authenticated bits=0) by orthanc.ca (8.13.3/8.13.3) with ESMTP id j7QM0xgG048468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2005 16:00:59 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Received: from [127.0.0.1] (localhost [127.0.0.1]) by peregrin.orthanc.ca (8.13.5.Beta0/8.13.5.Beta0) with ESMTP id j7QM0rQV001120; Fri, 26 Aug 2005 15:00:53 -0700 (PDT) In-Reply-To: References: <86d5o1q7rw.fsf@xps.des.no> <99653.1125054352@phk.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <612E8B11-7CCD-417F-9C2A-B237BCB1E811@orthanc.ca> Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Date: Fri, 26 Aug 2005 15:00:52 -0700 To: Hajimu UMEMOTO X-Mailer: Apple Mail (2.734) X-DCC-dcc.uncw.edu-Metrics: orthanc.ca 1201; Body=2 Fuz1=2 Fuz2=2 X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on orthanc.ca Cc: arch@freebsd.org Subject: Re: splitting off RPC and friends X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2005 22:01:11 -0000 On Aug 26, 2005, at 10:39 AM, Hajimu UMEMOTO wrote: > I'm not sure how many users are actually using > NIS, though. For sites that run a mix of routable and RFC 1918 networks, NIS is still quite commonly used to serve up the host names for the 1918 side of the network. Poor man's split DNS if you like. (In fact, I'll be installing yet another one of these setups this weekend.) And then there are the NIS-based maps for the automounter. RPC and NIS are alive and well, and aren't going away any time soon. --lyndon From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 00:29:43 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E4E316A41F; Sat, 27 Aug 2005 00:29:43 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [70.88.158.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09FF343D45; Sat, 27 Aug 2005 00:29:42 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [70.88.158.93]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id j7R0TdYS025741; Fri, 26 Aug 2005 20:29:41 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Fri, 26 Aug 2005 20:29:39 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Hajimu UMEMOTO In-Reply-To: Message-ID: <20050826202713.X1915@sasami.jurai.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [70.88.158.93]); Fri, 26 Aug 2005 20:29:41 -0400 (EDT) Cc: arch@FreeBSD.ORG Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2005 00:29:43 -0000 On Sat, 20 Aug 2005, Hajimu UMEMOTO wrote: > Our resolver reads resolv.conf once, and never re-read it. Recent > OpenBSD changed to re-read resolv.conf when it is updated. I believe it > is useful specially for mobile environment. The more useful solution is to run a local caching nameserver that forwards to the DHCP or location specific nameservers. I've got modifications to dhclient-script and a Makefile in /etc/namedb/ that implement this behavior. I'll clean it up for public consumption if others are interested. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 01:41:54 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 756C616A41F; Sat, 27 Aug 2005 01:41:54 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F51B43D45; Sat, 27 Aug 2005 01:41:53 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7R1frX1014792; Fri, 26 Aug 2005 18:41:53 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7R1frZU014791; Fri, 26 Aug 2005 18:41:53 -0700 Date: Fri, 26 Aug 2005 18:41:53 -0700 From: Brooks Davis To: "Matthew N. Dodd" Message-ID: <20050827014153.GA14720@odin.ac.hmc.edu> References: <20050826202713.X1915@sasami.jurai.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <20050826202713.X1915@sasami.jurai.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2005 01:41:54 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 26, 2005 at 08:29:39PM -0400, Matthew N. Dodd wrote: > On Sat, 20 Aug 2005, Hajimu UMEMOTO wrote: > >Our resolver reads resolv.conf once, and never re-read it. Recent=20 > >OpenBSD changed to re-read resolv.conf when it is updated. I believe it= =20 > >is useful specially for mobile environment. >=20 > The more useful solution is to run a local caching nameserver that=20 > forwards to the DHCP or location specific nameservers. >=20 > I've got modifications to dhclient-script and a Makefile in /etc/namedb/= =20 > that implement this behavior. I'll clean it up for public consumption if= =20 > others are interested. Sounds useful to me. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDD8ThXY6L6fI4GtQRAjZgAJ9p/d7gZKgYCh8mcSS4o4IwSTd8OwCgpbL9 wBbAuDYILStOYI23Wi5zsP4= =GfIL -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 01:58:46 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B09C916A41F for ; Sat, 27 Aug 2005 01:58:46 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id E81EF43D45 for ; Sat, 27 Aug 2005 01:58:45 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 41078 invoked by uid 399); 27 Aug 2005 01:58:44 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 27 Aug 2005 01:58:44 -0000 Message-ID: <430FC8D3.9030701@FreeBSD.org> Date: Fri, 26 Aug 2005 18:58:43 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Matthew N. Dodd" References: <20050826202713.X1915@sasami.jurai.net> In-Reply-To: <20050826202713.X1915@sasami.jurai.net> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.ORG Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2005 01:58:46 -0000 Matthew N. Dodd wrote: > On Sat, 20 Aug 2005, Hajimu UMEMOTO wrote: > >> Our resolver reads resolv.conf once, and never re-read it. Recent >> OpenBSD changed to re-read resolv.conf when it is updated. I believe >> it is useful specially for mobile environment. > > > The more useful solution is to run a local caching nameserver that > forwards to the DHCP or location specific nameservers. > > I've got modifications to dhclient-script and a Makefile in /etc/namedb/ > that implement this behavior. I'll clean it up for public consumption > if others are interested. I'm interested in reviewing that. As a general case, I'm ambivalent about using a local (on the same system) forwarder, as they can lead to unpredictable results. If the system is non-mobile, and the network configuration (including resolving name servers) is stable, and well designed, then a local forwarder is probably going to be ok. If the system is mobile, and even occasionally is moved into an unknown, or poorly configured network (think hotel room networks and other for-pay hotspots that do wacky DNS tricks) a local forwarder is likely to cause additional problems and confusion that can be difficult to debug. On the other hand, a local resolver (without forwarding) in that same situation would lead to equally unpredictable results. In short, I think that this is something I'd like to see us explore, but it should definitely be optional, and come with lots of warnings. Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 02:07:52 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E837416A41F for ; Sat, 27 Aug 2005 02:07:52 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 0052243D48 for ; Sat, 27 Aug 2005 02:07:51 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 48920 invoked by uid 399); 27 Aug 2005 02:07:51 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 27 Aug 2005 02:07:51 -0000 Message-ID: <430FCAF5.90701@FreeBSD.org> Date: Fri, 26 Aug 2005 19:07:49 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hajimu UMEMOTO References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2005 02:07:53 -0000 I've been following this thread with interest, and while I applaud the effort that's gone into this I'm not sure it has a very high cost/benefit ratio for the majority of FreeBSD systems. This would potentially be useful for mobile systems that will often be moved into different networks, but frankly I don't see a benefit for the vast majority of systems that will have the same resolv.conf file for weeks, months, or years. I'm also thinking of various types of high performance systems that actually do thousands of DNS queries a minute. While a stat() call in the resolver path for every query might not be noticeable on a "typical" system, they would add up on systems that are already being stressed. Personally, I would much rather we add some method of "HUPing" the resolver to re-read resolv.conf. That way we could add that command to dhclient-script and send it whenever the resolv.conf file is actually changed. This could also be used by sysadmins for typically "static" systems instead of having to restart services on those systems. IF we go the route of dynamically re-reading the conf file (and I hope we don't), then at minimum I think that the stat() and kqueue methods should be benchmarked with as close to real world loads as possible. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 02:19:09 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7E3716A41F for ; Sat, 27 Aug 2005 02:19:09 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [70.88.158.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FAAB43D46 for ; Sat, 27 Aug 2005 02:19:09 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [70.88.158.93]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id j7R2J6lG035118 for ; Fri, 26 Aug 2005 22:19:08 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Fri, 26 Aug 2005 22:19:06 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: arch@FreeBSD.ORG In-Reply-To: <20050827014153.GA14720@odin.ac.hmc.edu> Message-ID: <20050826221016.B1915@sasami.jurai.net> References: <20050826202713.X1915@sasami.jurai.net> <20050827014153.GA14720@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1788720939-1125109146=:1915" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [70.88.158.93]); Fri, 26 Aug 2005 22:19:08 -0400 (EDT) Cc: Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2005 02:19:10 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1788720939-1125109146=:1915 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 26 Aug 2005, Brooks Davis wrote: > On Fri, Aug 26, 2005 at 08:29:39PM -0400, Matthew N. Dodd wrote: >> I've got modifications to dhclient-script and a Makefile in /etc/namedb/ >> that implement this behavior. I'll clean it up for public consumption if >> others are interested. > > Sounds useful to me. I've not yet come up with a good way to configure this behavior, other than the bit that turns of the resolv.conf updating (touch /etc/dhclient-no-resolv-conf). /var/run/named.forwarders is updated with a Bind named.conf forwarders configuration section containing all DHCP provided nameservers. The Makefile is placed in /etc/namedb and /etc/namedb/named.conf is moved to /etc/named.conf.in and modified to include the lines: forward only; #include "/var/run/named.forwarders" This will cause the nameserver to never perform recursive queries directly but to forward everything to the listed forwarders. I'm open to suggestions on where to place the configuration knobs for this functionality. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 --0-1788720939-1125109146=:1915 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dhclient-script.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20050826221905.K1915@sasami.jurai.net> Content-Description: Content-Disposition: attachment; filename="dhclient-script.patch" SW5kZXg6IGRoY2xpZW50LXNjcmlwdA0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KUkNTIGZpbGU6IC9ob21lL2N2cy9zcmMvc2Jpbi9kaGNsaWVudC9kaGNs aWVudC1zY3JpcHQsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjUNCmRpZmYg LXUgLXUgLXIxLjUgZGhjbGllbnQtc2NyaXB0DQotLS0gZGhjbGllbnQtc2Ny aXB0CTI2IEp1bCAyMDA1IDE4OjI3OjM3IC0wMDAwCTEuNQ0KKysrIGRoY2xp ZW50LXNjcmlwdAkxMiBBdWcgMjAwNSAxNToxMDozMyAtMDAwMA0KQEAgLTEy OCw2ICsxMjgsMjMgQEANCiAJZmkNCiB9DQogDQorbWFrZV9uYW1lZF9mb3J3 YXJkZXJzKCkgew0KKwlpZiBbIC16ICIkbmV3X2RvbWFpbl9uYW1lX3NlcnZl cnMiIF07IHRoZW4NCisJCXJldHVybiAxDQorCWZpDQorDQorCXJtIC1mIC92 YXIvcnVuL25hbWVkLmZvcndhcmRlcnMNCisJZWNobyAiCWZvcndhcmRlcnMg eyIgPiAvdmFyL3J1bi9uYW1lZC5mb3J3YXJkZXJzDQorCWZvciBuYW1lc2Vy dmVyIGluICRuZXdfZG9tYWluX25hbWVfc2VydmVyczsgZG8NCisJCWVjaG8g IgkJJG5hbWVzZXJ2ZXI7IiA+PiAvdmFyL3J1bi9uYW1lZC5mb3J3YXJkZXJz DQorCWRvbmUNCisJZWNobyAiCX07IiA+PiAvdmFyL3J1bi9uYW1lZC5mb3J3 YXJkZXJzDQorDQorCWNkIC9ldGMvbmFtZWRiICYmIG1ha2UNCisNCisJcmV0 dXJuIDANCit9DQorDQogYWRkX25ld19yZXNvbHZfY29uZigpIHsNCiAJIyBY WFggT2xkIGNvZGUgZGlkIG5vdCBjcmVhdGUvdXBkYXRlIHJlc29sdi5jb25m IHVubGVzcyBib3RoDQogCSMgJG5ld19kb21haW5fbmFtZSBhbmQgJG5ld19k b21haW5fbmFtZV9zZXJ2ZXJzIHdlcmUgcHJvdmlkZWQuICBQUg0KQEAgLTEz NSw2ICsxNTIsMTAgQEANCiAJIyB0aHVzIGJyb2tlIHRoZSBzY3JpcHQuIFRo aXMgY29kZSBjcmVhdGVzIHRoZSByZXNvbHYuY29uZiBpZiBlaXRoZXINCiAJ IyBhcmUgcHJvdmlkZWQuDQogDQorCWlmIFsgLWYgL2V0Yy9kaGNsaWVudC1u by1yZXNvbHYtY29uZiBdOyB0aGVuDQorCQlyZXR1cm4gMA0KKwlmaQ0KKw0K IAlybSAtZiAvZXRjL3Jlc29sdi5jb25mLnN0ZA0KIA0KIAlpZiBbIC1uICIk bmV3X2RvbWFpbl9uYW1lIiBdOyB0aGVuDQpAQCAtMjQwLDYgKzI2MSw3IEBA DQogCQlhZGRfbmV3X2FsaWFzDQogCWZpDQogCWFkZF9uZXdfcmVzb2x2X2Nv bmYNCisJbWFrZV9uYW1lZF9mb3J3YXJkZXJzDQogCTs7DQogDQogRVhQSVJF fEZBSUwpDQpAQCAtMjY3LDYgKzI4OSw3IEBADQogCQkJCWFkZF9uZXdfYWxp YXMNCiAJCQlmaQ0KIAkJCWFkZF9uZXdfcm91dGVzDQorCQkJbWFrZV9uYW1l ZF9mb3J3YXJkZXJzDQogCQkJaWYgYWRkX25ld19yZXNvbHZfY29uZjsgdGhl bg0KIAkJCQlleGl0X3dpdGhfaG9va3MgMA0KIAkJCWZpDQo= --0-1788720939-1125109146=:1915 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=Makefile Content-Transfer-Encoding: BASE64 Content-ID: <20050826221906.R1915@sasami.jurai.net> Content-Description: Content-Disposition: attachment; filename=Makefile IyAkSWQkDQojDQoNCm5hbWVkLmNvbmY6IG5hbWVkLmNvbmYuaW4gL3Zhci9y dW4vbmFtZWQuZm9yd2FyZGVycw0KCWNwcCAtUCAtQyBuYW1lZC5jb25mLmlu ID4gJEANCgkvZXRjL3JjLmQvbmFtZWQgcmVzdGFydA0K --0-1788720939-1125109146=:1915-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 12:34:33 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3093616A41F; Sat, 27 Aug 2005 12:34:33 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 613C343D45; Sat, 27 Aug 2005 12:34:31 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7RCYPoY055823; Sat, 27 Aug 2005 16:34:25 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Sat, 27 Aug 2005 16:38:09 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: freebsd-arch@freebsd.org In-Reply-To: <20050827120008.82E2316A420@hub.freebsd.org> Message-ID: <20050827163141.V5409@stinger.cc.rsu.ru> References: <20050827120008.82E2316A420@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net Cc: Brooks Davis Subject: Re: splitting off RPC and friends X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2005 12:34:33 -0000 Hi! > It would be nice though if we could move the nsswitch support for NIS > into it's own module at some point so it's only inflicted on people who > actually do use it. :) It's not very difficult. I can do it :) But moving NIS to its own module will cause the code duplication, because there are a lot of cases, when nis and files sources are implemented together. With best regards, Michael Bushkov Rostov State University From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 17:06:01 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75E1A16A41F; Sat, 27 Aug 2005 17:06:01 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2230243D45; Sat, 27 Aug 2005 17:06:01 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7RH60SH010040; Sat, 27 Aug 2005 10:06:00 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7RH60YU010039; Sat, 27 Aug 2005 10:06:00 -0700 Date: Sat, 27 Aug 2005 10:06:00 -0700 From: Brooks Davis To: "Matthew N. Dodd" Message-ID: <20050827170600.GB14720@odin.ac.hmc.edu> References: <20050826202713.X1915@sasami.jurai.net> <20050827014153.GA14720@odin.ac.hmc.edu> <20050826221016.B1915@sasami.jurai.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline In-Reply-To: <20050826221016.B1915@sasami.jurai.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2005 17:06:01 -0000 --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 26, 2005 at 10:19:06PM -0400, Matthew N. Dodd wrote: > On Fri, 26 Aug 2005, Brooks Davis wrote: > >On Fri, Aug 26, 2005 at 08:29:39PM -0400, Matthew N. Dodd wrote: > >>I've got modifications to dhclient-script and a Makefile in /etc/namedb/ > >>that implement this behavior. I'll clean it up for public consumption = if > >>others are interested. > > > >Sounds useful to me. >=20 > I've not yet come up with a good way to configure this behavior, other=20 > than the bit that turns of the resolv.conf updating (touch=20 > /etc/dhclient-no-resolv-conf). >=20 > /var/run/named.forwarders is updated with a Bind named.conf forwarders=20 > configuration section containing all DHCP provided nameservers. The=20 > Makefile is placed in /etc/namedb and /etc/namedb/named.conf is moved to= =20 > /etc/named.conf.in and modified to include the lines: >=20 > forward only; > #include "/var/run/named.forwarders" >=20 > This will cause the nameserver to never perform recursive queries directl= y=20 > but to forward everything to the listed forwarders. >=20 > I'm open to suggestions on where to place the configuration knobs for thi= s=20 > functionality. I'd like to see dhclient-script pull in /etc/rc.conf. By doing: =2E /etc/rc.subr load_rc_config dhclient-script -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --oC1+HKm2/end4ao3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDEJ13XY6L6fI4GtQRAqqHAKDFgu/WyZTUPBVUsldsDZ/1drTJ1QCfSMmE BWzyRwsFuew6C5ej5j2ZGLE= =OPNj -----END PGP SIGNATURE----- --oC1+HKm2/end4ao3-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 18:56:44 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C70816A41F for ; Sat, 27 Aug 2005 18:56:44 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: from useful.dataloss.nl (useful.dataloss.nl [80.84.249.161]) by mx1.FreeBSD.org (Postfix) with SMTP id C968443D45 for ; Sat, 27 Aug 2005 18:56:43 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: (qmail 20875 invoked by uid 1001); 27 Aug 2005 18:56:40 -0000 Date: Sat, 27 Aug 2005 20:56:40 +0200 From: Peter van Dijk To: freebsd-arch@freebsd.org Message-ID: <20050827185639.GA20018@dataloss.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: portsnap base thought X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2005 18:56:44 -0000 Hi, portsnap requires that the /usr/ports on a machine was created with portsnap extract, before it will allow you to portsnap update. Suggestion: make the portstree as delivered in 6.0-RELEASE (on the CD etc.) compatible with portsnap extract, so people can use portsnap from a base CD install without having to fetch the portstree through portsnap first. I do realise this might bloat the CD image by about 50 megabytes (because of /var/db/portsnap) but I think it's worth it. Cheers, Peter -- peter@dataloss.nl | ~ tonight tonight, what is this potion http://blog.dataloss.nl/ | ~ that makes a fool of me UnderNet/#clue | Wayfinder, fr-025 soundtrack From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 21:16:13 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7B0316A41F for ; Sat, 27 Aug 2005 21:16:13 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8893B43D46 for ; Sat, 27 Aug 2005 21:16:13 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mr6so.prod.shaw.ca (pd3mr6so-qfe3.prod.shaw.ca [10.0.141.21]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ILW00IYVGEYHIA0@l-daemon> for freebsd-arch@freebsd.org; Sat, 27 Aug 2005 15:16:10 -0600 (MDT) Received: from pn2ml9so.prod.shaw.ca ([10.0.121.7]) by pd3mr6so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ILW0039SGEYS3K0@pd3mr6so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 27 Aug 2005 15:16:10 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ILW001I2GEXTF@l-daemon> for freebsd-arch@freebsd.org; Sat, 27 Aug 2005 15:16:10 -0600 (MDT) Date: Sat, 27 Aug 2005 14:16:09 -0700 From: Colin Percival To: Peter van Dijk Message-id: <4310D819.9080903@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.92.0.0 User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050724) Cc: freebsd-arch@freebsd.org Subject: re: portsnap base thought X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2005 21:16:14 -0000 Peter van Dijk wrote: > portsnap requires that the /usr/ports on a machine was created with > portsnap extract, before it will allow you to portsnap update. > > Suggestion: make the portstree as delivered in 6.0-RELEASE (on the CD > etc.) compatible with portsnap extract, so people can use portsnap > from a base CD install without having to fetch the portstree through > portsnap first. I do realise this might bloat the CD image by about > 50 megabytes (because of /var/db/portsnap) but I think it's worth it. There are two quite separate issues here: 1. When "portsnap fetch" is first run, portsnap needs to download a compressed snapshot of the entire tree (roughly 35MB). 2. If you try to run "portsnap update" against a ports tree which was not created with "portsnap extract", portsnap will refuse to run because it doesn't know which files in the ports tree need to be updated. The solution to the first problem is to ship a copy of /var/db/portsnap on the release images; this would add roughly 35MB to the release size, but it would also allow 28MB to be reclaimed by not shipping ports.tgz (and instead extracting it using portsnap). The solution to the second problem is to ship a copy of the ports tree which contains an appropriate /usr/ports/.portsnap.INDEX file; this would add roughly 600kB. Given that portsnap currently only has about 1500-2000 users (it's hard to get an accurate estimate since people tend not to update their ports trees as often during the freeze, but I'm fairly confident the number is in that range) it doesn't seem reasonable to make major changes to how releases are done yet; but assuming the usage of portsnap increases significantly over the next year, this is certainly something to consider for 7.0-R. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 23:51:45 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5702616A41F; Sat, 27 Aug 2005 23:51:45 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEBEA43D45; Sat, 27 Aug 2005 23:51:44 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-66-30-115-133.hsd1.ma.comcast.net ([66.30.115.133]) by comcast.net (sccrmhc13) with ESMTP id <20050827235141013005e73oe>; Sat, 27 Aug 2005 23:51:41 +0000 Received: from c-66-30-115-133.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id j7RNpfwm003153; Sat, 27 Aug 2005 19:51:41 -0400 (EDT) (envelope-from rodrigc@c-66-30-115-133.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-115-133.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id j7RNpeeY003152; Sat, 27 Aug 2005 19:51:40 -0400 (EDT) (envelope-from rodrigc) Date: Sat, 27 Aug 2005 19:51:40 -0400 From: Craig Rodrigues To: obrien@freebsd.org, freebsd-arch@freebsd.org Message-ID: <20050827235140.GA3063@crodrigues.org> References: <20050810005323.GA42721@crodrigues.org> <20050810032308.GA80916@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050810032308.GA80916@dragon.NUXI.org> User-Agent: Mutt/1.5.9i Cc: Subject: Re: [RFC] -Wredundant-decls: keep it or remove it? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2005 23:51:45 -0000 On Tue, Aug 09, 2005 at 08:23:08PM -0700, David O'Brien wrote: > On Tue, Aug 09, 2005 at 08:53:23PM -0400, Craig Rodrigues wrote: > > It is illegal in ISO C to declare a struct as extern (implying external > > linkage) , and then declare it as static (implying internal linkage). > .. > > OPTION 2: > > Forward declare routedomain as static, but remove -Wredundant-decls > > from kernel makefiles: > > static struct domain routedomain; > > .... > > static struct domain routedomain = { ..... } > > > > For OPTION 2, it is necessary to remove -Wredundant-decls > > because you will get a new compiler warning: > > > > warning: redundant redeclaration of 'routedomain' > > warnig: previous declaration was here ... > > This is a GCC bug that I am working to get fixed. Hi, Did you try something like this patch to GCC? Index: c-decl.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/c-decl.c,v retrieving revision 1.630.6.16 diff -u -u -r1.630.6.16 c-decl.c --- c-decl.c 16 Aug 2005 20:34:19 -0000 1.630.6.16 +++ c-decl.c 27 Aug 2005 23:43:06 -0000 @@ -1559,7 +1559,10 @@ && !(DECL_EXTERNAL (olddecl) && !DECL_EXTERNAL (newdecl)) /* Don't warn about forward parameter decls. */ && !(TREE_CODE (newdecl) == PARM_DECL - && TREE_ASM_WRITTEN (olddecl) && !TREE_ASM_WRITTEN (newdecl))) + && TREE_ASM_WRITTEN (olddecl) && !TREE_ASM_WRITTEN (newdecl)) + /* Don't warn about forward static variable decls. */ + && !(TREE_CODE (newdecl) == VAR_DECL + && !TREE_PUBLIC (olddecl) && !TREE_PUBLIC (newdecl))) { warning ("%Jredundant redeclaration of %qD", newdecl, newdecl); warned = true; -- Craig Rodrigues rodrigc@crodrigues.org