Red Hat Bugzilla – Bug 509438
after patching NAMED it fails to automatically start after shutdown or restart
Last modified: 2013-04-30 19:43:44 EDT
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)
2nd time this happened ... automatic update sees a BIND patch, so it gets downloaded and applied. But the stop/start (or RESTART) sequence does not fully complete and NAMED is left not functional :-)
Reproducible: Didn't try
I remember having NAMED messed up sometime in the last year from an automatic patch ... so today (and it happened today on two RHEL v5 servers here) is the 2nd time I have seen it. (by IT I mean after the application of a patch the sub-system did not restart properly)
in /var/log/messages I see
Jul 2 10:49:57 names2 named: shutting down: flushing changes
Jul 2 10:49:57 names2 named: stopping command channel on 0.0.0.0#953
Jul 2 10:49:57 names2 named: no longer listening on 127.0.0.1#53
Jul 2 10:49:57 names2 named: no longer listening on 188.8.131.52#53
Jul 2 10:49:57 names2 named: no longer listening on 192.168.122.1#53
which I assume is from the attempt to shut down NAMED to get it to restart ... either by calling the SERVICE cmd or doing something else ...
but NAMED as a process never dies ... and thus never gets restarted either :-)
To fix todays problem I did a KILL -9 on it, then a SERVICE NAMED START to get things back to normal.
When this hits my two primary public DNS servers, it hurts :-)
Maybe I just have too many zones ... our two servers have duplicate configs ... they handle about 900 zones (each server has the same 900 zones) and both do a lot of recursive lookups.
The more I think about this, since it causes NAMED to hang, I am going to mark this as Urgent ... but I can be talked into downgrading the Severity I suppose :-)
Would it be possible to tell me if you have bind-chroot package installed and if you are running named in chroot environment, please?
Sorry, YES we have bind installed in the chroot environment.
I'm not able to reproduce this issue. Would it be possible to attach more information, please?
Try to update bind packages and then attach your /var/log/messages file, please. Make sure you check "private" button when you add an attachment if your log contains sensitive information.
If named hangs during update please do:
- yum --enablerepo rhel-debuginfo install bind-debuginfo.<x86_64|i386>
- gdb attach <named_pid>
then in the gdb terminal run "t a a bt full" and attach output here.
It seems this problem is already fixed. If you are still able to reproduce it please reopen this bug.