Show HN: Interactive systemd – a better way to work with systemd units
208 comments
·January 18, 2025ww520
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.
Cyph0n
I think about them as “on start” and “on stop”.
It is important to keep in mind that systemd is tailored towards daemons. So if your service just runs a command that eventually exits, you need to explicitly tell systemd to treat it differently than a daemon.
Edit: As others noted, you’re probably looking for oneshot + RemainAfterExit.
rcxdude
It is a little asymmetric, because 'ExecStart' is actually normally 'Executable that is the service', not just script that starts the service, but I think that's a hangover from the self-daemonizing approach to init scripts.
Cyph0n
True, but it still makes sense to reason about them this way. Say you have an HTTP server:
- on start: start the server
- on stop: do nothing, because you are already terminating the server
But suppose you need to perform an additional task when the server is terminated. That is where you would add a ExecStop command or script.
wasted_intel
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!
kai-tub
I am also a NixOS user and this is exactly what motivated me to work on this project!
I am planning on adding some "guides" in the documentation but in short: You should check out `systemctl edit --runtime` for debugging units on NixOS. It makes debugging sooo much easier.
ripley12
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.
gurgeous
This is incredible! I will use this a ton. Only thing missing is a deb package...
Fnoord
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
$ uv tool install https://github.com/isd-project/isd/isd@latest
kai-tub
Yeah, silly me. It is fixed now, thanks for letting me know!
mahoro
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.
kai-tub
Hey, thanks for mentioning this! I have included the flag in the docs.
johnchristopher
> 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. )
kai-tub
Dang. I have never heard of `systemctl --host`. Sadly not. It is more or less a fancy wrapper around (the local) `systemctl`. But there is also an appimage that should make it (hopefully) easy to run it on remote servers.
Either way, feel free to open an issue and I will have a look at it.
diggan
> Dang. I have never heard of `systemctl --host`. Sadly not. It is more or less a fancy wrapper around (the local) `systemctl`.
Sounds like you could easily support it by letting users pass in $REMOTE_HOST and when you use your `systemctl` wrapper, add `$CMD --host=$REMOTE_HOST`, after that everything should work as before.
kai-tub
I will investigate it!
throeurir
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.
jchw
> 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)
nix run github:isd-project/isd
kai-tub
> 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.
Yeah, it get's complicated and I don't want to recommend it and explain the details. In short, I am creating the AppImage via nix. And the AppImage "mounts" (not overlays!) the AppImage's /nix/ directory. So calls from the TUI that would access /nix/ wouldn't go to the systems `/nix` directory, which leads to all kind of weird issues. For example, you could install your EDITOR via home-manager on Ubuntu. isd would start correctly because systemctl is "accessible" but if you open your EDITOR under `/nix` it wouldn't find it, which is super confusing as a user. -> So it is just easier to say to use the nix installation method if you are already using it :D
And sorry for the wrong docs, it is fixed now.
I also agree with your frustration. Personally, I would really enjoy working on such a tool but it wouldn't be an easy task, and who would support the work? This TUI had a manageable scope but it was still quite a bit of work. So I don't see myself investing too much into "higher-level interfaces".
PS: I have no idea why your post is ill-received :/
jchw
> In short, I am creating the AppImage via nix. And the AppImage "mounts" (not overlays!) the AppImage's /nix/ directory. So calls from the TUI that would access /nix/ wouldn't go to the systems `/nix` directory, which leads to all kind of weird issues.
That makes a lot of sense. There's not really much trivial that I think you can do to deal with that.
> PS: I have no idea why your post is ill-received :/
It's not really a big deal, I was just surprised and wondered if anyone who was compelled to vote down might come back to explain why.
jchw
I am completely confused as to why this comment seems to be poorly received. Can someone explain?
speed_spread
That may be a bit of nix backlash, don't sweat it.
I agree Linux could use better system APIs than "put file here" and "run these commands" which are much more error prone than making calls to properly documented interfaces.
elric
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.
kai-tub
I mean, I get why they don't want to "bloat" systemd with a complex/opinionated TUI, but I would've also really liked a more "upstreamed" interface. Though, I guess making systemd more beginner-friendly/accessible is not really that important for their funding?
gchamonlive
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.
kai-tub
Author here: I also find this an important thing to ask yourself when you are running applications/scripts that do anything with sudo and which is why I have written a fairly in-depth "Security" section on the isd documentation page:
https://isd-project.github.io/isd/security/
Let me know if anything is missing!
gchamonlive
As a suggestion, since your repo is open I think you can leverage sonarcloud without costs. It would make for another independent check that your code does what's intended and for instance won't ping a remote control server, either via dependency attacks or via malicious pull requests that could dodge reviews.
Where I work we also use defectdojo to catalogue and manage CVRs in our projects, but it's more involved to setup the testing pipeline and deploy the required services.
crabbone
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).
hedora
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.
I created a TUI for systemd/systemctl called isd (interactive systemd).
It provides a fuzzy search for units, auto-refreshing previews, smart sudo handling, and a fully customizable, keyboard-focused interface for power users and newcomers alike.
It is a more powerful (but heavier) version of sysz, which was the inspiration for the project.
This should be a huge timesaver for anybody who frequently interacts with or edits systemd units/services. And if not, please let me know why! :)