This is an old revision of the document!


To enable Python or Ruby on a shared hosting environment instead of in a dedicated VPS environment (such as cpanel, DirectAdmin etc), CloudLinux Python and Ruby Selector is recommended. If it is not for a shared hosting environment, you can refer to our archive section for LSWS native setup.

The Python and Ruby Selector allows end users to select the specific version of Python or Ruby they need.

LiteSpeed supports the Apache mod_passenger configuration generated through CloudLinux selectors (LiteSpeed doesn't support most of the mod_passenger apache rules and only support a few of the long list. Please check here for LiteSpeed supported Mod_Passenger rules). However, behind the scenes, LiteSpeed's is a completely different implementation to Apache's.

  • LiteSpeed Web Server 5.2+
  • CloudLinux
  1. Make sure Python and Ruby Selector works properly under Apache (follow CloudLinux instructions to install and configure).
  2. Test a Ruby or Python application with Apache and ensure it is running OK.
  3. Run script to install required ruby/python lsapi modules:
    /usr/local/lsws/admin/misc/enable_ruby_python_selector.sh
  4. Switch to LiteSpeed and try a ruby/python app

There are two ways to restart the Python and Ruby application: through the cPanel CloudLinux Python Application Manager, or by touching the <app_root_dir>/tmp/restart.txt file.

For example, if a Python application is located at /home/user1/mypythonapp the command would be:

touch /home/user1/mypythonapp/tmp/restart.txt

This will tell the server to restart the application.

NOTE: If you are restarting the Python app by touching <app_root_dir>/tmp/restart.txt, and the file already exists, you must still touch it to restart the app.

The application does not work properly

If your application does not work properly, you can try two simple steps to check if the application has been setup properly:

  1. If possible, switch back to Apache temporarily to verify if the application works properly under Apache.
  2. Check if any error has been logged into <APP_ROOT_DIR>/stderr.log. If it has, fix the error and try again.

For example:

A Python application writes an error to stderr.log under the application root directory, /home/user1/dingodossier/mbntp/stderr.log:

Traceback (most recent call last):
  File "/home/user1/dingodossier/mbntp/passenger_wsgi.py", line 8, in <module>
    wsgi = imp.load_source('wsgi', 'mbntp/wsgi.py')
  File "/home/user1/virtualenv/dingodossier_mbntp/3.4/lib64/python3.4/imp.py", line 171, in load_source
    module = methods.load()
  File "<frozen importlib._bootstrap>", line 1220, in load
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "<frozen importlib._bootstrap>", line 1471, in exec_module
  File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
  File "mbntp/wsgi.py", line 10, in <module>
    from django.core.wsgi import get_wsgi_application
ImportError: No module named 'django'

This indicates Django was not properly set up for the application.

The application will not restart

If touch <app_root_dir>/tmp/restart.txt or the CloudLinux Python manager fail to restart the Python application, there may be some old lswsgi processes in the way. Use the ps command to verify:

ps -ef | grep pythontest
pythont+ 508045 1 0 Aug13 ? 00:01:23 /opt/alt/python37/bin/lswsgi -m /home/pythontest/pyapp1/passenger_wsgi.py
pythont+ 890556 1 0 Jul31 ? 00:05:34 /opt/alt/python37/bin/lswsgi -m /home/pythontest/pyapp1/passenger_wsgi.py
pythont+ 1470047 1 0 Jul19 ? 00:10:36 /opt/alt/python37/bin/lswsgi -m /home/pythontest/pyapp1/passenger_wsgi.py
pythont+ 1900598 1866381 0 15:14 ? 00:00:00 /opt/alt/python37/bin/lswsgi -m /home/pythontest/pyapp1/passenger_wsgi.py
root 1902042 1898738 0 15:22 pts/2 00:00:00 grep --color=auto pythontest
pythont+ 2741844 1 0 Jul23 ? 00:08:41 /opt/alt/python37/bin/lswsgi -m /home/pythontest/pyapp1/passenger_wsgi.py

Even though you may have restarted the latest lswsgi process, the old running processes can cause restart issues. You may find, even if you switch to Apache, that these processes remain. The best way to deal with them is to log into the user via SSH and manually kill the processes.

  • Admin
  • Last modified: 2021/08/24 11:58
  • by Lisa Clarke