BIND 10 #2799: stats lost Auth stats after removing some b10-auth components
BIND 10 Development
do-not-reply at isc.org
Fri Mar 15 09:02:49 UTC 2013
#2799: stats lost Auth stats after removing some b10-auth components
-------------------------------------+-------------------------------------
Reporter: jreed | Owner:
Type: defect | Status: new
Priority: medium | Milestone:
Component: statistics | StatsRedesign
Keywords: | Resolution:
Sensitive: 0 | CVSS Scoring:
Sub-Project: DNS | Defect Severity:
Estimated Difficulty: 7 | Medium
Total Hours: 0 | Feature Depending on Ticket:
| Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Comment (by naokikambe):
I realized almost the reason of this problem. When one of the multiple
auth processes receives `shutdown` command, it sends the `stopping`
message to !ConfigManager.
{{{
2013-03-15 17:34:45.230 DEBUG [b10-auth.cc/14779] CC_GROUP_SEND sending
message '{ "command": [ "stopping", { "module_name": "Auth" } ] }' to
group 'ConfigManager'
}}}
But after that !ConfigManager removes all auth information from its
internal data, and it no longer manage auth information even though other
auth processes are running. Also it tells Cmdctl the module which it has
removed isn't running. That's why `bindctl` didn't recognize an auth's
command as the above. I suspect this part of `cfgmgr.py` is here.
{{{#!python
def __handle_module_stopping(self, arg):
"""Private function that handles a 'stopping' command;
The argument is of the form { 'module_name': <name> }.
If the module is known, it is removed from the known list,
and a message is sent to the Cmdctl channel to remove it as
well.
If it is unknown, the message is ignored."""
if arg['module_name'] in self.module_specs:
del self.module_specs[arg['module_name']]
self._send_module_spec_to_cmdctl(arg['module_name'], None)
# This command is not expected to be answered
return None
}}}
Stats manages information of modules based on data from !ConfigManager. So
it ignores the module which !ConfigManager doesn't have. I think
!ConfigManager should check whether other processes of the module which it
tries to remove are running or not before removing.
--
Ticket URL: <http://bind10.isc.org/ticket/2799#comment:4>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list