BIND 10 #1049: bind10 should not resort to SIGKILL

[BIND 10 Development]

#1049: bind10 should not resort to SIGKILL
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  major         |                    Milestone:  New
           Component:  Boss of BIND  |  Tasks
           Sensitive:  0             |                     Keywords:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 I don't think bind10 (boss) should fallback to SIGKILL.

 I see it often on multiple systems. Processes aren't dieing with SIGTERM.
 So we brute force them to close. (General a "shutdown" sent over a command
 channel does work though.)

 I understand it is useful so everything dies, but it hides problems -- why
 aren't the processes closing correctly?

 We shouldn't ever have real data loss on abrupt shutdown (because we
 should never respond about success until data  has written and synced to
 final storage.

 But we do have data loss potential in log messages output. If we SIGKILL
 we may lose debugging output that may be useful.

 If the SIGKILL is still desired, please:

 - don't do the SIGKILL only .1 second after SIGTERM. Wait much longer.
 Even check if children are still alive first and then wait a few seconds.

 - allow option to turn this off. I think that developers should never use
 SIGKILL or we won't fix real exit problems.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1049>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development