Monitoring your nameserver

David S. Herron david at twg.com
Fri Aug 17 07:19:42 AEST 1990


In article <9008141525.AA27754 at sci.ccny.cuny.edu> dan at SCI.CCNY.CUNY.EDU (Dan Schlitt) writes:
>Subject: How do YOU tell if named has died?

>So how do folks arrange to get automatic notification in a timely way
>when their nameserver software dies?  Answers for diverse hardware
>running unix for me, but others may be interested in other cases.

A quick hack would be to have a cron job on occasion which either
checks for the existance of critical processes & start's 'em up.  Or
just start's em & lets the processes fight over how many of which kind
are to be running.  Buuuut..

There's a generic problem with the way daemon's are done in Unix
whose issue is beyond `name service'.  That is that the daemons
are processes spun off into the background and not watched after.
[So therefore I'm cross-posting to unix-wizards..]  If `cron' dies
the system is just as crippled, though in a different way.  And
random people are just as likely to notice cron dieing as they
do when named dies now.

Something on my long and varied list of Things To Do (but haven't done
yet) is to write a program (name: respawn, or daemond) which watches
after generic processes.  As opposed to init which is suited to
watching after /etc/getty's.

This process will somehow take a list of processes to watch after.
It will be the parent of all those processes, so that it will be notified
of them dieing ..  It will have a number of actions it can do when
the process dies, like wait awhile before starting a new copy, start
one immediately, start one under some condition, etc.

This is different from init in that init is rather specific to
watching after getty's.  Even the SysV version of init .. though
the configurability of /etc/inittab gets close to what I have in mind.

This is different from inetd in that inetd is specific to network
services.  `cron' is not a network service, yet it also needs to
be watched over in this way.  Also inetd is suited to a situation
where it starts up a fresh process for each connection -- in the
particular case of named this is bad because named needs to be
running all the time.

At the moment we're relying on the hopefull assumption of a lack of
bugs in these background daemons.  (Where's some wood to knock on??)
-- 
<- David Herron, an MMDF weenie, <david at twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david at ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!



More information about the Comp.unix.wizards mailing list