Bug 154335

Created attachment 112919 [details]
Patch against named init for stop action

Running named without rndc control is not a supported configuration.
Many named features (eg. cache flush, cache dump, statistics, hot reload...)
are completely disabled without rndc control.
I will put in a fix to prevent use of rndc anywhere in the initscript
with a flag in /etc/sysconfig/named such as 'NO_RNDC=yes', but this
should not be the default.

This is now fixed with bind-9.3.1-4 in rawhide-2005-05-18 / FC4 -
named.init now falls back on using 'killproc -TERM named' if 
rndc stop fails. Will update bind-9.2.5 for FC3 shortly. 

Created attachment 114681 [details]
Patch against FC3 named init

Changes based on FC4-test update

Hmm...  Don't know why I said QUIT in the o.p.  Must have been a long
night....

I got the script from the FC4 rpm and tried the appropriate
differences on the FC3 script.  It appears to work okay.

I've attached a patch against the FC3 script for what I tested.

The fix appears to introduce a bug on my system.  If I "service named stop" it
reports and error, named DOES stop running, and the stale pid file doesn't get
rm'd.  If I "service named start" then it starts but it complains about existing
pid file.

I traced the problem to /etc/init.d/named in the stop() function.  $? appears to
get the value 1 no matter whether the rndc stop fails or succeeds.  I don't know
enough bash quirks, but the || && exceptions you guys put on the rndc stop line
appear to alter the $? value before RETVAL=$? gets assigned, causing RETVAL to
always be non-zero.

I'm sure I could patch this with some more lines and temp vars, but you bsh
wizards can do a better job.  Strange how no one else has reported this yet.

bind-9.2.5-2

I'm not seeing any problems like this, and other users that run with rndc
disabled have not reported any such problems .

Please check that you've upgraded to the latest bash-3.0.18 FC3 version.

When you start named, do you see log messages like 
  "named[...]: couldn't add command channel"
(ie. is rndc disabled on your system )?
I've tried starting/stopping/restarting named with rndc enabled and disabled,
and cannot reproduce this problem. 

It would be most helpful in enabling me to reproduce this problem if I could
see your configuration files - please tar them up:
  # tar -cphf /tmp/named.conf.tar /etc/{named.conf,/etc/rndc.key,/etc/rndc.conf}
and either append /tmp/named.conf.tar to this bug report or email it to me:
jvdias.

In the next version, I will edit the named.init file for clarity:
--- /etc/named.init, line 109:
stop() {
        # Stop daemons.
        echo -n $"Stopping $prog: "
	/usr/sbin/rndc stop >/dev/null 2>&1
	RETVAL=$?
	if pidof named >/dev/null; then
	   killproc named -TERM >/dev/null 2>&1 
	   $RETVAL=$?;
	fi
	if [ $RETVAL -eq 0 ]; then
	    rm -f /var/lock/subsys/named
	    rm -f /var/run/named.pid	    
	elif  pidof named >/dev/null; then
	    /usr/sbin/rndc stop >/dev/null 2>&1
	    RETVAL=$?
	    if pidof named >/dev/null; then
		killproc named -TERM >/dev/null 2>&1 
		$RETVAL=$?;
	    fi
	    if [ $RETVAL -eq 0 ]; then
		rm -f /var/lock/subsys/named
		rm -f /var/run/named.pid
	    fi;
	fi;
	if [ $RETVAL -eq 0 ]; then
	    success
	else
	    failure
        fi;
	echo
	return $RETVAL
}

I have all the latest errata, but an older kernel 2.6.10-1.770_FC3 (SCSI bugs
keeping me from moving up so far).  Bash is bash-3.0-18.

rndc is enabled and tested working.  If I issue the /usr/sbin/rndc stop manually
it works fine (exit 0) and named is stopped.  I edited the rndc stop line in
/etc/init.d/named to read just:

"/usr/sbin/rndc stop >/dev/null 2>&1"

and now the script works 100% as expected.  Splitting up the command and echoing
$? and RETVAL for debugging I can easily show that when the || &&'s are in there
the RETVAL is always non-zero EVEN THOUGH rndc stop is succeeding!  With the
||&& taken out the retval is as expected.

It totally appears to me like some simple bash semantics problem.  I can't
understand why it would be unique to my system.

For testing, I just changed the line to read:

/usr/sbin/rndc stop >/dev/null 2>&1 || echo foo && echo bar

and now I get:

#service named stop
Stopping named: bar
                                                           [  OK  ]
#service named start
Starting named:                                            [  OK  ]

So it looks like the logic in your short-circuit || is incorrect.  Does bash do
C-style order of ops for || && short circuit?  Looks like you want something
that explicit parens in C would provide:  a || (b && c)

Like I said, I don't know bash well enough to know how it handles that.  Your
updated script should fix the problem fine, though I'd probably test RETVAL
before "if pidof named" as perhaps rndc can return before named is truly dead
(otherwise why the sleep 2 in the restart() function?).

The problem is incorrect logic in the script line that reverts to killproc() if
rndc fails (line break added to avoid word wrap):

   /usr/sbin/rndc stop >/dev/null 2>&1 || pidof named >/dev/null && \
        killproc named -TERM >/dev/null 2>&1
   RETVAL=$?

The killproc call is executed if rndc succeeds OR if a process "named" exists. 
If rndc succeeds, pidof is never called, the named process no longer exists
and killproc fails, resulting in RETVAL=1.

I believe the script line should be:

   /usr/sbin/rndc stop >/dev/null 2>&1 || { pidof named >/dev/null && \
        killproc named -TERM >/dev/null 2>&1; }

which will execute the "pidof" and "killproc" commands only if rndc fails.

This really should be cleaned up, since this problem causes "service named
restart" to complain "ln: `/var/run/named.pid': File exists" .

Thought so.  Exactly my point.  You sure the solution is curly braces instead of
parens?  (As I said, I'm no bash expert, but at least this is an easy one to fix.)

Parentheses would work too, but at the expense of spawning a subprocess.
The curly braces just group the commands within the current process.

This bug is now fixed with bind-9.2.5-3 .

*** Bug 163598 has been marked as a duplicate of this bug. ***

update package is published