Enabling the services
openmixer runs as systemd user units, not system services. The engine is a native PipeWire client and has to live inside the session that owns the operator's PipeWire graph; a system unit would land in a different graph and find no audio devices.
Two units ship with openmixer-server, both installed to /usr/lib/systemd/user/:
| Unit | What it runs |
|---|---|
openmixer-server.service |
/usr/bin/openmixer-server --config /etc/openmixer/config.json — the mixer engine and control plane. |
reac-pw.service |
/usr/bin/reac-pw, serving every declared REAC segment. Reads ~/.config/reac-pw/reac-pw.env plus one <iface>.env per segment. Owned by the reac-pw package, not by openmixer. |
Enable lingering first
loginctl enable-linger "$(whoami)"
This is required, not optional. systemd stops a user's units when that user's last session ends. Without lingering the mixer dies when you log out and does not come back after a headless reboot.
Enable the engine
systemctl --user enable --now openmixer-server
sudo systemctl reload nginx
The web surface is then on http://<host>:8880/.
Do not enable the REAC unit by hand
reac-pw.service is registered by the package but deliberately left disabled.
Configure the transport from the mixer itself — Setup → Adapters → REAC. That writes
~/.config/reac-pw/ and enables and starts the unit for you.
Enabling it by hand on a host that declares no interface does not crash-loop: the unit's
command line requires REAC_LIVE_IFACE to be set and fails fast with a
message naming the Setup path. That is the intended behaviour, but you have gained
nothing over letting Setup do it.
The unit also refuses to start if /usr/bin/reac-pw has lost its file capabilities. It
checks getcap before exec and fails with an explicit message rather than dying on a
silent EPERM inside the capture path. If you ever see that, reinstall or repair the
reac-pw package.
One further detail worth knowing if you edit the unit: NoNewPrivileges= is deliberately
not set on reac-pw.service. The kernel ignores file capabilities across
execve() when that flag is on, which would silently strip CAP_NET_RAW.
Prove it survives a reboot
Starting once is not the test. Reboot the machine, do not log in, and check from another session:
machinectl shell <operator>@ /bin/systemctl --user status openmixer-server reac-pw
Both should be active. If they are not, lingering is the first thing to check.
Check the units resolve from the packaged path
systemctl --user list-unit-files | grep -E 'openmixer-server|reac-pw'
Both should come from /usr/lib/systemd/user/. A leftover file at
~/.config/systemd/user/<name>.service shadows the packaged unit of the same name,
so a package upgrade will appear to have no effect. That is exactly what this check
catches; a rig migrating off hand-installed units should run
deploy/systemd/migrate-to-packaged.sh from the source tree.
Restarting
systemctl --user restart openmixer-server
systemctl --user restart reac-pw
Restarting the REAC unit is safe with a box connected: the stagebox re-runs its handshake by itself and is normally back within a few seconds.