non-root process and PID files

[Jos Backus]

On Fri, Nov 14, 2003 at 01:45:45AM -0800, Terry Lambert wrote:
> Jos Backus wrote:
> > On Thu, Nov 13, 2003 at 02:45:18AM -0800, Terry Lambert wrote:
> > > > Why use pid files at all if you could be using a process supervisor instead?
> > >
> > > Who supervises the supervisor?
> > 
> > Heh. The supervisor should be small and robust, like init. Has init died on
> > you recently? Do you want to solve this problem or find Nirvana? If the
> > latter, don't use computers.
> 
> OK.  We already have one of those.  We call it "init".  8-).
 
Feature-wise init and svscan/supervise don't quite match; svscan has more
features, one of which being that it doesn't use a single control file which
if you screw it can render your system unusable. Even SysV init has more
(useful) features than ours. Also, init is kinda hard to use by non-root users
for that reason. People have been known to successfully replace init with
svscan, btw.

> > > 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.  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.
[snip]
> "Cacheing Considered Harmful".

This is really off-topic. But sure, there are instances where this approach is
less than robust. So what? Using pidfiles doesn't solve this problem either.

[snip]
> > > 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.

Ahh, the gold server approach lurks behind this (as one example). But until we
have a perfect world where people don't have to touch boxes directly we're
stuck with them making mistakes. Also, software can fail in ways unaccounted
for. But this is really off-topic.

> 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).
> 
> 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.
 
I think it would help if config files had a common structure and could be
queried for "interesting" service metadata like dependencies. See the Arusha
project for an example.

Anyway, we were talking about the use of pidfiles versus using a process
monitor. I'm simply claiming that using a process monitor is far superior.

> -- Terry

-- 
Jos Backus                       _/  _/_/_/      Sunnyvale, CA
                                _/  _/   _/
                               _/  _/_/_/
                          _/  _/  _/    _/
jos at catnook.com        _/_/   _/_/_/          require 'std/disclaimer'