From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 07:41:29 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C3BA16A4CE for ; Fri, 14 Nov 2003 07:41:29 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A4C743FDD for ; Fri, 14 Nov 2003 07:41:27 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 7931372E15; Fri, 14 Nov 2003 07:34:07 -0800 (PST) From: Wes Peters Organization: Softweyr To: Terry Lambert , jos@catnook.com Date: Fri, 14 Nov 2003 07:41:24 -0800 User-Agent: KMail/1.5.4 References: <3F9CF3F6.8307.ABC1250@localhost> <20031113165647.GA80504@lizzy.catnook.com> <3FB4A449.7452A382@mindspring.com> In-Reply-To: <3FB4A449.7452A382@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311140741.24751.wes@softweyr.com> cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 15:41:29 -0000 On Friday 14 November 2003 01:45 am, Terry Lambert wrote: > Jos Backus wrote: > > On Thu, Nov 13, 2003 at 02:45:18AM -0800, Terry Lambert wrote: > > > > > > There are also the small issues of ordering (the reason you can't > > > just run everything out of /etc/ttys via init in the first place), > > > > Sure. Hard to get right but not unsolvable. No reason you can't use > > process monitoring with something like rcNG. > > We tried very hard to do this on the InterJet. We still ended up > shooting most things in the head with large caliber bullets each > time the dial on demand interface went up or down because we did > not have the idea of hard and soft dependencies. On the latest iteration of system configuration at St. Bernard, we do track hard and soft dependencies. It turns out that it doesn't help as much as you'd like, because... > Even if we had > had them, though, we would still have been SOL, since many of the > Open Source programs we used cached information when they started. > Because of this, the data could get stale. Yup. I'm still amazed at the amount of software that doesn't have the ability to reset it's configuration without just shooting it and starting anew. > > /service/smtpd.{external,internal} > > Yeah, we did this, so that we could shoot "only" half the processes > in the head on link up/down. > > It sucked. We almost shipped a product that wouldn't hav worked > when we did the DNS split, because the dependency graph had to be > manually managed, and wasn't. We work in a much more static environment, which does make things a bit less of a challenge. I encountered all the same problems at DoBox, and solved them the same way. The St. Bernard appliances tend to get reconfigured several times during installation then rarely after the fact, so the challenge is to make sure we don't blow up while the customer is trying to get it working out of the box. Tracking the startup dependencies separately from reconfiguration dependencies helps quite a bit on this front. > > > and removing human error from adding and removing new things to be > > > monitored. > > > > That's a generic problem with any type of change management. > > Not really. If your configuration changes all happened in a > centralized data repository, and nobody cached anything, but got > their information from that central repository, and the interface > to the repository was a system interface (so the system could > cache on your behalf so performance didn't degrade unbearably), > THEN you might have something. After you rewrote millions of > lines of Open Source code to use your registry instead of working > the way it currently works, which is everyone has their own poop > files. If you are lucky, hitting them over the head with a > shovel (SIGHUP) works, and you don't have to kill and resurrect > them (you just have to wait a long time before the services become > usable again, e.g. DNS reading its config files). We have one of those. It even has a (relatively) stable API. It's called PostgreSQL, perhaps you've heard of it? ;^) Not what I'd recommend for a general configuration database, but we were already using it for other data, and it does a pretty good job of cache coherency. The differences in processor speed and memory cost these days vs. what you worked with at Whistle makes a lot of difference in what you can do as well. > Anyway, FreeBSD has steadfastly disliked the concept of a registry, > ever since Microsoft implemented it in Windows95; it's on of the > biggest "NIH" items of all time. And yet struggles to move towards it in a limited fashion, with the rc.conf concept. The problem would be making the necessary changes to all those millions of lines of somebody else's code to have everything work out of the "registry." -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com