Re: nanny (was Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed)
On 11/17/2011 13:24, Jeremy C. Reed wrote: Also what other types of nanny scripts do you use? (I already saw other emails with a few suggestions.) Personally I have always thought that the perl script in contrib is overly complex. #!/bin/sh while : ; do /path/named -f whatever other flags you use sleep 17 done You can tart this idea up with various redirections of stdout/stderr, a signal catcher to make it easier to kill, etc. Hopefully this is enough to get people thinking. hth, Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nanny (was Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed)
Personally I have always thought that the perl script in contrib is overly complex. #!/bin/sh while : ; do /path/named -f whatever other flags you use sleep 17 done That works, but note that it won't catch the problem if named hangs. Running it in xinetd works too, but same note. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nanny (was Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed)
On 11/18/2011 11:48, Evan Hunt wrote:
Personally I have always thought that the perl script in contrib is
overly complex.
#!/bin/sh
while : ; do
/path/named -f whatever other flags you use
sleep 17
done
That works, but note that it won't catch the problem if named hangs.
Right, but that's what ${Monitoring_System:=nagios} is for. :)
And it's been a looong time since I've had a running instance of
BIND refuse to answer queries.
--
We could put the whole Internet into a book.
Too practical.
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
nanny (was Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed)
On Wed, 16 Nov 2011, Phil Mayers wrote: It might be good if bind were able to re-start itself, rather than dying outright (e.g. re-exec the process) but that is dangerous too; it's better done by an unrelated supervising process. In the bind9 tarball's contrib directory there is a simply nanny perl script. Basically every 30 seconds it checks if PID still exists and does a dig. If no PID, it starts named. If dig fails, it kills the process and starts named. And waits 120 seconds before checking again. I am curious if any users of the nanny.pl script (or similar parent) had any crash but didn't notice it. (Maybe look at logs to see if named started.) Also what other types of nanny scripts do you use? (I already saw other emails with a few suggestions.) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nanny (was Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed)
On Thursday 17 November 2011 15:24:12 Jeremy C. Reed wrote: Also what other types of nanny scripts do you use? (I already saw other emails with a few suggestions.) Mine is a very trivial thing, basically just: /sbin/pidof named || restartNamed where restartNamed is a function to log the failure and run the distributor's BIND init script. This is invoked via /etc/cron.hourly, a run-parts(1) thing. I figure I can afford to be without any of my authoritative NS hosts for an hour, and for the one that serves my mail server, well, it is only going to defer everything during the named outage, not a big problem. Potentially less spam, actually! :) My other authoritative NS hosts are not doing much in the way of recursion, only serving local processes which are not very busy, so they're not very exposed, but they are running this cron job anyway. What I should perhaps do: separate the authoritative named instance from the recursive one on the mail server. I suppose BIND 10 does this, by design? -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nanny (was Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed)
On 11/17/11 1:45 PM, /dev/rob0 r...@gmx.co.uk wrote: What I should perhaps do: separate the authoritative named instance from the recursive one on the mail server. I suppose BIND 10 does this, by design? Yes, that is best practice (I keep reading it in docs from people I trust, like Cricket Liu). I've done it since BIND 8 (back in 4.x I was new enough I was just happy things worked)... Even on the same host, use IP aliases and keep separate process space for authoritative and recursive. Even better, different boxes/VMs with dedicated resource pools. There's really no good reason a bug in caching code should take down your authoritative instances, you just have to design it that way. The make lots of dedicated binaries approach of BIND 10 (sorry, one of the suggested approaches) reminds me of tinydns and qmail... However, since I have never liked either of those products, but do very much like the least privilege model, I will choose Postfix instead -- as something worthy of measuring up to. ;-) It will be fun to see how this pans out. -- By nature, men are nearly alike; by practice, they get to be wide apart. -- Confucius ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
