blob: e565dfde9a051323c80cecab3622a3df216e5f0e (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
==================
WSGIRestrictSignal
==================
:Description: Enable restrictions on use of signal().
:Syntax: ``WSGIRestrictSignal On|Off``
:Default: ``WSGIRestrictSignal On``
:Context: server config
A well behaved Python WSGI application should not in general register any
signal handlers of its own using ``signal.signal()``. The reason for this
is that the web server which is hosting a WSGI application will more than
likely register signal handlers of its own. If a WSGI application were to
override such signal handlers it could interfere with the operation of the
web server, preventing actions such as server shutdown and restart.
In the interests of promoting portability of WSGI applications, mod_wsgi
restricts use of ``signal.signal()`` and will ensure that any attempts
to register signal handlers are ignored. A warning notice will be output
to the Apache error log indicating that this action has been taken.
If for some reason there is a need for a WSGI application to register some
special signal handler this behaviour can be turned off, however an
application should avoid the signals ``SIGTERM``, ``SIGINT``,
``SIGHUP``, ``SIGWINCH`` and ``SIGUSR1`` as these are all used by
Apache.
Apache will ensure that the signal ``SIGPIPE`` is set to ``SIG_IGN``.
If a WSGI application needs to override this, it must ensure that it is
reset to ``SIG_IGN`` before any Apache code is run. In a multi threaded
MPM this would be practically impossible to ensure so it is preferable that
the handler for ``SIG_PIPE`` also not be changed.
Apache does not use ``SIGALRM``, but it is generally preferable that
other techniques be used to achieve the same affect.
Do note that if enabling the ability to register signal handlers, such a
registration can only reliably be done from within code which is
implemented as a side effect of importing a script file identified by the
WSGIImportScript directive. This is because signal handlers can only be
registered from the main Python interpreter thread, and request handlers
when using embedded mode and a multithreaded Apache MPM would generally
execute from secondary threads. Similarly, when using daemon mode, request
handlers would executed from secondary threads. Only code run as a side
effect of WSGIImportScript is guaranteed to be executed in main Python
interpreter thread.
|
