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-2f7599075...@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_andr...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
