Skip to content
This repository was archived by the owner on Oct 23, 2023. It is now read-only.
This repository was archived by the owner on Oct 23, 2023. It is now read-only.

Proposal: Log SystemExit in wsgi wrapper #675

@mattrobenolt

Description

@mattrobenolt

When using gunicorn, at least, and a worker times out, gunicorn sends a SIGABRT signal to the worker process. This manifests itself as a SystemExit exception that gets raised in the worker.

When this happens in Django, Django completely ignores SystemExit and lets it re-raise so the process can exit, without ever calling the got_request_exception signal, so in our case, we never see the exception and nobody knows that anything happened since it happily exited without a fuss.

My proposal would be to explicitly catch SystemExit, log, then reraise.

imo this seems like a reasonable thing to do within a middleware. If something is trying to shut down the process while in the middle of the request, probably worth logging.

In gunicorn, this wouldn't log for a normal shutdown, since that sends a SIGTERM instead of SIGABRT.

Would need to be tested against other wsgi runners, specifically uwsgi.

Refs:
https://github.com/django/django/blob/37ea3cb03e80de80380009a7a7939bc48d75abe9/django/core/handlers/base.py#L223-L225
https://github.com/benoitc/gunicorn/blob/e1912db59a2f1df36387dd28bb3515202cc03098/gunicorn/arbiter.py#L443

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions