Markus Heiser bfef2c3b65 [fix] buildprocess of docs in LXC (containers)

The $DOCS_BUILD variable (like all BUILD variables) in the lxc environment::

   sudo -H ./utils/lxc.sh cmd searx-archlinux make docs

is different from running build process in the HOST::

   make docs

with kernel-include directive we can use the environment variables in the reST
documents to address the correct file location of the include.

Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>

2020-06-18 18:52:45 +02:00

4.7 KiB

Raw Blame History

uwsgi

further reading

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.ini
The 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.

Ubuntu / debian