Re: rndc halt -p behavior
I wasn't talking about (or even really looking at, at the time) the output of rndc -help. I was originally discussing the description in the Administrators Reference Manual for Bind 9.4. -rich On Jan 23, 2009, at 1:45 AM, Doug Barton wrote: Niall O'Reilly wrote: On Wed, 2009-01-21 at 19:14 -0600, Jeremy C. Reed wrote: Maybe we should just remove the immediately part. Any suggestions would be appreciated. If you're going to make a change, adding a little more information wouldn't hurt, would it? The output of 'rndc -h' is already quite lengthy, and there is an 80-column terminal limit to consider Doug ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc halt -p behavior
On Wed, 2009-01-21 at 19:14 -0600, Jeremy C. Reed wrote: Maybe we should just remove the immediately part. Any suggestions would be appreciated. If you're going to make a change, adding a little more information wouldn't hurt, would it? Perhaps: s/immediately/cleanly (which may take a little time)/ IHTH /Niall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc halt -p behavior
Niall O'Reilly wrote: On Wed, 2009-01-21 at 19:14 -0600, Jeremy C. Reed wrote: Maybe we should just remove the immediately part. Any suggestions would be appreciated. If you're going to make a change, adding a little more information wouldn't hurt, would it? The output of 'rndc -h' is already quite lengthy, and there is an 80-column terminal limit to consider Doug ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc halt -p behavior
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
Re: rndc halt -p behavior
Rich Goodson wrote: 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. You are expected to 'wait' on the PID that was returned before you start anything new. rndc operates asynchronously to the BIND process, so it does not wait for BIND to exit. Reference: 'man wait' AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc halt -p behavior
In message 1a345677-0c03-45a7-a1e1-af364fe87...@gronkulator.com, Rich Goodson writes: 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. pid=`rndc halt -p` case $pid in pid:*) pid=`expr $pid : pid: \([0-9]*\)` echo -n waiting for $pid to exit while kill -0 $pid 2 /dev/null ; do echo -n .; sleep 1; done echo . done.; ;; esac 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 --Apple-Mail-20-871872810 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable htmlbody style=3Dword-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; divdivBasically, I'm trying = to use a shell script to replace the missing 'restart' argument to rndc, = nbsp;so I was looking for nbsp;some sort of return value that tells = me, hey, your old named process is now gone, feel free to start a new = one./divdivbr/divdivWhat doesn't seem to jibe to me with the = behavior I see is this line:/divdivbr/divdiv/divblockquote = type=3DcitedivIf -p is specified named's process id is returned. = This allows an external process to determine when named had completed = halting./div/blockquotedivbr/divdivWhether 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). nbsp;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
Re: rndc halt -p behavior
On Wed, 21 Jan 2009, Rich Goodson wrote: And I'm expected to know this, how? (incidentally, I added a 'wait' statement to my script after I discovered this behavior). This behavior does not appear to be what the documentation describes, is all I'm trying to say. Just to clarify the documentation part: Stop the server immediately. Maybe we should just remove the immediately part. Any suggestions would be appreciated. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc halt -p behavior
In article gl8hdv$228...@sf1.isc.org, Jeremy C. Reed jeremy_r...@isc.org wrote: On Wed, 21 Jan 2009, Rich Goodson wrote: And I'm expected to know this, how? (incidentally, I added a 'wait' statement to my script after I discovered this behavior). This behavior does not appear to be what the documentation describes, is all I'm trying to say. Just to clarify the documentation part: Stop the server immediately. Maybe we should just remove the immediately part. Any suggestions would be appreciated. Nothing happens instantaneously. This just tells it to stop immediately, but it still takes time for it to obey the command. Consider the analogy: if I call you and tell you to come to my house immediately, it will take you a few seconds to get to your car, then some number of minutes to drive here. The documentation even says that the purpose of returning the PID is so that you can tell when the process has actually gone away. What would be the point if the command didn't returning until the process had exited? -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc halt -p behavior
I think that the word immediately needs to stay, as that's what differentiates halt from stop. The documentation in its current form seems to imply that named returns a signal to rndc as it's exiting. Perhaps even a simple change such as: If -p is specified named’s process id is returned when named begins its shutdown process. This gives an external process a way to determine when named had completed halting via the 'wait' shell built- in or some other method. And here is where we realize why I don't make my living as a technical writer. -rich On Jan 21, 2009, at 7:14 PM, Jeremy C. Reed wrote: On Wed, 21 Jan 2009, Rich Goodson wrote: And I'm expected to know this, how? (incidentally, I added a 'wait' statement to my script after I discovered this behavior). This behavior does not appear to be what the documentation describes, is all I'm trying to say. Just to clarify the documentation part: Stop the server immediately. Maybe we should just remove the immediately part. Any suggestions would be appreciated. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc halt -p behavior
Jeremy C. Reed wrote: On Wed, 21 Jan 2009, Rich Goodson wrote: And I'm expected to know this, how? Rich, you read into the text what you wanted it to say (as you indicated in another message) but failed to try to understand what was actually there. The behavior you're saying you thought the docs described doesn't even make sense. Ok, I stopped the server for you, here is the pid it used to be running as. Huh? :) Just to clarify the documentation part: Stop the server immediately. Maybe we should just remove the immediately part. Any suggestions would be appreciated. rndc -h for 9.6.0-P1 reads: stop Save pending updates to master files and stop the server. stop -p Save pending updates to master files and stop the server reporting process id. halt Stop the server without saving pending updates. halt -p Stop the server without saving pending updates reporting process id. You might be able to squeeze more meaning into it by saying, Finish updates to master files and shut down the server. And, ...server, and report the pid of the named process. Arguably shut down implies the beginning of a process rather than a single event, although what's there now makes perfect sense to me. hth, Doug ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
