Show HN: Interactive systemd – a better way to work with systemd units (isd-project.github.io)

Looks nice.

One thing I found systemd really confusing was its treatment of ExecStop in a service script. ExecStart is the command to run when systemd starts the service at system boot up (or when a user tells systemd to start the service). However, ExecStop is run when the starting command has finished running. You have to set RemainAfterExit=yes to have the desired function of running the stop command on system shutdown or on user stopping the service. ExecStop is basically the "on-cleanup" event rather than "to-shutdown-the-service" event.

    enum Service {
        Exec { ExecStart: String, ... }
        Forking { ExecStart: String, ... }
        OneShot { ExecStart: String, ... }
    }

Love this. I use raw CLI commands until it hurts, and have recently embraced tools like lazygit/lazydocker to get visibility into otherwise opaque system/tree states, and it’s been a huge level-up.

I have several user and system level services I manage, but debugging them is tedious. Your opening line that lists common commands and their pain points really resonated with me.

I’m on NixOS, so editing immutable unit files directly won’t work, but the service discovery, visibility, and management will be really helpful. Nice work!

This looks very good, thanks for sharing! I maintain a similar project and working with the systemd/dbus APIs has been pretty painful; eager to try this and see what I can learn from it.

https://github.com/rgwood/systemctl-tui

At long last, systemd-client: merry meet! Next step is such a TUI for non-Linux such as macOS, FreeBSD, Windows. For macOS I use LaunchControl.app but it isn't a TUI.

Just one thing: I had to do

  $ uv tool install git+https://github.com/isd-project/isd

instead of

  $ uv tool install https://github.com/isd-project/isd/isd@latest

and uvx wouldn't work at all, version: uv 0.5.21. That said, uv is way more quick than pip(x) so I just switched.

So cool that with uv it becomes so easy to install such tools.

What's missing in the install routine is uv installing this tool ignoring the Python dependency. My box has 3.10 and isd won't work with it. Fixed with `-p 3.13` option. May be worth mention in the docs.

> If you ever became frustrated while typing:

Hey, that's me ! (And I love systemd !)

I haven't installed it yet so quick question: can it connect to remote host ? I often use systemctl --host <hostname> status foo.service (status, timers, logs etc. )

I can not install this stuff on remote servers and docker images. I would like multiple backbends to execute commands and gather informations (local, ssh, docker).

It should be installable locally, and run commands on remote machine via ssh! And via 'docker exec' commands.

> If you have nix installed, this AppImage will not work! Either use the nix or uv installation instructions!

Is this really true? I understand why it does not work on NixOS (I tried just out of curiosity and it seems like it is unable to exec the host systemctl for some reason) but I don't think there's any reason it wouldn't work on other OSes that merely have Nix installed.

Interestingly though, on Nix v2.24.11, I can't use the provided Nix command either:

    $ nix run https://github.com/isd-project/isd
    error:
           … while fetching the input 'https://github.com/isd-project/isd'
    
           error: Failed to open archive (Unrecognized archive format)

Even if that did work (you could adjust it into a Git URL to make it work) it would probably not be ideal since Nix has a native GitHub fetcher that is more efficient. I think this should be the actual Nix command:

    nix run github:isd-project/isd

Anyway, this is cool. I actually wanted to make a similar thing using systemd's DBus API and Qt instead of a TUI and even started writing code for it, and if you wanted to I'm sure you'd find that the DBus API probably provides all of the functionality you would need (admittedly it is a lot easier to just call `systemd -H` than to implement your own SSH tunneling, though.) It kind of frustrates me that systemd and modern Linux in general is absolutely teeming with data and interfaces that could be exposed and make administering systems, especially desktop systems that were traditionally very inscrutable, much easier. e.g. in the past, how did you know what was going on when an xdg autostart app failed? Now with systemd running xdg autostart apps in some desktops, it would be really easy to provide a GUI that can show you the failed autostarts and even provide a GUI log viewer, and yet somehow, such a tool does not seem to exist, at least in the realm of things that are maintained and relatively feature-complete. Rather frustrating.

Looks great, well done. It's a shame that it's needed at all. The vast majority of my interactions with systemd are trivial: (re)starting a service, looking at a log file to figure out what's wrong, and making sure a service starts on boot. I find it baffling that the ergonomics of systemd for those common tasks are so lacking. But the TUI seems to help, so thanks.

And sure, systemd it's more deterministic and includes the kitchen sink, unlike initd.

Thankfully these days I can automate most of such interactions out of existence, so I no longer feel the burning hatred that I once did. More like a smoldering ember.

How's security handled? Not in terms of system permissions which Linux handles well, but in terms of guarantees that it can't be hijacked and remotely controlled by an external attacker.

On search and editing system unit files:

1. My life improved a lot after I found that you can do "systemctl status $PID" and systemd will find what service (if any) is responsible for the process in question. This has been a life saver many, many times. But, more search would still be welcome, especially for cases when the system fails to boot, or fails to reach a particular target etc.

2. I think systemd didn't go far enough with unit files. The motivation was to escape the hell of Shell scripts, where each system was defined in its own unique way, and was failing in a dozen of unique ways. While, initially, it might have seemed that a simple INI-style format could manage to describe service requirements... I think, it's way overdue to realize that it doesn't. And sysadmins on the ground "fix" that by embedding more Shell into these configuration files, bringing us back to the many unique ways a service will fail. Perhaps, having a way to edit these unit files so that it doesn't expose the actual format may lead to improvement in the format (more structure, more types, templates).

This looks almost as easy to use as slackware’s init/syslog back in the Linux 0.9x days.

If you add a sane cli with tab completion support, it’ll come full circle.

Maybe a bit of a gross simplification, but would you say this is analogous to something like k9s for Kubernetes? It looks handy, to say the least.

Haha this is great. It’s funny that others also end up doing this enable, start, journalctl, start dance. Good stuff. I shall try it.

My only problem is that I wish there were a way to install it on my machine and have it connect to a remote systemctl but that probably is a lot of work to reliably work (port may not be open etc etc).

Nice! How did you find working with the Textual library?

Looks super cool, I've been working quite a bit with systemd recently, and typing systemctl and journalctl + their flags gets old rather fast.

Can it connect to remote hosts like you can with systemctl --host?

This looks super well done and polished. The rich docs are crazy detailed for something that was just released. You're really setting the bar for what other projects should do. Congrats!

Keep in mind, systemd is still a default-allow access control list (ACL) and has a very long road ahead in form of Linux security, as long as CAP_SYS_ADMIN continuea to exist.

May make it easier to customize but it doesn't close the security loopholea like SELinux, GRSecurity, TOMOYA, or AppArmor does.

https://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecu...

This is amazing, I had a bunch of work to do on some remote hosts this night and tried using isd as much as possible, to see how it can help me.

Some feedback :

- it is.. relatively slow ? especially when focusing on different panes (tab/shift+tab). on my machine it takes at least half a second to react

- the unit list is missing page-up/page-down handling

- in some unit attributes, the ordering of some values frequently changes (for example, on unstarted services, in `TriggeredBy`)

- it could be interesting to integrate the output of `systemd-analyse security`

Nice work !

Need to see this in action. The example videos overuse the fuzzy search for commands in my opinion. Makes it hard to concentrate what the actual action/information is when a huge part of the screen changes. Not to say I don’t like fuzzy searchable command prompts. But it can be clearer to either just type out a command or have a menu system. As I said I need to check this out in action for myself.

The security section is good to see. Thanks for that!

Isn't `service nginx status` a shorter way to do it? I've always done that instead of the longer systemctl commands.

Thank you for shipping this. Need to test it but going to add this to the deps bundle for my deployment service (relies heavily on systemd). Looks like it would make day to day maintenance/debugging far less of a headache.

Looks very useful. Standard tooling for systemd is such an annoying maze to navigate.

This would be extremely helpful. Although, I would love a feature where you can add different linux hosts and manage them all from a single place, using ssh