Opened 8 years ago

#6011 enhancement new

Make MultiService help out with debugging applications that won't shut down

Reported by: Jean-Paul Calderone Owned by:
Priority: normal Milestone:
Component: core Keywords:
Cc: Branch:
Author:

Description

IService.stopService can return a Deferred which will be waited upon before an application (and thus the reactor, and probably the process) is stopped/exited. Sometimes a bug causes one of these deferreds not to fire, or at least not to fire in a timely manner. If an application consists of a single IService implementation, then it's not hard to figure out the culprit. However, MultiService means there may be many IService implementations, and any one of them can delay shutdown.

MultiService should come with a tool or two to help debug this scenario. At a very basic level, this could just be a __repr__ which shows the state of the MultiService (not running, running, stopping, not running) and the states of its child services. Take this crude example:

<MultiService state=stopping children=[SomeService (not running), Another Service (stopping)]>

Printing out this MultiService makes it obvious that Another Service is the cause of the delay.

An additional question might be how to make it easy to get to see this information. Most applications don't include a convenient hook for causing their top-level IService implementation to get printed anywhere.

It might be a good idea to finally implement the subsequent Control-C behavior that has been discussed (probably for ten years now). A first Control-C initiates shutdown. Presently, a second Control-C tries to re-initiate shutdown which is mostly bogus. Instead, it could display this debug information about MultiService (perhaps via a new interface on the application object). Further Control-C keystrokes (should I say SIGINT signals instead? Perhaps.) might cancel the Deferred returned from stopService and then exit the process uncleanly.

This is likely more than a single ticket's worth of work. Perhaps some of the other tickets would make sense to complete before the MultiService debug information feature would actually be practically usable. The features don't seem terribly dependent on each other, though, and would probably also be useful independently.

Change History (0)

Note: See TracTickets for help on using tickets.