Now, the python venv is now created via `pyvenv` or `python3 -m venv`
instead of the legacy `virtualenv`. For this, not all python processes
from the venv need to be stopped.
Migration from previous versions of this type may be difficult, but
solvable if the venv will be recreated.
Changed flag (force to ignore a non-existant directory), typo and
swapped arguments are done. Also, the process to stop all processes from
the virtal environment has changed: Now, it stops all potential services
and ignore errors (because a service doesn't exist).
After that, it sends a kill signal to all processes and then gracefully
wait since there is no option to do that with systemd.
Cause of corrupt databases if the services are restarted incorrectly,
the order and dependencies are adjusted. Now, the `netbox-rq` service
will be included in restarts of `netbox` and required for the WSGI
servers that it must running.
For these changes, the restart command of `__netbox` was adjusted. The
other ones where edited too, to use the same command.
All services now require redis and postgresql to be started before them
to prevent any start order issues.
If someone asked for what the RQ worker is required, see here:
https://netbox.readthedocs.io/en/stable/additional-features/webhooks/#webhook-processing
Because `set -e` got printed all the time, the type __netbox always had
some generated code for the remote side. This line was removed because
this is already done by cdist when executing the code-remote script.
Rather, the exit-on-error option was set to some scirpts (two ..).
To avoid aborts because of the python venv could not be updated by
killing all processes that uses the venv.
It will be done all times to prevent any error, because it could not be
reliably detected if the type installs or updates NetBox.
The wrapper service will "control" the services added from the
__netbox_* types to provide a general interface. This is more dynamic
than the alias approach used previously. Through this, it is possible
to handle multiple wsgi services for netbox - if this works ..
See as a reference:
http://alesnosek.com/blog/2016/12/04/controlling-a-multi-service-application-with-systemd/
Because someone *want* to use something other than just gunicorn, it was
extracted to a own type. Because gunicorn is a bit deep in the netbox
installation process, it's a bit harder to isolate it.
`__netbox_uwsgi` will come, too.