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.