[CherryPy] #886: Shutdown failures

[CherryPy]

#886: Shutdown failures
---------------------------------------+------------------------------------
Reporter: malcolm...@gmail.com | Owner: fumanchu
Type: defect | Status: new
Priority: normal | Milestone:
Component: CherryPy code | Keywords:
---------------------------------------+------------------------------------
There are some cases in which cherrypy shutdown behaviour is suboptimal.

- If unexpected exceptions occur during shutdown, the system never stops.
This occurs regularly if, for example, cherrypy is run with its output
piped into rotatelogs; during shutdown, rotatelogs is gone, and attempts
to log cause exceptions. Should this occur, the server sits there
indefinitely, ignoring further KeyboardInterrupts and SIGTERMs, responding
to every request with broken pipe errors, and needs nastiness (SIGKILL,
SIGSEGV etc.) to make it stop.

- Once the server receives a KeyboardInterrupt or SIGTERM, it seems
determined to respond to every request already in a queue; if the
application is both busy and slow, this can introduce an arbitrary
shutdown delay during which, again, further KeyboardInterrupts or SIGTERMs
are ignored, and only waiting it out or being nasty will stop it.

--
Ticket URL: <http://www.cherrypy.org/ticket/886>
CherryPy <http://www.cherrypy.org>
CherryPy - a pythonic, object-oriented HTTP framework

[CherryPy]

#886: Shutdown failures
---------------------------------------+------------------------------------
Reporter: malcolm...@gmail.com | Owner: fumanchu
Type: defect | Status: new

Priority: normal | Milestone: 3.1
Component: CherryPy code | Resolution:
Keywords: |
---------------------------------------+------------------------------------
Changes (by fumanchu):

* milestone: => 3.1

Comment:

I would like a way for shutdown to be clean, even if that takes a while,
and I'd like it to be the default. But perhaps after receiving an initial
!KeyboardInterrupt we can switch to forceful exit on a subsequent one.
Would that solve the issue for you?

[CherryPy]

#886: Shutdown failures
---------------------------------------+------------------------------------
Reporter: malcolm...@gmail.com | Owner: fumanchu
Type: defect | Status: new
Priority: normal | Milestone:

Component: CherryPy code | Resolution:
Keywords: |
---------------------------------------+------------------------------------

Changes (by malcolm...@gmail.com):

* milestone: 3.1 =>

Comment:

Yes, that would do the trick with the second issue; I can plug in a stop
script to our deployment environment to ensure the SIGTERM is sent twice,
and in development I'm sure I can manage to hit Control-C twice.

This would also apply to the second case - it's no biggie if the first
attempt to shutdown fails with broken pipe errors, so long as the second
attempt works - but it would seem like having the shutdown fail at all is
a bug and could be fixed entirely without impacting other use cases.

[CherryPy]

#886: Shutdown failures
---------------------------------------+------------------------------------
Reporter: malcolm...@gmail.com | Owner: fumanchu
Type: defect | Status: new

Priority: normal | Milestone: 3.1

Component: CherryPy code | Resolution:
Keywords: |
---------------------------------------+------------------------------------
Changes (by malcolm...@gmail.com):

* milestone: => 3.1

Comment:

Oops sorry didn't meant to unset the milestone. Not sure what happened
there.

[CherryPy]

#886: Shutdown failures
---------------------------------------+------------------------------------
Reporter: malcolm...@gmail.com | Owner: fumanchu

Type: defect | Status: assigned

Priority: normal | Milestone: 3.1
Component: CherryPy code | Resolution:
Keywords: |
---------------------------------------+------------------------------------

Changes (by fumanchu):

* status: new => assigned

Comment:

Partial fix in [2109]. Bus.exit (which is called from several places in
the code: server threads, atexit handlers, signal handlers, console
control handlers) now calls os._exit(os.EX_SOFTWARE) if an error occurs
during its run. This keeps exit errors from hanging the app indefinitely
due to lingering threads.

[CherryPy]

#886: Shutdown failures
---------------------------------------+------------------------------------
Reporter: malcolm...@gmail.com | Owner: fumanchu

Type: defect | Status: closed
Priority: normal | Milestone: 3.1
Component: CherryPy code | Resolution: fixed

Keywords: |
---------------------------------------+------------------------------------
Changes (by fumanchu):

* resolution: => fixed
* status: assigned => closed