OpenMTC/doc/systemd.md
2017-11-07 14:41:38 +01:00

53 lines
3.8 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# OpenMTC systemd integration
In addition to SysV init scripts, OpenMTC is providing ready-to-use service files for the [systemd](https://freedesktop.org/wiki/Software/systemd/) init system.
> ** Hint:** As OpenMTC does not require privileged ports in order to function, it can be safely run from within a user's home directory. To do so, replace `sudo systemctl` with `systemctl --user`. It should bear mentioning that this is a convenience option for developers that is strongly discouraged for production.
## Installing Service Files
Please refrain from copying or editing the provided files. Instead, change into the root of the openmtc repository and proceed as follows:
```sh
$ sudo systemctl link $(pwd)/openmtc-gevent/etc/systemd/system/openmtc-*.service
```
This should provide you with two new services in the systemd search path: `openmtc-gateway` and `openmtc-backend`. Confirm this by executing `sudo systemctl status openmtc-\*`.
## Adjusting `ExecStart`
By default, the service files will assume to find the start scripts to be located in `/usr/local/bin`. Chances are, this may not be the case. This is how to adjust the service files properly:
```sh
$ sudo systemctl edit openmtc-gateway
```
An editor is going to open. Fill the presented file with the following content:
```ini
[Service]
# Clear user and group
User=
Group=
# This is needed to reset ExecStart before reassigning
ExecStart=
# Change to location on your system
ExecStart=/opt/openmtc-gevent/bin/run-gateway
```
Save the file and exit the editor. Run `sudo systemctl daemon-reload` and verify the new value got picked up by executing `sudo systemctl show --property=ExecStart --no-pager openmtc-gateway `.
The procedure above is identical for the `openmtc-backend` component, safe for replacing `gateway` with `backend`.
## Controlling the Services
Both, gateway and backend, can be started through `sudo systemctl start openmtc-gateway` and `sudo systemctl start openmtc-backend`, respectively. They can also be started in bulk via `sudo systemctl start openmtc-gateway openmtc-backend`. Execution order is not guaranteed, though.
If you always require the two services, it may be a good idea to add a dependency from the gateway to the backend as follows:
```sh
$ sudo systemctl add-requires openmtc-gateway.service openmtc-backend
```
> **⚠️ Caveat:** Please take note that the target unit name is fully specified. This is needed as systemd would otherwise assume you wanted to add a requirement to a *target*
Verify the dependency has been set in place by running `sudo systemctl list-dependencies openmtc-gateway` and checking if `openmtc-gateway.service` is listed. Starting the `openmtc-gateway` service will now also invoke `openmtc-backend`. Another benefit is that `openmtc-gateway` will be reloaded if `openmtc-backend` is.
Services can be shut down through `sudo systemctl stop` in the same fashion as `systemctl start`.
## Monitoring
While `systemctl status` may reveal some log lines, more telling output generated by the services can be monitored through [`journalctl`](https://www.freedesktop.org/software/systemd/man/journalctl.html). `sudo journalctl -lf --unit openmtc-\*` should present a life feed of all running openmtc services.
> ** Hint:** The road is a bit rough for those who run OpenMTC via systemd from their homedir, unfortunately. In theory, you should be good to go with `journalctl -lf --user --unit openmtc-\*`. But due to a lot of diversity in deployed systemd versions potentised by a wealth of different configurations, this may not do the trick. In that case, - under the assumption only a single instance of each, gateway and backend is running - the fastest way to success may be this:
```sh
$ sudo journalctl -lf _PID=$(ps ux | grep gateway_main.py | head -n1 | awk '{ print $2; }') + \
_PID=$(ps ux | grep backend_main.py | head -n1 | awk '{ print $2; }')
```