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

Original Article ↗ Hacker News Discussion ↗

An open-source TUI tool for managing systemd units is drawing praise from developers and admins who find `systemctl`/`journalctl` powerful but cumbersome for everyday tasks like starting services and viewing logs. Commenters highlight how the interface improves visibility, shortens the debug loop, and feels similar in spirit to tools like lazygit or k9s, while noting limitations such as lack of first-class remote host support and some performance quirks. The conversation broadens into long-standing grievances with systemd’s ergonomics and naming, alongside appreciation for its consistency across distros and interest in better, security-conscious tooling on top of it.

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.