uwsgi¶
Contents
Origin uWSGI¶
How uWSGI is implemented by distributors is different. uWSGI itself recommend two methods
systemd.unit template files as described here One service per app in systemd.
There is one systemd unit template and one uwsgi ini file per uWSGI-app placed at dedicated locations. Take archlinux and a searx.ini as example:
unit template --> /usr/lib/systemd/system/uwsgi@.service uwsgi ini files --> /etc/uwsgi/searx.iniThe searx app can be maintained as know from common systemd units:
systemctl enable uwsgi@searx systemctl start uwsgi@searx systemctl restart uwsgi@searx systemctl stop uwsgi@searx
The uWSGI Emperor mode which fits for maintaining a large range of uwsgi apps.
The Emperor mode is a special uWSGI instance that will monitor specific events. The Emperor mode (service) is started by a (common, not template) systemd unit. The Emperor service will scan specific directories for uwsgi ini files (also know as vassals). If a vassal is added, removed or the timestamp is modified, a corresponding action takes place: a new uWSGI instance is started, reload or stopped. Take Fedora and a searx.ini as example:
to start a new searx instance create --> /etc/uwsgi.d/searx.ini to reload the instance edit timestamp --> touch /etc/uwsgi.d/searx.ini to stop instance remove ini --> rm /etc/uwsgi.d/searx.ini
Distributors¶
The uWSGI Emperor mode and systemd unit template is what the distributors mostly offer their users, even if they differ in the way they implement both modes and their defaults. Another point they might differ is the packaging of plugins (if so, compare Install packages) and what the default python interpreter is (python2 vs. python3).
Fedora starts a Emperor by default, while archlinux does not start any uwsgi service by default. Worth to know; debian (ubuntu) follow a complete different approach. debian: your are familiar with the apache infrastructure? .. they do similar for the uWSGI infrastructure (with less comfort), the folders are:
/etc/uwsgi/apps-available/
/etc/uwsgi/apps-enabled/
The uwsgi ini file is enabled by a symbolic link:
ln -s /etc/uwsgi/apps-available/searx.ini /etc/uwsgi/apps-enabled/
From debian’s documentation (/usr/share/doc/uwsgi/README.Debian.gz): You
could control specific instance(s) by issuing:
service uwsgi <command> <confname> <confname> ...
sudo -H service uwsgi start searx
sudo -H service uwsgi stop searx
My experience is, that this command is a bit buggy.
Alltogether¶
Create the configuration ini-file according to your distribution (see below) and restart the uwsgi application.
# init.d --> /usr/share/doc/uwsgi/README.Debian.gz
# For uWSGI debian uses the LSB init process, this might be changed
# one day, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833067
create /etc/uwsgi/apps-available/searx.ini
enable: sudo -H ln -s /etc/uwsgi/apps-available/searx.ini /etc/uwsgi/apps-enabled/
start: sudo -H service uwsgi start searx
restart: sudo -H service uwsgi restart searx
stop: sudo -H service uwsgi stop searx
disable: sudo -H rm /etc/uwsgi/apps-enabled/searx.ini
# systemd --> /usr/lib/systemd/system/uwsgi@.service
# For uWSGI archlinux uses systemd template units, see
# - http://0pointer.de/blog/projects/instances.html
# - https://uwsgi-docs.readthedocs.io/en/latest/Systemd.html#one-service-per-app-in-systemd
create: /etc/uwsgi/searx.ini
enable: sudo -H systemctl enable uwsgi@searx
start: sudo -H systemctl start uwsgi@searx
restart: sudo -H systemctl restart uwsgi@searx
stop: sudo -H systemctl stop uwsgi@searx
disable: sudo -H systemctl disable uwsgi@searx
# systemd --> /usr/lib/systemd/system/uwsgi.service
# The unit file starts uWSGI in emperor mode (/etc/uwsgi.ini), see
# - https://uwsgi-docs.readthedocs.io/en/latest/Emperor.html
create: /etc/uwsgi.d/searx.ini
restart: sudo -H touch /etc/uwsgi.d/searx.ini
disable: sudo -H rm /etc/uwsgi.d/searx.ini
[uwsgi]
# uWSGI core
# ----------
#
# https://uwsgi-docs.readthedocs.io/en/latest/Options.html#uwsgi-core
# Who will run the code
uid = searx
gid = searx
# chdir to specified directory before apps loading
chdir = /usr/local/searx/searx-src/searx
# searx configuration (settings.yml)
env = SEARX_SETTINGS_PATH=/etc/searx/settings.yml
# disable logging for privacy
disable-logging = true
# The right granted on the created socket
chmod-socket = 666
# Plugin to use and interpretor config
single-interpreter = true
# enable master process
master = true
# load apps in each worker instead of the master
lazy-apps = true
# load uWSGI plugins
plugin = python3,http
# By default the Python plugin does not initialize the GIL. This means your
# app-generated threads will not run. If you need threads, remember to enable
# them with enable-threads. Running uWSGI in multithreading mode (with the
# threads options) will automatically enable threading support. This *strange*
# default behaviour is for performance reasons.
enable-threads = true
# plugin: python
# --------------
#
# https://uwsgi-docs.readthedocs.io/en/latest/Options.html#plugin-python
# load a WSGI module
module = searx.webapp
# set PYTHONHOME/virtualenv
virtualenv = /usr/local/searx/searx-pyenv
# add directory (or glob) to pythonpath
pythonpath = /usr/local/searx/searx-src
# speak to upstream
# -----------------
#
# Activate the 'http' configuration for filtron or activate the 'socket'
# configuration if you setup your HTTP server to use uWSGI protocol via sockets.
# using IP:
#
# https://uwsgi-docs.readthedocs.io/en/latest/Options.html#plugin-http
# Native HTTP support: https://uwsgi-docs.readthedocs.io/en/latest/HTTP.html
http = 127.0.0.1:8888
# using unix-sockets:
#
# On some distributions you need to create the app folder for the sockets::
#
# mkdir -p /run/uwsgi/app/searx
# chmod -R searx:searx /run/uwsgi/app/searx
#
# socket = /run/uwsgi/app/searx/socket
[uwsgi]
# uWSGI core
# ----------
#
# https://uwsgi-docs.readthedocs.io/en/latest/Options.html#uwsgi-core
# Who will run the code
uid = searx
gid = searx
# chdir to specified directory before apps loading
chdir = /usr/local/searx/searx-src/searx
# searx configuration (settings.yml)
env = SEARX_SETTINGS_PATH=/etc/searx/settings.yml
# disable logging for privacy
logger = systemd
disable-logging = true
# The right granted on the created socket
chmod-socket = 666
# Plugin to use and interpretor config
single-interpreter = true
# enable master process
master = true
# load apps in each worker instead of the master
lazy-apps = true
# load uWSGI plugins
plugin = python
# By default the Python plugin does not initialize the GIL. This means your
# app-generated threads will not run. If you need threads, remember to enable
# them with enable-threads. Running uWSGI in multithreading mode (with the
# threads options) will automatically enable threading support. This *strange*
# default behaviour is for performance reasons.
enable-threads = true
# plugin: python
# --------------
#
# https://uwsgi-docs.readthedocs.io/en/latest/Options.html#plugin-python
# load a WSGI module
module = searx.webapp
# set PYTHONHOME/virtualenv
virtualenv = /usr/local/searx/searx-pyenv
# add directory (or glob) to pythonpath
pythonpath = /usr/local/searx/searx-src
# speak to upstream
# -----------------
#
# Activate the 'http' configuration for filtron or activate the 'socket'
# configuration if you setup your HTTP server to use uWSGI protocol via sockets.
# using IP:
#
# https://uwsgi-docs.readthedocs.io/en/latest/Options.html#plugin-http
# Native HTTP support: https://uwsgi-docs.readthedocs.io/en/latest/HTTP.html
http = 127.0.0.1:8888
# using unix-sockets:
#
# On some distributions you need to create the app folder for the sockets::
#
# mkdir -p /run/uwsgi/app/searx
# chown -R searx:searx /run/uwsgi/app/searx
#
# socket = /run/uwsgi/app/searx/socket
[uwsgi]
# uWSGI core
# ----------
#
# https://uwsgi-docs.readthedocs.io/en/latest/Options.html#uwsgi-core
# Who will run the code
uid = searx
gid = searx
# chdir to specified directory before apps loading
chdir = /usr/local/searx/searx-src/searx
# searx configuration (settings.yml)
env = SEARX_SETTINGS_PATH=/etc/searx/settings.yml
# disable logging for privacy
disable-logging = true
# The right granted on the created socket
chmod-socket = 666
# Plugin to use and interpretor config
single-interpreter = true
# enable master process
master = true
# load apps in each worker instead of the master
lazy-apps = true
# load uWSGI plugins
plugin = python3,http
# By default the Python plugin does not initialize the GIL. This means your
# app-generated threads will not run. If you need threads, remember to enable
# them with enable-threads. Running uWSGI in multithreading mode (with the
# threads options) will automatically enable threading support. This *strange*
# default behaviour is for performance reasons.
enable-threads = true
# plugin: python
# --------------
#
# https://uwsgi-docs.readthedocs.io/en/latest/Options.html#plugin-python
# load a WSGI module
module = searx.webapp
# set PYTHONHOME/virtualenv
virtualenv = /usr/local/searx/searx-pyenv
# add directory (or glob) to pythonpath
pythonpath = /usr/local/searx/searx-src
# speak to upstream
# -----------------
#
# Activate the 'http' configuration for filtron or activate the 'socket'
# configuration if you setup your HTTP server to use uWSGI protocol via sockets.
# using IP:
#
# https://uwsgi-docs.readthedocs.io/en/latest/Options.html#plugin-http
# Native HTTP support: https://uwsgi-docs.readthedocs.io/en/latest/HTTP.html
http = 127.0.0.1:8888
# using unix-sockets:
#
# On some distributions you need to create the app folder for the sockets::
#
# mkdir -p /run/uwsgi/app/searx
# chmod -R searx:searx /run/uwsgi/app/searx
#
# socket = /run/uwsgi/app/searx/socket
