systemd-manager-tui: a terminal interface for systemd units

Why systemd-manager-tui exists

systemd-manager-tui targets administrators who need to inspect and change systemd units without moving between command-line commands and log views. It provides one terminal interface for listing services, reading logs, examining properties, editing unit files, and changing a unit's lifecycle. Supported operations include start, stop, restart, mask, unmask, enable, and disable. That operation set makes it relevant for routine administration of both system units and per-user units.

The application is written in Rust and built as a terminal user interface with Ratatui and crossterm. Its command-line parsing uses clap, while zbus handles communication with systemd over D-Bus. This is not a general-purpose service dashboard. It assumes systemd is the init system and offers a focused way to work with units exposed through systemd's D-Bus interfaces.

System and user scopes can be navigated from the same application. The unit list can also be limited to running services or expanded to show all units. This matters because a single operator may manage root-owned system services and services attached to a user's systemd manager during the same session. However, permissions still follow the D-Bus scope. The README does not document a way to bypass systemd policy or gain privileges.

D-Bus data flow and terminal interface

The documented mechanism is direct interaction with systemd through the D-Bus API. The application does not present its controls as shell scripts built around systemctl. Instead, operations and queries are sent through the bus, which allows the program to represent systemd as an interactive interface. The exact bus method names are not included in the README, so they should not be inferred beyond the stated lifecycle operations.

The terminal layer is built around Ratatui 0.29 and crossterm 0.28.1. The README also lists Vim-like navigation. Filtering can be supplied at startup, as shown later with the `-f` option, and notification watching can be disabled with `-n` or `--no-notifications`. These details indicate that the interface is intended for repeated keyboard operation rather than a single command that prints service status.

The regular test suite covers unit logic, application flows, and Ratatui rendering with `TestBackend`. According to the README, that suite does not require an interactive terminal or a running systemd instance. This separation makes ordinary development checks possible in environments that cannot expose real system and user buses. The opt-in integration suite is a different matter because it reads actual units and creates a transient user service for lifecycle checks.

Installing systemd-manager-tui on common Linux distributions

The project offers distribution packages, an AUR package, Nix execution, a release binary, and Cargo installation. Choose the path that matches the host rather than copying all of these commands. Package metadata states that the Debian package depends on systemd and recommends a session bus, while the RPM metadata requires systemd. That metadata also places the release binary at `/usr/bin/systemd-manager-tui`.

For Ubuntu, download the matching `.deb` from the repository's Releases page, then install that local file with dpkg. The README uses `x.x.x-x` as a placeholder for the downloaded version and architecture, so those literal values must be replaced with the actual release asset name.

sudo dpkg -i ./systemd-manager-tui_x.x.x-x_amd64.deb

Fedora follows the same pattern with an RPM asset downloaded from Releases. Again, substitute the real version and architecture in the filename.

sudo dnf install ./systemd-manager-tui_x.x.x-x_x86_64.rpm

Arch Linux users are directed to the Arch User Repository package.

yay -S systemd-manager-tui

NixOS users can run the GitHub project through Nix.

nix run github:matheus-git/systemd-manager-tui

The repository also includes `flake.nix` and `flake.lock`, and the README links to `docs/flakes.md` for flake-specific guidance.

Starting a filtered systemd service session

Cargo is the most direct documented source-based installation method. It installs the crate named `systemd-manager-tui` with the locked dependency graph. The package version in `Cargo.toml` is 1.3.0, matching the recent v1.3.0 release listed for the project.

cargo install --locked systemd-manager-tui

After installation, launch the program by name. Without options, it opens the terminal interface for managing systemd services.

systemd-manager-tui

A first useful session can start with a service-name filter. The following documented example limits the initial view to units matching `docker`.

systemd-manager-tui -f docker

The README does not describe the complete keyboard map for every view. It does confirm Vim-like navigation and the available lifecycle commands, but it does not state whether actions require confirmation, which key opens the editor, or whether every property field is editable. Those interface details should be checked against the current documentation or source before automating a sequence of keystrokes.

A downloaded binary follows a separate path. Make it executable and run it from its directory. This is appropriate only when the release binary matches the host architecture and required libraries.

chmod +x systemd-manager-tui
./systemd-manager-tui

Controlling notifications and unit scope

By default, the application watches system and user units for failure notifications. Operators who do not want that behavior can disable it with either the short or long option. Both forms are documented as equivalent.

systemd-manager-tui -n

The long form is useful in scripts, aliases, or documentation where the intent should remain visible without opening the README.

systemd-manager-tui --no-notifications

Disabling notifications removes watching for system and user unit failures. The README does not say that it disables journal access, so it should not be interpreted as a general switch for all log viewing. Nor does the documentation describe notification thresholds, retry behavior, or a configurable timeout.

Scope selection is a navigation feature rather than a command-line switch in the documented usage. Users can move between system and user units and can restrict the list to running services or show all units. That arrangement suits mixed workloads, but it leaves an important operational boundary: access depends on the active user manager and bus authorization. The integration test instructions explicitly require a systemd-based Linux host with an active user manager for the relevant user-bus checks.

Editing units and checking real systemd behavior

The application supports unit-file editing in addition to lifecycle commands and log viewing. The README does not specify the editor integration, validation behavior, or whether edits are applied immediately. It therefore does not support claims about syntax checking, automatic restarts after an edit, or recovery from invalid unit files. Users who require controlled changes may need to inspect unit properties and status carefully before invoking an edit.

The documented regular test command does not need systemd:

cargo test

The README says this includes unit tests, application-flow tests, and Ratatui rendering tests using `TestBackend`. That makes it the appropriate documented command for checking the crate in a non-systemd environment, including many CI containers.

A second suite targets real D-Bus behavior. The documented command is longer and deliberately runs ignored tests serially.

cargo test infrastructure::systemd_service_adapter::tests -- --ignored --test-threads=1

The host must be Linux with systemd, an active user manager, and both `systemctl` and `systemd-run`. The suite reads real system units and creates an isolated transient user service to exercise lifecycle operations. It then stops and removes the temporary service. The serial setting reduces concurrent interaction with that shared systemd test service, which is a sensible constraint for this suite. These tests can change real user-manager state, so they do not belong in an untrusted or production account without review.

Limits, packaging cost, and the systemctl alternative

The largest limitation is platform dependence. systemd-manager-tui is tied to systemd and D-Bus, so it does not address services managed by another init system. It also cannot manage a unit that the current bus connection is not authorized to query or control. The README does not describe privilege escalation, polkit integration, remote hosts, container configuration, or a web interface.

The interface is also intentionally narrower than the full `systemctl` command set. It documents a useful group of lifecycle and inspection actions, but it does not claim to reproduce every systemctl subcommand or option. For automation, `systemctl` remains the clearer primitive because commands can be placed directly in scripts, inspected in logs, and executed without a terminal interface. systemd-manager-tui is the different approach: it places systemd state, logs, properties, editing, and control inside a keyboard-driven TUI.

Maintenance is recent. The repository is not archived, and its last push was on 2026-10-10. Version 1.3.0 was released on 2026-10-10, after v1.2.5 from 2026-08-03. This does not remove the cost of tracking release notes or package updates, but it indicates current repository activity rather than an archived code line.

The project uses Rust edition 2024 and ships an MIT-licensed package. Its release build disables debug information, uses `opt-level = 3`, sets `codegen-units = 1`, enables link-time optimization, and strips symbols. Those settings favor a compact distribution binary at the cost of slower compilation. The MIT License permits use and modification under its terms, while distribution packages also carry systemd and D-Bus-related packaging implications. Those are project metadata facts, not legal advice.

Editorial conclusion

Adopt systemd-manager-tui if you routinely manage systemd system or user units and prefer a terminal interface to systemctl commands. Do not choose it for non-systemd init systems, hosts without suitable D-Bus access, or workflows that require graphical desktop integration. Verify first that the installation format matches your distribution and that the account can access the system or user bus required for the units you intend to control. For this release line, the repository is not archived and the last push was on 2026-10-10.

Frequently asked questions

Official sources

1. License: MIT
2. matheus-git/systemd-manager-tui on GitHub
3. Project website
4. README
5. Releases