Xref: utzoo comp.protocols.tcp-ip.domains:346 comp.unix.wizards:23487 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!wuarchive!udel!princeton!twg.com!david From: david@twg.com (David S. Herron) Newsgroups: comp.protocols.tcp-ip.domains,comp.unix.wizards Subject: Re: Monitoring your nameserver Message-ID: <7769@gollum.twg.com> Date: 16 Aug 90 21:19:42 GMT References: <9008141525.AA27754@sci.ccny.cuny.edu> Reply-To: david@twg.com (David S. Herron) Followup-To: comp.protocols.tcp-ip.domains Distribution: inet Organization: The Wollongong Group, Palo Alto, CA Lines: 49 In article <9008141525.AA27754@sci.ccny.cuny.edu> dan@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, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- Sign me up for one "I survived Jaka's Story" T-shirt!