EVOLUTION-MANAGER

Edit File: WSGIDaemonProcess.html

<!DOCTYPE html>

 <html class="no-js" lang="en" > 
<head>
 <meta charset="utf-8">
 
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 
 <title>WSGIDaemonProcess &mdash; mod_wsgi 4.7.1 documentation</title>

</head>

<a href="../index.html" class="icon icon-home"> mod_wsgi

</a>

</div>

<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
 
 
 
 
 
 
 <ul class="current">
<li class="toctree-l1"><a class="reference internal" href="../project-status.html">Project Status</a></li>
<li class="toctree-l1"><a class="reference internal" href="../security-issues.html">Security Issues</a></li>
<li class="toctree-l1"><a class="reference internal" href="../getting-started.html">Getting Started</a></li>
<li class="toctree-l1"><a class="reference internal" href="../requirements.html">Requirements</a></li>
<li class="toctree-l1"><a class="reference internal" href="../installation.html">Installation</a></li>
<li class="toctree-l1"><a class="reference internal" href="../troubleshooting.html">Troubleshooting</a></li>
<li class="toctree-l1"><a class="reference internal" href="../user-guides.html">User Guides</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="../configuration.html">Configuration</a><ul class="current">
<li class="toctree-l2"><a class="reference internal" href="WSGIAcceptMutex.html">WSGIAcceptMutex</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIAccessScript.html">WSGIAccessScript</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIApplicationGroup.html">WSGIApplicationGroup</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIAuthGroupScript.html">WSGIAuthGroupScript</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIAuthUserScript.html">WSGIAuthUserScript</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGICallableObject.html">WSGICallableObject</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGICaseSensitivity.html">WSGICaseSensitivity</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIChunkedRequest.html">WSGIChunkedRequest</a></li>
<li class="toctree-l2 current"><a class="current reference internal" href="">WSGIDaemonProcess</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIImportScript.html">WSGIImportScript</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGILazyInitialization.html">WSGILazyInitialization</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIPassAuthorization.html">WSGIPassAuthorization</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIProcessGroup.html">WSGIProcessGroup</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIPythonEggs.html">WSGIPythonEggs</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIPythonHome.html">WSGIPythonHome</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIPythonOptimize.html">WSGIPythonOptimize</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIPythonPath.html">WSGIPythonPath</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIRestrictEmbedded.html">WSGIRestrictEmbedded</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIRestrictProcess.html">WSGIRestrictProcess</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIRestrictSignal.html">WSGIRestrictSignal</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIRestrictStdin.html">WSGIRestrictStdin</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIRestrictStdout.html">WSGIRestrictStdout</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIScriptAlias.html">WSGIScriptAlias</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIScriptAliasMatch.html">WSGIScriptAliasMatch</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGIScriptReloading.html">WSGIScriptReloading</a></li>
<li class="toctree-l2"><a class="reference internal" href="WSGISocketPrefix.html">WSGISocketPrefix</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="../finding-help.html">Finding Help</a></li>
<li class="toctree-l1"><a class="reference internal" href="../reporting-bugs.html">Reporting Bugs</a></li>
<li class="toctree-l1"><a class="reference internal" href="../contributing.html">Contributing</a></li>
<li class="toctree-l1"><a class="reference internal" href="../source-code.html">Source Code</a></li>
<li class="toctree-l1"><a class="reference internal" href="../release-notes.html">Release Notes</a></li>
</ul>

</div>
 </div>
 </nav>

<ul class="wy-breadcrumbs">
 
 <li><a href="../index.html">Docs</a> &raquo;</li>
 
 <li><a href="../configuration.html">Configuration</a> &raquo;</li>
 
 <li>WSGIDaemonProcess</li>
 
 
 <li class="wy-breadcrumbs-aside">
 
 
 <a href="../_sources/configuration-directives/WSGIDaemonProcess.txt" rel="nofollow"> View page source</a>
 
 
 </li>
 
 </ul>

<hr/>
</div>
 <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
 <div itemprop="articleBody">
 
 <div class="section" id="wsgidaemonprocess">
<h1>WSGIDaemonProcess<a class="headerlink" href="#wsgidaemonprocess" title="Permalink to this headline">¶</a></h1>
<table class="docutils field-list" frame="void" rules="none">
<col class="field-name" />
<col class="field-body" />
<tbody valign="top">
<tr class="field-odd field"><th class="field-name">Description:</th><td class="field-body">Configure a distinct daemon process for running applications.</td>
</tr>
<tr class="field-even field"><th class="field-name">Syntax:</th><td class="field-body"><tt class="docutils literal">WSGIDaemonProcess</tt> name <tt class="docutils literal">[</tt> options <tt class="docutils literal">]</tt></td>
</tr>
<tr class="field-odd field"><th class="field-name">Context:</th><td class="field-body">server config, virtual host</td>
</tr>
</tbody>
</table>
The <tt class="docutils literal">WSGIDaemonProcess</tt> directive can be used to specify that distinct
daemon processes should be created to which the running of WSGI
applications can be delegated. Where Apache has been started as the
<tt class="docutils literal">root</tt> user, the daemon processes can be run as a user different to that
which the Apache child processes would normally be run as.
When distinct daemon processes are enabled and used, the process is
dedicated to mod_wsgi and the only thing that the processes do is run the
WSGI applications assigned to that process group. Any other Apache modules
such as PHP or activities such as serving up static files continue to be
run in the standard Apache child processes.
Note that having denoted that daemon processes should be created by
using the <tt class="docutils literal">WSGIDaemonProcess</tt> directive, the <tt class="docutils literal">WSGIProcessGroup</tt>
directive, or the <tt class="docutils literal">process-group</tt> option of <tt class="docutils literal">WSGIScriptAlias</tt> still
needs to be used to delegate specific WSGI applications to execute within
those daemon processes.
Also note that the name of the daemon process group must be unique for the
whole server. That is, it is not possible to use the same daemon process
group name in different virtual hosts.
Options which can be supplied to the <tt class="docutils literal">WSGIDaemonProcess</tt> directive are:
<dl class="docutils">
<dt>processes=num</dt>
<dd>Defines the number of daemon processes that should be started in this
process group. If not defined then only one process will be run in this
process group.
Note that if this option is defined as <tt class="docutils literal">processes=1</tt>, then the WSGI
environment attribute called <tt class="docutils literal">wsgi.multiprocess</tt> will be set to be
<tt class="docutils literal">True</tt> whereas not providing the option at all will result in the
attribute being set to be <tt class="docutils literal">False</tt>. This distinction is to allow for
where some form of load balancing is used across process groups in the
same Apache instance, or separate Apache instances. If you need to
ensure that <tt class="docutils literal">wsgi.multiprocess</tt> is <tt class="docutils literal">False</tt> so that interactive
debuggers will work, simply do not specify the <tt class="docutils literal">processes</tt> option and
allow the default single daemon process to be created in the process
group.
</dd>
<dt>threads=num</dt>
<dd>Defines the number of threads to be created to handle requests in each
daemon process within the process group.
If this option is not defined then the default will be to create 15
threads in each daemon process within the process group.
Do not get carried away and set this to a very large number in the
belief that it will somehow magically enable you to handle many more
concurrent users. Any sort of increased value would only be appropriate
where your code is I/O bound. If you code is CPU bound, you are better
of using at most 3 to 5 threads per process and using more processes.
If you set the number of threads to 0 you will enable a special mode
intended for using a daemon process to run a managed set of processes.
You will need to use <tt class="docutils literal">WSGIImportScript</tt> to pre-load a Python script
into the main application group specified by <tt class="docutils literal">%{GLOBAL}</tt> where the
script runs a never ending task, or does an exec to run an external
program. If the script or external program exits, the process is
shutdown and replaced with a new one. For the case of using a Python
script to run a never ending task, a <tt class="docutils literal">SystemExit</tt> exception will be
injected when a signal is received to shutdown the process. You can
use <tt class="docutils literal">signal.signal()</tt> to register a signal handler for <tt class="docutils literal">SIGTERM</tt>
if needing to run special actions before then exiting the process using
<tt class="docutils literal">sys.exit()</tt>, or to signal your own threads to exit any processing
so you can shutdown in an orderly manner.
</dd>
<dt>display-name=value</dt>
<dd>Defines a different name to show for the daemon process when using the
<tt class="docutils literal">ps</tt> command to list processes. If the value is <tt class="docutils literal">%{GROUP}</tt> then the
name will be <tt class="docutils literal">(wsgi:group)</tt> where <tt class="docutils literal">group</tt> is replaced with the name
of the daemon process group.
Note that only as many characters of the supplied value can be displayed
as were originally taken up by <tt class="docutils literal">argv0</tt> of the executing process.
Anything in excess of this will be truncated.
This feature may not work as described on all platforms. Typically it
also requires a <tt class="docutils literal">ps</tt> program with BSD heritage. Thus on some versions
of Solaris UNIX the <tt class="docutils literal">/usr/bin/ps</tt> program doesn&#8217;t work, but
<tt class="docutils literal">/usr/ucb/ps</tt> does. Other programs which can display this value
include <tt class="docutils literal">htop</tt>.
</dd>
<dt>home=directory</dt>
<dd>Defines an absolute path of a directory which should be used as the
initial current working directory of the daemon processes within the
process group.
If this option is not defined the initial current working directory
will be set to be the home directory of the user that the daemon
process is configured to run as using the <tt class="docutils literal">user</tt> option to the
<tt class="docutils literal">WSGIDaemonProcess</tt> directive. Otherwise the current working
directory of Apache when started will be used, which if Apache is being
started from system init scripts, would usually be the system root
directory.
</dd>
<dt>user=name | user=#uid</dt>
<dd>Defines the UNIX user name or numeric user uid of the user that
the daemon processes should be run as. If this option is not supplied
the daemon processes will be run as the same user that Apache would
run child processes, as defined by the <a class="reference external" href="http://httpd.apache.org/docs/2.4/mod/mod_unixd.html#user">User</a> directive, and it is
not necessary to set this to the Apache user yourself.
Note that this option is ignored if Apache wasn&#8217;t started as the root
user, in which case no matter what the settings, the daemon processes
will be run as the user that Apache was started as.
Also be aware that mod_wsgi will not allow you to run a daemon process
group as the root user due to the security risk of running a web
application as root.
</dd>
<dt>group=name | group=#gid</dt>
<dd>Defines the UNIX group name or numeric group gid of the primary
group that the daemon processes should be run as. If this option is not
supplied the daemon processes will be run as the same group that Apache
would run child processes, as defined by the <a class="reference external" href="http://httpd.apache.org/docs/2.4/mod/mod_unixd.html#group">Group</a> directive, and it
is not necessary to set this to the Apache group yourself.
Note that this option is ignored if Apache wasn&#8217;t started as the root
user, in which case no matter what the settings, the daemon processes
will be run as the group that Apache was started as.
</dd>
<dt>supplementary-groups=group1 | supplementary-groups=group1,group2</dt>
<dd>Defines a list of additional UNIX groups that the user the daemon
process group runs as, should be added to, in addition to primary
UNIX group associated with that user. When specifying more than one
group, separate the names of the groups with a comma.</dd>
<dt>umask=0nnn</dt>
<dd>Defines a value to be used for the umask of the daemon processes within
the process group. The value must be provided as an octal number.
If this option is not defined then the umask of the user that Apache is
initially started as will be inherited by the process. Typically the
inherited umask would be &#8216;0022&#8217;.
</dd>
<dt>lang=locale</dt>
<dd>Set the current language locale. This is the same as having set the
<tt class="docutils literal">LANG</tt> environment variable.
You will need to set this on many Linux systems where Apache when
started up from system init scripts uses the default C locale, meaning
that the default system encoding is ASCII. Unless you need a special
language locale, set this to <tt class="docutils literal">en_US.UTF-8</tt>.
Whether the <tt class="docutils literal">lang</tt> or <tt class="docutils literal">locale</tt> option works best can depend on the
system being used. Set both if you aren&#8217;t sure which is appropriate.
</dd>
<dt>locale=locale</dt>
<dd>Set the current language locale. This is the same as having set the
<tt class="docutils literal">LC_ALL</tt> environment variable.
You will need to set this on many Linux systems where Apache when
started up from system init scripts uses the default C locale, meaning
that the default system encoding is ASCII. Unless you need a special
language locale, set this to <tt class="docutils literal">en_US.UTF-8</tt>.
Whether the <tt class="docutils literal">lang</tt> or <tt class="docutils literal">locale</tt> option works best can depend on the
system being used. Set both if you aren&#8217;t sure which is appropriate.
</dd>
<dt>chroot=directory</dt>
<dd>Run the daemon process group process within a chroot jail. Use of a
chroot jail is now deprecated due to the difficulty in setting up a
chroot environment. It is recommended that you use more modern
containerisation technologies such as Docker or runC.</dd>
<dt>script-user=name | script-user=#uid</dt>
<dd>Sets the user that must be the owner of any WSGI script file delegated
to be run in the daemon process group. If the owner doesn&#8217;t match a
HTTP Forbidden response will be returned for any request.
Note that this doesn&#8217;t change what user the daemon process group runs
as at any time. If you want to set the user that the daemon process
group runs as, use the <tt class="docutils literal">user</tt> option.
Only one of <tt class="docutils literal">script-user</tt> or <tt class="docutils literal">script-group</tt> option can be used at
the same time.
</dd>
<dt>script-group=name | script-group=#gid</dt>
<dd>Sets the group that must be the group of any WSGI script file delegated
to be run in the daemon process group. If the group doesn&#8217;t match a
HTTP Forbidden response will be returned for any request.
Note that this doesn&#8217;t change what group the daemon process group runs
as at any time. If you want to set the group that the daemon process
group runs as, use the <tt class="docutils literal">group</tt> option.
Only one of <tt class="docutils literal">script-user</tt> or <tt class="docutils literal">script-group</tt> option can be used at
the same time.
</dd>
<dt>python-home=directory</dt>
<dd>Set the location of the Python virtual environment to be used by the
daemon processes. The directory to use is that which <tt class="docutils literal">sys.prefix</tt> is
set to for the Python virtual environment. The virtual environment can
have been created by <tt class="docutils literal">virtualenv</tt>, <tt class="docutils literal">pyvenv</tt> or <tt class="docutils literal">python -m venv</tt>.
Note that the Python virtual environment must have been created using
the same base Python version as was used to compile the mod_wsgi
module. You can&#8217;t use this to force mod_wsgi to somehow use a different
Python version than it was compiled for. If you want to use a different
version of Python, you will need to reinstall mod_wsgi, compiling it
for the version you want. It is not possible for the one mod_wsgi
instance to run applications for both Python 2 and 3 at the same time.
</dd>
<dt>python-path=directory | python-path=directory:directory</dt>
<dd>List of colon separated directories to add to the Python module search
path, ie., <tt class="docutils literal">sys.path</tt>.
Note that this is not strictly the same as having set the <tt class="docutils literal">PYTHONPATH</tt>
environment variable when running normal command line Python. When this
option is used, the directories are added by calling
<tt class="docutils literal">site.addsitedir()</tt>. As well as adding the directory to
<tt class="docutils literal">sys.path</tt> this function has the effect of opening and interpreting
any <tt class="docutils literal">.pth</tt> files located in the specified directories.
If using a Python virtual environment, rather than use this option to
refer to the <tt class="docutils literal">site-packages</tt> directory of the Python virtual
environment, you should use the <tt class="docutils literal">python-home</tt> option to specify the
root of the Python virtual environment instead.
In all cases, if the directory contains Python packages which have C
extension components, those packages must have been installed using the
same base Python version as was used to compile the mod_wsgi module.
You should not mix packages from different Python versions or
installations.
</dd>
<dt>python-eggs=directory</dt>
<dd>Directory to be used as the Python egg cache directory. This is
equivalent to having set the <tt class="docutils literal">PYTHON_EGG_CACHE</tt> environment
variable.
Note that the directory specified must exist and be writable by the
user that the daemon process run as.
</dd>
<dt>restart-interval=sss</dt>
<dd>Defines a time limit in seconds for how long a daemon process should
run before being restarted.
This might be use to periodically force restart the WSGI application
processes when you have issues related to Python object reference count
cycles, or incorrect use of in memory caching, which causes constant
memory growth.
If this option is not defined, or is defined to be 0, then the daemon
process will be persistent and will continue to service requests until
Apache itself is restarted or shutdown.
Avoid setting this too low. This is because the constant restarting and
reloading of your WSGI application may cause unecessary load on your
system and affect performance.
You can use the <tt class="docutils literal">graceful-timeout</tt> option in conjunction with this
option to reduce the chances that an active request will be interrupted
when a restart occurs due to the use of this option.
</dd>
<dt>maximum-requests=nnn</dt>
<dd>Defines a limit on the number of requests a daemon process should
process before it is shutdown and restarted.
This might be use to periodically force restart the WSGI application
processes when you have issues related to Python object reference count
cycles, or incorrect use of in memory caching, which causes constant
memory growth.
If this option is not defined, or is defined to be 0, then the daemon
process will be persistent and will continue to service requests until
Apache itself is restarted or shutdown.
Avoid setting this to a low number of requests on a site which handles
a lot of traffic. This is because the constant restarting and reloading
of your WSGI application may cause unecessary load on your system and
affect performance. Only use this option if you have no other choice
due to a memory usage issue. Stop using it as soon as any memory issue
has been resolved.
You can use the <tt class="docutils literal">graceful-timeout</tt> option in conjunction with this
option to reduce the chances that an active request will be interrupted
when a restart occurs due to the use of this option.
</dd>
<dt>inactivity-timeout=sss</dt>
<dd>Defines the maximum number of seconds allowed to pass before the
daemon process is shutdown and restarted when the daemon process has
entered an idle state. For the purposes of this option, being idle
means there are no currently active requests and no new requests are
being received.
This option exists to allow infrequently used applications running in
a daemon process to be restarted, thus allowing memory being used to
be reclaimed, with process size dropping back to the initial startup
size before any application had been loaded or requests processed.
Note that after any restart of the WSGI application process, the WSGI
application will need to be reloaded. This can mean that the first
request received by a process after the process was restarted can be
slower. If you WSGI application has a very high startup cost on CPU and
time, it may not be a good idea to use the option.
See also the <tt class="docutils literal">request-timeout</tt> option for forcing a process restart
when requests block for a specified period of time.
Note that similar functionality to that of the <tt class="docutils literal">request-timeout</tt>
option, for forcing a restart when requests blocked, was part of what
was implemented by the <tt class="docutils literal">inactivity-timeout</tt> option. The request
timeout was broken out into a separate feature in version 4.1.0 of
mod_wsgi.
</dd>
<dt>request-timeout=sss</dt>
<dd>Defines the maximum number of seconds that a request is allowed to run
before the daemon process is restarted. This can be used to recover
from a scenario where a request blocks indefinitely, and where if all
request threads were consumed in this way, would result in the whole
WSGI application process being blocked.
How this option is seen to behave is different depending on whether a
daemon process uses only one thread, or more than one thread for
handling requests, as set by the <tt class="docutils literal">threads</tt> option.
If there is only a single thread, and so the process can only handle
one request at a time, as soon as the timeout has passed, a restart of
the process will be initiated.
If there is more than one thread, the request timeout is applied to
the average running time for any requests, across all threads. This
means that a request can run longer than the request timeout. This is
done to reduce the possibility of interupting other running requests,
and causing a user to see a failure. So where there is still capacity
to handle more requests, restarting of the process will be delayed
if possible.
</dd>
<dt>deadlock-timeout=sss</dt>
<dd>Defines the maximum number of seconds allowed to pass before the
daemon process is shutdown and restarted after a potential deadlock on
the Python GIL has been detected. The default is 300 seconds.
This option exists to combat the problem of a daemon process freezing
as the result of a rogue Python C extension module which doesn&#8217;t
properly release the Python GIL when entering into a blocking or long
running operation.
</dd>
<dt>startup-timeout=sss</dt>
<dd>Defines the maximum number of seconds allowed to pass waiting to see if
a WSGI script file can be loaded successfully by a daemon process. When
the timeout is passed, the process will be restarted.
This can be used to force the reloading of a process when a transient
issue occurs on the first attempt to load the WSGI script file, but
subsequent attempts still fail because a Python package that was loaded
has retained state that prevents attempts to run initialisation a
second time within the same process. The Django package can cause this
scenario as the initialisation of Django itself can no longer be
attempted more than once in the same process.
</dd>
<dt>graceful-timeout=sss</dt>
<dd>When <tt class="docutils literal">maximum-requests</tt> is used and the maximum has been reached,
or <tt class="docutils literal">cpu-time-limit</tt> is used and the CPU limit reached, or
<tt class="docutils literal">restart-interval</tt> is used and the time limit reached, if
<tt class="docutils literal">graceful-timeout</tt> is set, then the process will continue to run for
the number of second specified by this option, while still accepting
new requests, to see if the process reaches an idle state. If the
process reaches an idle state, it will then be resarted immediately. If
the process doesn&#8217;t reach an idle state and the graceful restart
timeout expires, the process will be restarted, even if it means that
requests may be interrupted.</dd>
<dt>eviction-timeout=sss</dt>
<dd>When a daemon process is sent the graceful restart signal, usually
<tt class="docutils literal">SIGUSR1</tt>, to restart a process, this timeout controls how many
seconds the process will wait, while still accepting new requests,
before it reaches an idle state with no active requests and shutdown.
If this timeout is not specified, then the value of the
<tt class="docutils literal">graceful-timeout</tt> will instead be used. If the <tt class="docutils literal">graceful-timeout</tt>
is not specified, then the restart when sent the graceful restart
signal will instead happen immediately, with the process being forcibly
killed, if necessary, when the shutdown timeout has expired.
</dd>
<dt>shutdown-timeout=sss</dt>
<dd>Defines the maximum number of seconds allowed to pass when waiting for
a daemon process to shutdown. When this timeout has been reached the
daemon process will be forced to exited even if there are still active
requests or it is still running Python exit functions. The shutdown
timeout is applied after any graceful restart timeout or eviction
timeout if they have been specified. No new requests are accepted
during the shutdown timeout is being applied.
If this option is not defined, then the shutdown timeout will be set
to 5 seconds. Note that this option does not change the shutdown
timeout applied to daemon processes when Apache itself is being stopped
or restarted. That timeout value is defined internally to Apache as 3
seconds and cannot be overridden.
</dd>
<dt>connect-timeout=sss</dt>
<dd>Defines the maximum amount of time for an Apache child process to wait
trying to get a successful connection to the mod_wsgi daemon processes.
This defaults to 15 seconds.</dd>
<dt>socket-timeout=sss</dt>
<dd>Defines the timeout on individual reads/writes on the socket connection
between the Apache child processes and the mod_wsgi daemon processes.
If this is not specified, the number of seconds specified by the
Apache <a class="reference external" href="http://httpd.apache.org/docs/2.4/mod/core.html#timeout">Timeout</a> directive will be used instead.</dd>
<dt>queue-timeout=sss</dt>
<dd>Defines the timeout on how long to wait for a mod_wsgi daemon process
to accept a request for processing.
This option is to allow one to control what to do when backlogging of
requests occurs. If the daemon process is overloaded and getting
behind, then it is more than likely that a user will have given up on
the request anyway if they have to wait too long. This option allows
you to specify that a request that was queued up waiting for too long
is discarded, allowing any transient backlog to be quickly discarded
and not simply cause the daemon process to become even more backlogged.
When this occurs the user will recieve a 504 Gateway Time Out response.
</dd>
<dt>listen-backlog=nnn</dt>
<dd>Defines the depth of the daemon process socket listener queue. By
default the limit is 100, although this is actually a hint, as
different operating systems can have different limits on the maximum
value or otherwise treat it in special ways.a
This option can be set, along with <tt class="docutils literal">queue-timeout</tt> to try and better
handle back logging when the WGSI application gets overloaded.
</dd>
<dt>socket-user=name | socket-user=#uid</dt>
<dd>Set the owner of the UNIX listener socket for the daemon process group.
This can be used when using the Apache <a class="reference external" href="https://httpd.apache.org/docs/2.4/mod/mod_privileges.html#privilegesmode">PrivilegesMode</a> directive with
value of <tt class="docutils literal">SECURE</tt> to change the owner of the socket from the default
Apache user, to the user under which the Apache child process which is
attempting to connect to the daemon process group, will run when
handling requests. This is necessary otherwise the Apache child worker
process will not be able to connect to the listener socket for the
mod_wsgi daemon process to proxy the request to the WSGI application.
This option can also be used when using third party Apache modules such
as mod_ruid, mod_ruid2, mod_suid as well as the ITK MPM for Apache.
</dd>
<dt>cpu-time-limit=sss</dt>
<dd>Define the maximum amount of CPU time a daemon process is allowed to
consume before a shutdown is triggered and the daemon process
restarted. The point of this is to provide some means of controlling
potentially run away processes due to bad code that gets stuck in heavy
processing loops.
Note that CPU time used is recorded from when the daemon process is
first created. This means that a process will eventually reach the
limit in normal use and would be restarted. You can use the
<tt class="docutils literal">graceful-timeout</tt> option to reduce the chances that an active
request will be interrupted.
</dd>
<dt>cpu-priority=num</dt>
<dd>Sets the scheduling priority set to the daemon processes. This can be
a number of the range -20 to 20. The default priority is 0. A lower
priority gives more favourable scheduling.</dd>
<dt>memory-limit=num</dt>
<dd>Sets the maximum amount of memory a daemon process can use. This will
have no affect on some platforms as <tt class="docutils literal">RLIMIT_AS</tt>/<tt class="docutils literal">RLIMIT_DATA</tt> with
<tt class="docutils literal">setrlimit()</tt> isn&#8217;t always implemented. For example MacOS X and older
Linux kernel versions do not implement this feature. You will need to
test whether this feature works or not before depending on it.</dd>
<dt>virtual-memory-limit=num</dt>
<dd>Sets the maximum amount of virtual memory a daemon process can use.
This will have no affect on some platforms as <tt class="docutils literal">RLIMIT_VMEM</tt> with
<tt class="docutils literal">setrlimit()</tt> isn&#8217;t always implemented. You will need to test whether
this feature works or not before depending on it.</dd>
<dt>stack-size=nnn</dt>
<dd>The amount of virtual memory in bytes to be allocated for the stack
corresponding to each thread created by mod_wsgi in a daemon process.
This option would be used when running Linux in a VPS system which has
been configured with a quite low &#8216;Memory Limit&#8217; in relation to the
&#8216;Context RSS&#8217; and &#8216;Max RSS Memory&#8217; limits. In particular, the default
stack size for threads under Linux is 8MB is quite excessive and could
for such a VPS result in the &#8216;Memory Limit&#8217; being exceeded before the
RSS limits were exceeded. In this situation, the stack size should be
dropped down to be in the region of 512KB (524288 bytes).
</dd>
<dt>receive-buffer-size=nnn</dt>
<dd>Defines the UNIX socket buffer size for data being received by the
daemon process from the Apache child process.
This option may need to be used to override small default values set by
certain operating systems and would help avoid possibility of deadlock
between Apache child process and daemon process when the WSGI
application generates large responses but doesn&#8217;t consume request
content. In general such deadlock problems would not arise with well
behaved WSGI applications, but some spam bots attempting to post data
to web sites are known to trigger the problem.
The maximum possible value that can be set for the buffer size is
operating system dependent and will need to be calculated through trial
and error.
</dd>
<dt>send-buffer-size=nnn</dt>
<dd>Defines the UNIX socket buffer size for data being sent in the
direction daemon process back to Apache child process.
This option may need to be used to override small default values set by
certain operating systems and would help avoid possibility of deadlock
between Apache child process and daemon process when the WSGI
application generates large responses but doesn&#8217;t consume request
content. In general such deadlock problems would not arise with well
behaved WSGI applications, but some spam bots attempting to post data
to web sites are known to trigger the problem.
The maximum possible value that can be set for the buffer size is
operating system dependent and will need to be calculated through trial
and error.
</dd>
<dt>header-buffer-size=nnn</dt>
<dd>Defines the maximum size that a response header/value can be that is
returned from a WSGI application. The default size is 32768 bytes. This
might need to be overridden where excessively large response headers
are returned, such as in custom authentication challenge schemes which
use the <tt class="docutils literal">WWW-Authenticate</tt> header.</dd>
<dt>response-buffer-size=nnn</dt>
<dd>Defines the maximum number of bytes that will be buffered for a
response in the Apache child processes when proxying the response body
from the WSGI application. The default size is 65536 bytes. Be careful
increasing this to provide extra buffering of responses as it
contributes to the runtime memory size of the Apache child processes.</dd>
<dt>response-socket-timeout=nnn</dt>
<dd>Defines the maximum number of seconds allowed to pass before timing out
on a write operation back to the HTTP client when the response buffer
has filled and data is being forcibly flushed. Defaults to 0 seconds
indicating that it will default to the value of the <tt class="docutils literal">socket-timeout</tt>
option.</dd>
</dl>
To delegate a particular WSGI application to run in a named set of daemon
processes, the <tt class="docutils literal">WSGIProcessGroup</tt> directive should be specified in
appropriate context for that application, or the <tt class="docutils literal">process-group</tt> option
used on the <tt class="docutils literal">WSGIScriptAlias</tt> directive. If neither is used to delegate
the WSGI application to run in a daemon process group, the application will
be run within the standard Apache child processes.
If the <tt class="docutils literal">WSGIDaemonProcess</tt> directive is specified outside of all virtual
host containers, any WSGI application can be delegated to be run within
that daemon process group. If the <tt class="docutils literal">WSGIDaemonProcess</tt> directive is
specified within a virtual host container, only WSGI applications
associated with virtual hosts with the same server name as that virtual
host can be delegated to that set of daemon processes.
In the case where you have two separate <tt class="docutils literal">VirtualHost</tt> definitions for
the same <tt class="docutils literal">ServerName</tt>, but where one is for port 80 and the other for
port 443, specify the <tt class="docutils literal">WSGIDaemonProcess</tt> directive in the
first <tt class="docutils literal">VirtualHost</tt>. You can then refer to that daemon process group
by name from the second <tt class="docutils literal">VirtualHost</tt>. Using one daemon process group
across the two virtual hosts in this case is preferred as then you do not
have two whole separate instances of your application for port 80 and 443.
<div class="highlight-python"><div class="highlight"><pre>&lt;VirtualHost *:80&gt;
ServerName www.site1.com

WSGIDaemonProcess www.site1.com user=joe group=joe processes=2 threads=25
WSGIProcessGroup www.site1.com

...
&lt;/VirtualHost&gt;

&lt;VirtualHost *:443&gt;
ServerName www.site1.com

WSGIProcessGroup www.site1.com

...
&lt;/VirtualHost&gt;
</pre></div>
</div>
When <tt class="docutils literal">WSGIDaemonProcess</tt> is associated with a virtual host, the error log
associated with that virtual host will be used for all Apache error log
output from mod_wsgi rather than it appear in the main Apache error log.
For example, if a server is hosting two virtual hosts and it is desired
that the WSGI applications related to each virtual host run in distinct
processes of their own and as a user which is the owner of that virtual
host, the following could be used:
<div class="highlight-python"><div class="highlight"><pre>&lt;VirtualHost *:80&gt;
ServerName www.site1.com
CustomLog logs/www.site1.com-access_log common
ErrorLog logs/ww.site1.com-error_log

WSGIDaemonProcess www.site1.com user=joe group=joe processes=2 threads=25
WSGIProcessGroup www.site1.com

...
&lt;/VirtualHost&gt;

&lt;VirtualHost *:80&gt;
ServerName www.site2.com
CustomLog logs/www.site2.com-access_log common
ErrorLog logs/www.site2.com-error_log

WSGIDaemonProcess www.site2.com user=bob group=bob processes=2 threads=25
WSGIProcessGroup www.site2.com

...
&lt;/VirtualHost&gt;
</pre></div>
</div>
For historical reasons and the inability to change existing behaviour when
adding or changing features, many of the options to <tt class="docutils literal">WSGIDaemonProcess</tt>,
especially those related to timeouts are not enabled by default. It is
strongly recommended you explicitly set these options yourself as this will
give you a system which is better able to recover from backlogging due to
overloading when you have too many long running requests or hanging
requests. As a starting point you can see what <tt class="docutils literal">mod_wsgi-express</tt> uses as
defaults, adjusting them as necessary to suit your specific application
after you research what each option does. For example, consider starting
out with:
<ul class="simple">
<li><tt class="docutils literal">display-name='%{GROUP}'</tt></li>
<li><tt class="docutils literal">lang='en_US.UTF-8'</tt></li>
<li><tt class="docutils literal">locale='en_US.UTF-8'</tt></li>
<li><tt class="docutils literal">threads=5</tt></li>
<li><tt class="docutils literal">queue-timeout=45</tt></li>
<li><tt class="docutils literal">socket-timeout=60</tt></li>
<li><tt class="docutils literal">connect-timeout=15</tt></li>
<li><tt class="docutils literal">request-timeout=60</tt></li>
<li><tt class="docutils literal">inactivity-timeout=0</tt></li>
<li><tt class="docutils literal">startup-timeout=15</tt></li>
<li><tt class="docutils literal">deadlock-timeout=60</tt></li>
<li><tt class="docutils literal">graceful-timeout=15</tt></li>
<li><tt class="docutils literal">eviction-timeout=0</tt></li>
<li><tt class="docutils literal">restart-interval=0</tt></li>
<li><tt class="docutils literal">shutdown-timeout=5</tt></li>
<li><tt class="docutils literal">maximum-requests=0</tt></li>
</ul>
Note that the <tt class="docutils literal">WSGIDaemonProcess</tt> directive and corresponding features are
not available on Windows.
</div>

</div>
 <div class="articleComments">
 
 </div>
 </div>
 <footer>
 
 <div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
 
 <a href="WSGIImportScript.html" class="btn btn-neutral float-right" title="WSGIImportScript" accesskey="n" rel="next">Next </a>
 
 
 <a href="WSGIChunkedRequest.html" class="btn btn-neutral" title="WSGIChunkedRequest" accesskey="p" rel="prev"> Previous</a>
 
 </div>

<hr/>

</div>
 Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.

</footer>

</div>
 </div>

</section>

</div>

</body>
</html>