Support supervised non-systemd sessions (`--no-systemd`, runit/Void Linux)

[RomainLanz]

Note

This issue has been written with AI help.

Environment

• Void Linux (runit)
• Niri / Wayland
• Noctalia v5
• Python 3.14

Context

hyprwhspr setup auto --no-systemd already exists, and the main application can run as a foreground daemon with its own lock file. This makes most of the runtime look close to supervisor-agnostic already.

However, the Noctalia/Waybar integration and parts of the CLI still assume a systemd user service. In particular, config/hyprland/hyprwhspr-tray.sh calls systemctl --user directly for status/start/stop/restart. As a result, a daemon supervised by runit would be reported as stopped and the widget controls would not work, even though recording itself is controlled through hyprwhspr's runtime FIFO.

The README also currently lists systemd as a prerequisite, while the CLI exposes --no-systemd.

Proposed scope

Would you be open to a PR that completes the existing non-systemd path while preserving systemd as the default?

Possible approach:

1. Detect a foreground/supervised daemon by its lock/PID/process when no active systemd unit exists.
2. Make tray/Noctalia recording controls work with an already-running non-systemd daemon.
3. Add clean SIGTERM handling so supervisors such as runit can stop the daemon without skipping application cleanup.
4. Add a small runit service example and documentation for Void Linux.
5. Keep installation/service-manager abstraction limited in the first PR; full Void dependency automation could be separate.

A more generic supervisor-neutral approach would also help OpenRC, s6, dinit, and compositor-autostart users, rather than special-casing only runit.

I can implement and test this on Void Linux with runit, Niri, Noctalia v5, and the in-process ONNX-ASR/Parakeet backend. Before preparing the PR, I wanted to check which scope and service-manager interface you would prefer.

[goodroot]

Hey, this is very timely. Thanks for creating the issue.

Void is indeed getting quite popular.

I'm glad that you're able to test it and willing to do an implementation. Let me just do some research on my end and get back to you quickly to see if I have any thoughts before you dig in.

Again, much appreciated. 😀

[goodroot]

@RomainLanz OK, in general:

1. The data plane, most of the state and control, is already mostly OK
2. Supervising the lifecycle is the gap

---

Things to watch out for:

• Beware environment race. The systemd unit waits for the Wayland socket and imports WAYLAND_DISPLAY/NIRI_SOCKET, and I think that a runit service will get neither. Make sure we start before Niri as without those vars then injection silently fails. Problematic in past.

• The tray acts on its own via auto-restart after mic hotplug, stuck-service recovery, on every status poll. Those need a non-systemd decision (skip + notify is fine IMO but whatever works).

• _on_unrecoverable_audio_stream in lib/main.py only exits-for-restart under systemd — imo generalize to "supervised" so runit gets recovery instead of the weird/broken path.

• "Stopped vs. crashed" comes from systemctl is-failed - imo let it degrade to "stopped."

• Python 3.14: confirm onnxruntime wheels exist for it on Void before leaning on the in-process backend.

Also, to make things easier, I just ripped out the legacy Parakeet REST server, so hyprwhspr.service is the only unit to think about. 👍 That was a long time coming and this was a good opportunity.

---

Some notes from Claude, which has all my scaffolding, etc:

• Detection: fall back to the lock file — $XDG_RUNTIME_DIR/hyprwhspr/hyprwhspr.lock holds the PID when not under systemd. The tray script is the single source of truth; the Noctalia widget shims it, so both bars light up together.
• Recording controls: already flow through the runtime FIFO — they work the moment detection does.
• SIGTERM: yes — route it into the existing cleanup path. Helps systemd users too.
• Lifecycle: degrade, don't abstract. Non-systemd stop = signal the PID; restart belongs to the supervisor. No service-manager interface this pass.

---

Or: do what feels right to you and we'll get it shipped either way.

And: keeping it to runit and "works great on Void" is a solid step, vs. solving for all possible non-system options.

Bonne chance!

[RomainLanz]

Thanks!

I'm heading off on holiday now. I'll get back to this when I return. 🏖️

[goodroot]

Enjoy your time off. 😴