Show HN: Interactive systemd – a better way to work with systemd units

Original Article ↗ Hacker News Discussion ↗

Overall Reception

  • Many commenters are enthusiastic; several say they “will definitely try it” and plan to bundle it into their workflows.
  • People who already use tools like lazygit/lazydocker see this as a similar “visibility + ergonomics” upgrade for systemd.
  • Some express frustration that such a tool is necessary at all, but welcome it as making systemd “fun” or at least less tedious.

Remote and Multi‑Host Usage

  • Multiple users immediately ask for remote host support akin to systemctl --host and for integration over SSH and docker exec.
  • The current tool is essentially a wrapper around local systemctl; remote support is not implemented yet but is under consideration, with an open issue.
  • Suggestions include always treating “host” as a parameter so local and remote remain a unified UI.

Nix/NixOS and Installation

  • NixOS users are a strong early audience; the immutable config model makes interactive debugging particularly attractive.
  • Discussion around using systemctl edit --runtime on NixOS for debugging units.
  • Some confusion around AppImage + Nix due to /nix directory mounting behavior; docs were updated.
  • uv is praised as an easy way to install; minor issues with specific uv invocation and Python version requirements are noted.

Systemd UX and Philosophy

  • A large subthread debates systemctl’s CLI design: verb-first vs verb-last, consistency with other tools, and ergonomics for frequent restart/stop cycles.
  • Some find systemctl/journalctl “fiddly and unintuitive” and constantly have to look up commands; others argue the interface is consistent with modern Unix-style CLIs and that aliases are the right solution.
  • Comparisons are made to cron vs systemd timers, git’s ergonomics, and broader Unix philosophy (small base, composable, scriptable).

Service Semantics (ExecStop, types, timers)

  • Long discussion on ExecStart/ExecStop, Type=oneshot/forking, and RemainAfterExit.
  • Several users find ExecStop semantics confusing, especially that it often runs after the main process exits and that behavior changes with service type.
  • Others argue the semantics are internally consistent if you think in terms of service states (starting/running/stopping/stopped), but acknowledge the mental model is non-obvious.

Security Concerns

  • Users appreciate a dedicated security section in the docs and ask how hijacking is prevented.
  • Suggestions include adding automated code scanning (e.g., static analysis) and better handling of supply-chain risks.
  • A side thread notes that systemd itself is still “default allow” and not a replacement for MAC systems like SELinux/AppArmor, though this is somewhat off-topic for the TUI itself.

Implementation Choices and Ecosystem

  • The project is implemented in Python using Textual; this is praised for documentation and rapid development, even though some would prefer Rust/Go.
  • Some compare the tool conceptually to k9s (for Kubernetes) or other TUIs, and suggest similar UX patterns.
  • Early feedback highlights performance hiccups on pane switching, missing PageUp/PageDown, and desire for integrating systemd-analyze security; issues have been filed and are being iterated on.