Comment 1 for bug 717205

<jml> just found out about this issue affecting us: https://bugs.launchpad.net/launchpad/+bug/717205
<exarkun> Unless there's more details, I don't think that's new in 10.2
 You could always have a before shutdown trigger that returns a Deferred that doesn't fire as soon as you'd like
<exarkun> And re-sending a shutdown signal while waiting for that would always do something wacky
<exarkun> But! Certainly it would be nice to do something better.

In my experience with this error, that's exactly the cause.

So the obvious question is: what would “something better” be? Some possibilities:
 * a subsequent SIGTERM/SIGINT forces shutdown to continue without waiting for the unfired Deferred(s).
 * a subsequent SIGTERM/SIGINT just logs a simple warning “SIGFOO received but shutdown already in progress”
 * a subsequent SIGTERM/SIGINT logs a warning and some details about what it is waiting on (ideally identifying the trigger(s) involved and even e.g. the outstanding connections or whatever is involved)
 * provide an API on the reactor that controls whether shutdown-signal-received-during-blocked-shutdown warns, forces shutdown to proceed, or whatever, so that service authors can choose which behaviour they want.

I'm sure there are others. I'm not sure which is best for Launchpad's use case(s), or best in general.

A workaround for Launchpad's cases may be to explicitly override SIGTERM/INT from the before-shutdown trigger we register, but it seems fairly clear to me that Twisted should offer better facilities here. The relevant upstream bug appears to be <http://twistedmatrix.com/trac/ticket/4406>.