问题
Here's the scenario. I have a Django app being served by Gunicorn on Linux. On certain requests it makes an https call to an external API via httplib2.request(). Sometimes that call fails in such a way that hoses OpenSSL (not sure how, but it's not my fault and doesn't really matter). OpenSSL sends a SIGABRT signal to gunicorn in this case. Gunicorn handles the SIGABRT and promptly system exits (as it should).
The root issue as I see it is that OpenSSL asynchronously signals the parent process to abort, rather than returning an error code. Don't tell me to abort because of YOUR personal problems, OpenSSL! Legacy code in action.
Is anyone else thoroughly annoyed by this problem? How would you prevent this from killing your Gunicorn process? It completely bypasses Django exception handling.
Relevant code points:
- OpenSSL sends SIGABRT whenever OpenSSLDie() is called: https://github.com/openssl/openssl/blob/e0fc7961c4fbd27577fb519d9aea2dc788742715/crypto/cryptlib.c#L391
- which comments claim happens whenever there is a fatal error in any cryptographic operation: https://github.com/openssl/openssl/blob/e0fc7961c4fbd27577fb519d9aea2dc788742715/fips/fips.c#L136
- The SIGABRT is handled by gunicorn: https://github.com/benoitc/gunicorn/blob/6eb01409da42a81b7020cd78c52613d8ec868e94/gunicorn/workers/base.py#L173
- which causes gunicorn to sys.exit(1): https://github.com/benoitc/gunicorn/blob/6eb01409da42a81b7020cd78c52613d8ec868e94/gunicorn/workers/base.py#L200
来源：https://stackoverflow.com/questions/25880006/gunicorn-exits-because-https-request-from-django-fails-in-openssl