BIND 10 #1049: bind10 should not resort to SIGKILL
BIND 10 Development
do-not-reply at isc.org
Thu Jun 30 14:10:45 UTC 2011
#1049: bind10 should not resort to SIGKILL
-------------------------------------+-------------------------------------
Reporter: jreed | Owner:
Type: | Status: new
defect | Milestone: Year 3 Task
Priority: major | Backlog
Component: Boss | Resolution:
of BIND | Sensitive: 0
Keywords: | Sub-Project: DNS
Defect Severity: N/A | Estimated Difficulty: 0.0
Feature Depending on Ticket: | Total Hours: 0
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by shane):
* milestone: New Tasks => Year 3 Task Backlog
Comment:
There are two issues here.
First, I agree that a process not exiting with the shutdown message - or
at least SIGTERM - is a bug. I also agree that using SIGKILL masks this.
So we do need a way for developers to disable this.
The second issue is that in real operation the system needs to promptly
shut down, even if there are developer errors. So I argue that for default
operation we need to keep the system "as is".
As for the timing... waiting a few seconds seems insane to me. All of our
tasks need to be able to handle being shut down at any time anyway (we may
get accidental "kill -9" from administrator mistyping process ID, the
Linux out-of-memory handler can shut things down, power cables can be
tripped over, and so on). Having the system take more than a second to
shutdown seems like a defect to me, and there doesn't seem to be any real
need for it.
So I think this ticket has a few work items, both minor:
1. Add a flag to disable SIGKILL on shutdown (or perhaps one to set the
interval before falling back to SIGKILL?)
1. Fix any processes that currently block or catch SIGTERM (besides the
boss)
1. Insure all processes properly handle shutdown requests
--
Ticket URL: <http://bind10.isc.org/ticket/1049#comment:1>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list