Date: Fri, 14 Nov 2003 07:41:24 -0800 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert2@mindspring.com>, jos@catnook.com Cc: freebsd-hackers@freebsd.org Subject: Re: non-root process and PID files Message-ID: <200311140741.24751.wes@softweyr.com> In-Reply-To: <3FB4A449.7452A382@mindspring.com> References: <3F9CF3F6.8307.ABC1250@localhost> <20031113165647.GA80504@lizzy.catnook.com> <3FB4A449.7452A382@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311140741.24751.wes>