Manually stop processes launched by mod_wsgi, and monitor how many processes are running

Taken partially from this question, add display-name to WSGIDaemonProcess so you can grab them using a command like:

ps aux | grep modwsgi

Add this to your configuration:

Define GROUPNAME modwsgi
WSGIDaemonProcess yourapp user=www-data group=www-data processes=5 threads=5 display-name=%{GROUPNAME}

Update

There are a couple of reasons why ps would not give you the DaemonProcess display-name.
As shown in the docs:

display-name=value Defines a different name to show for the daemon process when using the ps command to list processes. If the value is %{GROUP} then the name will be (wsgi:group) where group 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 argv0 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 ps program with BSD heritage. Thus on some versions of Solaris UNIX the /usr/bin/ps program doesn’t work, but /usr/ucb/ps does. Other programs which can display this value include htop.

You could:

Set a display-name of smaller length:

WSGIDaemonProcess yourapp user=www-data group=www-data processes=5 threads=5 display-name=wsws

And try to find them by:

ps aux | grep wsws

Or set it to %{GROUP} and filter using the name of the daemon process group (wsgi:group).

The way which processes are managed with mod_wsgi for each mode is described in:

• http://modwsgi.readthedocs.io/en/develop/user-guides/processes-and-threading.html

For embedded mode, where your WSGI application is run inside of the Apache child worker processes, Apache manages when processes are created and destroyed based on the Apache MPM settings. Because of how Apache manages the processes, they can be shutdown at any time if there is insufficient request throughput, or more processes could be created if request throughput increases. When running, the same process will handle many requests over time until it gets shutdown. In other words, Apache dynamically manages the number of processes.

Because of this dynamic process management, it is a bad idea to use embedded mode of mod_wsgi unless you know how to tune Apache properly and many other things as well. In short, never use embedded mode unless you have a good amount of experience with Apache and running Python applications with it. You can watch a video about why you wouldn't want to run in embedded mode at:

• https://www.youtube.com/watch?v=k6Erh7oHvns

There is also the blog post:

• http://blog.dscpl.com.au/2012/10/why-are-you-using-embedded-mode-of.html

So use daemon mode and verify that your configuration is correct and you are in fact using daemon mode by using the check in:

• http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#embedded-or-daemon-mode

For daemon mode, the WSGI application runs in a separate set of managed processed. These are created at the start and will run until Apache is restarted, or reloading of the process is triggered for various reasons, including:

• The daemon process is sent a direct signal to shutdown by a user.
• The code of the application sends itself a signal.
• The WSGI script file is modified, which will trigger a shutdown so the WSGI application can be reloaded.
• A defined request timeout occurs due to stuck or long running request.
• A defined maximum number of requests has occurred.
• A defined inactivity timeout expires.
• A defined timer for periodic process restart expires.
• A startup timeout is defined and the WSGI application failed to load in that time.

In these cases, when the process is shutdown, it is replaced.

More details about the various timeout options and how the processes respond to signals can be found in:

• http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html

More details about source code reloading and touching of the WSGI script file can be found in:

• http://modwsgi.readthedocs.io/en/develop/user-guides/reloading-source-code.html

One item which is documented is how you can incorporate code which will look for any changes to Python code files used by your application. When a change occurs to any of the files, the process will be restarted by sending itself a signal. This should only be used for development and never in production.

If you are using mod_wsgi-express in development, which is preferable to hand configuring Apache yourself, you can use the --reload-on-changes option.

If sending a SIGTERM signal to the daemon process, there is a set shutdown sequence where it will wait a few seconds to wait for current requests to finish. If the requests don't finish, the process will be shutdown anyway. That period of time is dictated by the shutdown timeout. You shouldn't play with that value.

If sending a SIGUSR1 signal to the daemon process, by default it acts just like sending a SIGTERM signal. If however you specify the graceful timeout for shutdown, you can extend how long it will wait for current requests to finish. New requests will be accepting during that period. That graceful timeout also applies in other cases as well, such as maxmimum number of requests received, or timer for periodic restart triggered. If you need the timeout when using SIGUSR1 to be different to those cases, define the eviction timeout instead.

As to how to identify the daemon processes to be sent the signal, use the display-name of option WSGIDaemonProcess. Then use ps to identify the processes, or possibly use killall if it uses the modified process name on your platform. Send the daemon processes the SIGUSR1 signal if want more graceful shutdown and SIGTERM if want them to restart straight away.

If you want to track how long a daemon process has been running, you can use:

import mod_wsgi
metrics = mod_wsgi.process_metrics()

The metrics value will include output like the following for the process the call is made in:

{'active_requests': 1,
 'cpu_system_time': 0.009999999776482582,
 'cpu_user_time': 0.05000000074505806,
 'current_time': 1525047105.710778,
 'memory_max_rss': 11767808,
 'memory_rss': 11767808,
 'pid': 4774,
 'request_busy_time': 0.001851,
 'request_count': 2,
 'request_threads': 2,
 'restart_time': 1525047096.31548,
 'running_time': 9,
 'threads': [{'request_count': 2, 'thread_id': 1},
             {'request_count': 1, 'thread_id': 2}]}

If you just want to know how many processes/threads are used for the current daemon process group you can use:

mod_wsgi.process_group
mod_wsgi.application_group
mod_wsgi.maximum_processes
mod_wsgi.threads_per_process

to get details about the process group. The number of process is fixed at this time for daemon mode and the name maximum_processes is just to be consistent with what the name is in embedded mode.

If you need to run code on process shutdown, you should NOT try and define your own signal handlers. Do that and mod_wsgi will actually ignore them as they will interfere with normal operation of Apache and mod_wsgi. Instead, if you need to run code on process shutdown, use atexit.register(). Alternatively, you can subscribe to special events generated by mod_wsgi and trigger something off the process shutdown event.