Description of problem: If rndc fails, named fails to stop. Version-Release number of selected component (if applicable): bind-9.3.3-0.1.rc2.fc5 How reproducible: Always Steps to Reproduce: 1. /etc/init.d/named start 2. /etc/init.d/named stop Actual results: Stopping named: [FAILED] Expected results: Stopping named: [ OK ] Additional info: There's an error in the test of the rndc RETVAL which guarantees named will always fail to stop if rndc fails to stop it. Patch attached. The patch also corrects a typo in a comment.
Created attachment 138743 [details] Patch to /etc/init.d/named
hmm, not sure if we want to kill named in any case...need to check it.
Could you please run "/usr/sbin/rndc stop" and attach an output here?
Not sure if this helps, but this problem occurs if your named.conf rndc key does not match your rndc.key one. Obviously rndc will fail but you should still be able to stop named somehow!
Contents of named.conf include // Disable rndc controls { }; So "rndc stop" yields rndc: connect failed: 127.0.0.1#953: connection refused The point is that there's a bug in the logic of the init script whether you use rndc or not. Without changing -eq to -ne in the test of $RETVAL from rndc, the if block is useless. If rndc succeeds, then the if block gets executed, including testing if named is still running, which it isn't, so the script exits the block. If rndc fails, the block is skipped in its entirety, not meeting the intent of the block to act as a failsafety. OTOH if you're changing the intent of the block, then the bug is that the if statement exists at all. Just execute the block no matter what.
Please check the latest test update for FC5 (bind-9.3.3-0.2.rc2.fc5). There is a hack there what you have suggested.
Just got the erratum from updates, rather than testing. Works okay.
So does the bind-9.3.3-0.2.rc2.fc5 work for you?
Yes. bind-9.3.3-0.2.rc2.fc5 is the version I got from updates. It works.
okay, closing as fixed.