Socket activation
Allows optional auto-launching of monado-service.
A few ways:
- by default (and without systemd) nothing is different: run monado-service, then run your app. Most monado developers are expected to use this.
- if systemd is available (and it's not configured to disable this), when the project is installed, a
monado.socket
andmonado.service
user unit files are installed in /usr/lib/systemd/user or similar.systemctl --user enable monado.socket
will have systemd open the domain socket at login, for socket-activation: running a client app will spin up the service, whilesystemctl --user stop monado.service
will stop it. (You can still run the service on its own if you haven't enabled the socket unit and it will work as expected.) This is expected to mainly be used by end users installing a package. - if systemd is available (and it's not configured to disable this), and if the person compiling runs
{make,ninja} link-systemd-dev-units
, it will linkmonado-dev.service
andmonado-dev.socket
for that user (usingsystemctl --user link
) - which symlinks into~/.config/systemd/user/
. Thesemonado-dev
units contain absolute paths to the build directory (just likeopenxr_monado-dev.json
) and are specified to conflict with themonado
-named units, so there will be no compat problems. These monado-dev services are set to exit after the client quits, to support development iteration. This is even more optional but might be helpful to some developers.
One thing that this would let us do (but is not currently done yet) is to lock-down what we allow the service module to actually do: systemd contains a variety of ways to restrict processes with just a configuration change, which is nice for security.
Fixed earlier todo: If you try running it when there was already one running (or even just systemd listening) you get
ERROR: Could not bind socket: is the service running already?
Or, is the systemd unit monado.socket or monado-dev.socket active?
(The second line is of course conditional on building with systemd support.)