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.

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.

> 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. )

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.

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.

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.

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...

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).

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 !

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

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

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.

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!

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

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

Is there any way I can run a service before a given other service AND as late as possible (without rewriting the other service's unit file)?

I use systemd heavily. I'll definitely check this out!

The switching of command and service in the argument order from the init script days still catches me out.

foo restart vs restart foo

Out of curiosity, any tools that provide a systemd gui minus the fzf dependency?

Is there no GUI for SystemD?

This looks very nice, I’ll have to give it a try!

This looks really well done. Congratulations!

Why have you picked Python for this project? I feel like Rust/Go have better TUI ecosystems and the ability to use native bindings.

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).

kudos, this is super neat and useful !! Thank you

This looks neat. I have to look up the very fiddly and unintuitive systemd commands all the time. service start? service.foo start? start foo.service? Oh right, sudo systemctl start service.foo

And the feedback is so bad. It should know everything in its own config dir and tell me how to do what I want to do. Was it enabled? I forget. How do I look at logs? Oh right journalctl. Also the layout of things with lots of symlinks and weird directories in places that annoy my 90's linux sysadmin brain. Why am I looking at /lib/systemd/system

I am annoyed by the redundant "systemd/system" directory name every time I have to go there. At this point, just promote it to /etc/systemd and build a better CLI.

As a very occasional linux sysadmin just trying to make things work, the "typing at a console" systemd interfaces are not fun to work with. Maybe nobody should be doing that. In an enterprise, sure that's different. I think interfaces should be human, and linux should still be fun.

Why did a single person tossed out decades of CLI wisdoms devised by many gray-beards?

Bring back the verb-last CLI.

    systemctl rsyslog stop
    systemctl rsyslog start

Don't be suggesting `^op^art` over up-CtrlW This is worse than pacman.