BIND 10 #2712: Cmdctl shutdown command does not shut down b10-cmdctl

BIND 10 Development do-not-reply at isc.org
Thu Apr 25 14:06:30 UTC 2013


#2712: Cmdctl shutdown command does not shut down b10-cmdctl
-------------------------------------+-------------------------------------
            Reporter:  jelte         |                        Owner:
                Type:  defect        |  vorner
            Priority:  medium        |                       Status:
           Component:  cmd-ctl       |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130423
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  6             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by vorner):

 Hello

 Replying to [comment:9 jinmei]:
 > Of course, the fundamental issue is, as has been the case, the naive
 > use of threads: creating a threaded application with an (seemingly) ad
 > hoc design, sharing various kinds of data without much consideration
 > of thread related issues.  We need a fundamental overhaul here, and
 > while I hope we'll actually have time for it some day, that's
 > certainly too big for this ticket.  My suggested fix is to send all
 > commands to msgq and have it send back to Cmdctl if the command is for
 > Cmdctl itself.  That's redundant in some sense but should work, and
 > coding-wise the change is quite small.

 I agree we need some rewrite here, but we need it almost everywhere. So
 I'm not optimistic here.

 Also, I think this approach is better, since the code has one less
 special-case. I guess the special-case was mostly a premature
 optimisation.

 However, it'll stop working if we ever unify the sessions (using just one
 from cfgmgr), because msgq refuses to send messages back to the sender,
 even if it is addressed there. Do you have idea why the special code is
 there?

 Some comments to the code:

 Could you describe the motivation of the
 `test_handle_post_request_to_itself`, for example in the docstring?

 I believe this should be „quit“, not „quite“:
 {{{
         # shutdown.  So "send bind10 command" will fail (it cannot
 complete
         # "quite").
 }}}

 I'm confused by this comment:
 {{{
     ignore_failure ('ignoring failure', optional): set to not None if
 bindctl
     is expected to fail (and it's acceptable).

     Fails if bindctl does not exit with status code 0 and ignore_failure
     is not None.
 }}}

 So, if `ignore_failure` is set to `None` (a false value), is the failure
 ignored?

-- 
Ticket URL: <http://bind10.isc.org/ticket/2712#comment:12>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list