rndc halt -p behavior

[Rich Goodson]

Basically, I'm trying to use a shell script to replace the missing  
'restart' argument to rndc,  so I was looking for  some sort of return  
value that tells me, "hey, your old named process is now gone, feel  
free to start a new one".

What doesn't seem to jibe to me with the behavior I see is this line:

> If -p is specified named's process id is returned. This allows an  
> external process to determine when named had completed halting.

Whether named is still answering queries or just cleaning up its  
allocated memory, the PID is returned BEFORE named is gone, as named  
is still running for a good while after the PID is returned (I've seen  
up to 15 or 20 seconds or so).  So, if I use this in a script,  
assuming the behavior that seems to be implied in the documentation,  
I'm going to be starting a new instance of named once the PID is  
returned, so I'm going to end up with 2 concurrent named processes.

I understand that I probably seem like a pedantic pain in the ass, but  
is this broken, or is the documentation wrong?  You seem to be saying  
that rndc is behaving correctly, so I must therefore assume that the  
documentation is wrong in this respect and use some sort of logic in  
my script to tell me when named has gone *poof*.

Unless the documentation is using a different definition of the word  
"halt" than I am, which is entirely possible.  I'm defining "halted"  
in my head as the process is gone and no longer appears in a process  
listing, whereas you may be defining "halted" as when named has  
stopped answering queries and has released its hold on port 53.  If  
this is the case, it might not be a big deal if there are two  
concurrent named processes, as the new one is free to grab the port  
and start answering queries while the old one simply cleans up after  
itself, memory-wise.

-rich

On Jan 21, 2009, at 5:00 PM, Mark Andrews wrote:

>
> In message <2971F259-4897-48F8-B418-2F759907596B at gronkulator.com>,  
> Rich Goodson
> writes:
>> The behavior of 'rndc halt -p' appears to be different from the =20
>> documentation.
>>
>> According to the BIND 9.4 ARM rndc section:
>> halt [-p] Stop the server immediately. Recent changes made through  
>> =20
>> dynamic update or IXFR
>> are not saved to the master =EF=AC=81les, but will be rolled  
>> forward =
>> from the =20
>> journal =EF=AC=81les when the
>> server is restarted. If -p is speci=EF=AC=81ed named=E2=80=99s  
>> process =
>> id is =20
>> returned. This allows an external
>> process to determine when named had completed halting.
>>
>> But the actual behavior seems to be that 'rndc halt -p' returns =20
>> immediately with the PID of named, but a 'ps -ef' shows named still  
>> =20
>> running until it's done answering its unfinished recursive queries  
>> (or =20=
>>
>> whatever it's busy doing).
>>
>> Is rndc broken, or is the documentation wrong, or am I missing =20
>> something?
>>
>> If it makes a difference, this is on a server that exclusively does  
>> =20
>> recursive resolution and does not serve any authoritative zones.
>>
>> -rich
>
> 	named is just freeing all memory that it has allocated.  If there
> 	has been a memory leak this is when it will be detected.
>
> 	Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20090121/a32ffdc2/attachment.html>