Overview
When trying to redeploy a Passenger process, Passenger may refuse deployment, because you have maxed out on available process slots. Terminating the process will free a connection slot and permit Passenger to launch a new process.
Symptoms
Upon launching an application after restarting, the app will hang and log an error similar to:
[ 2015-03-03 14:36:46.2725 11560/7f728e250700 Pool2/Group.h:898 ]: Unable to spawn the the sole process for group /home/virtual/siteXXX/fst/var/subdomain/SUBDOMAIN/../../www/APPNAME#default because the max pool size has been reached. Trying to shutdown another idle process to free capacity...
Solution
Kill any resident processes from the terminal. You can accomplish this in one of two ways:
Easy way
Know the process name? kill -9 $(ps -o pid= -C PROCNAME) - substitute PROCNAME for the process name
Example: to kill all Python processes running with the binary, python: kill -9 $(ps -o pid= -C python)
In certain situations, a kill may be issued to other processes. This won’t affect neighboring processes, but will elicit a warning that may be safely ignored:
bash: kill: (17267) - Operation not permitted bash: kill: (17413) - Operation not permitted
Hard way
Don’t know the process name? Use ps to pull up processes:
Example:
[sand@sol www]$ ps x
PID TTY STAT TIME COMMAND
1898 ? Sl 0:02 Passenger AppPreloader: /home/virtual/site137/fst/var/www/rails4
3512 ? Sl 0:00 Passenger MeteorApp (3519)
3827 ? S 0:00 python /.socket/passenger/helper-scripts/wsgi-loader.pyThis is an abridged process list
Inspect the value under the PID column. PIDs are process identifiers and are a globally unique way to identify a process running. Take the PID for the respective Passenger application, then kill it.
kill -9 1898
This will kill the application running under /var/www/rails4 allowing Passenger to spawn a new instance.