Opened 10 years ago

Closed 8 years ago

#123 closed enhancement (complete)

'stopping' messages and 'alive' channel

Reported by: jelte Owned by: UnAssigned
Priority: medium Milestone:
Component: ~Inter-module communication(obsolete) Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: 0.0 Add Hours to Ticket:
Total Hours: Internal?: no


Currently, modules notify the configmanager that they are running by sending their specifications to it. However, there is no notification if modules stop running. There is also no way to query which modules are currently running. Therefore we need two additions;

  1. Automatically send an 'i am stopping' message to the ConfigManager? channel when modules quit correctly.
  1. Add a channel 'alive', where all modules listen on, and respond to when queried.

(this ticket handles featurebacklog items 34 and 36)


Change History (11)

comment:1 Changed 10 years ago by zhanglikun

Ticket #99 relies on this one, so when somebody fix this ticket, please let the owner(that's me) of ticket #99 know it.

comment:2 Changed 9 years ago by stephen

  • billable set to 0
  • Estimated Difficulty set to 0.0
  • Internal? unset

The Boss process needs to receive these messages as it restarts all processes when they die, even when shutdown of the process has been requested via bindctl (e.g. a shutdown of xfrin via the command "Xfrin shutdown").

comment:3 Changed 9 years ago by jelte

I wonder about that; in the end I'd prefer that whether or not subprocess should be running is a boss option; i.e. to stop running MyMod?, you tell Boss that, not MyMod? directly (though this involves giving bob a list of modules to run, and that will involve having some form of dependencies)

Kind of related, I'd love to see a 'don't restart anything ever' option/argument for :)

comment:4 Changed 9 years ago by zhanglikun

For me, I would like to add the option to shutdown command, like "xfrin shutdown restart=False", then boss will not restart it.

comment:5 Changed 9 years ago by stephen

(though this involves giving bob a list of modules to run, and that will involve having
some form of dependencies)

Bob already has a list of modules to run, it's hard-coded into it.

From the discussion here, how about the following:

  1. Boss should start up the critial modules (message queue, configuration manager) then read the other modules it should start from the configuration database.
  2. Each module should have the following attributes:
    • Whether it should be run when BIND10 starts.
    • Whether it should be automatically restarted if it dies.
    • List of modules that must be running before this one can start.
  3. Boss controls the starting and stopping of processes.

The last means that regardless of the settings of the options, a command such as "Xfrin shutdown" can be taken as an instruction not to restart the program (in this case Xfrin) when it shuts down. It also suggests that we need to think about adding the commands "start" and "restart" to give additional process control.

comment:6 Changed 9 years ago by jelte

We appear to have a fundamental disagreement here :)

I think that whether or not a module should be running (i.e. started, restarted, or stopped), is a property of boss, not the module itself.

Taking that as a base, I think that the configuration and user-visible commands should also be for boss; i.e. we should remove the shutdown commands in modules (or rather, make them internal only), skipping one important detail for now, that would mean:

  • Boss has a list of modules that should be running (hardcoded at this moment)
  • Boss starts and restarts all modules in that list
  • By changing that list, you can stop modules

Additionally, for more runtime control, we add the following direct Boss commands:
Boss restart <module>, stop the module, and restart it
Boss start <module>, start the module, and restart it if it fails
Boss stop <module>, stop the module, but do not restart it
(these last two could either have the effect of updating the config list, or only run this during the current run of the boss process)

The detail I'm ignoring here is inter-module dependencies, which boss should have no knowledge of, and which may depend on specific module configuration. I have some diverging ideas on how to get to that, but none fully formed yet.

Chair-throwing may commence.

comment:7 Changed 9 years ago by jelte

  • Owner changed from jelte to UnAssigned
  • Status changed from new to assigned

comment:8 Changed 9 years ago by shane

  • Defect Severity set to N/A
  • Sub-Project set to DNS

Ticket #213 is being used to collect this and related issues.

comment:9 Changed 9 years ago by shane

  • Sub-Project changed from DNS to Core

comment:10 Changed 8 years ago by jelte

BTW, part of this was needed to fix ticket #640, so item 1 of this ticket has been implemented now.

comment:11 Changed 8 years ago by shane

  • Resolution set to complete
  • Status changed from assigned to closed

This ticket seems to have been addressed in the recent boss reconfigurability work. Closing.

Note: See TracTickets for help on using tickets.