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

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.

ExecStop works the way you want for type=forking

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.

This is incredible! I will use this a ton. Only thing missing is a deb package...

Yeah, silly me. It is fixed now, thanks for letting me know!

Hey, thanks for mentioning this! I have included the flag in the docs.

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.

> 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 :/

I am completely confused as to why this comment seems to be poorly received. Can someone explain?

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?

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!

That was my first thought as well, seems to fill a very similar niche, just for systemd instead of kubernetes

I have never used or touched k9s nor Kubernetes, so... Maybe?

Maybe it is possible with `systemctl --host`... Though, I would have to make quite a few changes to the UI design since it would mean that there are "multiple modes". One for local and multiple remotes. So... Check back in a month or so :D

It was great! The extensive documentation and the vast amount of widgets were definitely the main reasons why I have chosen to do it in Python/Textual rather than other languages/libraries.

Though I don't agree with all design decisions, and there are some bugs, having such well-maintained documentation and clean repo makes it easy to dive into the project and understand what is going on and how other components are built.

Thanks for the library!

Thanks!

I've put quite a lot of work into it and wanted the project to give a good first impression. This was important to me since I believe these "niche" TUI libraries need to immediately show what problems they are solving or how they save time, as users need a reason to _use_ an additional abstraction layer.

Honestly it's not all or nothing. It really depends on your threat model. If you assume all native code is both not malicious and incapable of being compromised to run untrusted code then the existing model works. At that point it's more important to focus your security efforts on how native code ends up running, and therefore the distro specific packaging ecosystem.

Now for many that threat model is not sufficient as they both run increasingly less trustworthy software, obtained by less trustworthy mechanisms such as npm or off a website, or simply want to protect against bugs that cause otherwise non malicious software from being compromised and resulting in security incidents. I'm in this latter camp but we can't ignore the fact that there are many who happily operate in the former. There also exist solutions such as we browsers with their sandboxes and VMs that somewhat fill the requirements for running untrusted software for these individuals.

Yes yes and a reminder that BSD Jails are better than anything Linux does and a bunch of other dead horses we like beating on the regular around here.

Which is a fanciful way of saying that I don't understand the relevance of your comment at all to the topic at hand, which is an interactive frontend.

- That the tab pane switching is the slow part is a bit weird. Is there a difference when you see all units and a subset of units? Maybe open an issue and I can provide more possible settings that could be changed.

- Jep, page up/down handling will be added. Thanks!

- Not quite sure when this happens. Maybe an example screen shot (before/after) could help?

- Yeah, that is definitely on the roadmap.

Funny that you mention that. I honestly thought not too many people would care about it.

Though I am by far no security specialist. Please let me know where I can improve the section!

Most systemd functionality has built-in support for targeting remote hosts and local machines (containers, VMs) and mostly utilizes SSH under the hood to do so.

Check the -H and respective -M flags of many systemd CLI utilities.

Happy to hear!

Please open an issue on GitHub if you encounter any silly alpha issues.

You can override the other unit without rewriting. Place you config here.

> /etc/systemd/system/<unit>.service.d

I've used PartOf to enforce "dependency". Lots of other ways to enforce order and dependency once you have the override in place.

Hey, mostly because the underlying TUI framework (textual) is _amazing_.

Not gonna lie, I am not a big fan of Python anymore because of the dependency hell you can run into when working with CUDA libraries but uv is a breath of fresh air and textual is just sooo easy.

Don't get me wrong, I am not saying that I would never consider rewriting it in Rust or Go, but the documentation and guides from Textual were great resources and the creator, Will, also seems like a really nice guy :D

Edit: To be explicit, I believe that Python has currently the most advanced and accessible TUI ecosystem. At least, that was my impression after checking a few examples on an afternoon.

> 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

I don't get this complaint. It's the same order as almost every other command-line utility that has subcommands: <command> <subcommand> <thing to operate on>. To me, that kind of consistency is very intuitive.

    systemctl stop my-service
    systemctl status my-service
    git add my-file
    git remote remove upstream
    apt install my-package
    docker run my-container
    adb push local-file remote-file

My biggest annoyance is "systemctl status" gives you just enough of the service's log to make the output take up most of the terminal each time you run it but never enough of the service's log to get a useful picture of what's actually happened with the service lately.

Not to mention unless the problem with the service completely prevented it from running (it advises some commands to run in that case) you're supposed to just always remember "journalctl -xeu $SERVICE" was the incantation, less you want to go look up the flags again or manually parse the entire "journalctl" output.

Overall I generally like systemd though. The syntax can just be a burden sometimes.

> I am annoyed by the redundant "systemd/system" directory name

It's not redundant, you also have /etc/systemd/user (and /lib/systemd/user) where units that run in the user context (as opposed to system-wide context) are stored.

This is why I have instated a policy of using systemd --user services whenever possible.

If you don't need elevated permissions this is ideal.

All you have to do is enable linger using loginctl if you want your service to auto start as the user on boot unattended.

Your user services live in ~/.config/systemd/user

I find that at least systemd means that it's consistent across distros. I spent way more time looking up this kind of thing when every distro rolled their own init system.

Author here: Yeah, I agree.

It is a bit weird. On the one hand, I understand that it makes sense to have [command] [verb] [object] on a "logical" level and that viewing logs should be a separate command (`journalctl`), but it is definitely not ergonomic. Especially if you frequently have to switch between start/stop/restart.

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

This was precisely the case for me. I "enjoy" playing around with systemd and am super interested in better understanding it, but the feedback loop just felt sooo slow. So hopefully this TUI can make it "fun" again :)

It is a bit crazy to me how everyone says “dont use cron systemd is in now” but cron just does what it says on the tin with no problems. I have lines that work fine ran in script or on my crontab but when wrapped in a launchd command no longer work (log says things work until the db is to be updated which tells me launchd ran processes lack sufficient permissions perhaps to update my db but its not clear why this is the case or how I can elevate launchd sufficiently.

Fiddly and unintuitive? A lack of exposure to something does not really allow room for valid criticism of the thing.

Just a tip, if you remember the service name, status will show the directory the unit file is in. That will hopefully get you over your issues with directories. Complaining about Linux directories seems weird though. Have you looked at... anything else at all?

I just wish systemd allowed abbreviations for the subcommands, like "ip" (and git, for long options).

By the time you have it all memorized, they'll change it. Again. Because... because.

I haven’t had much trouble with the cli, but it is kinda wordy. I made this alias:

    alias sc='sudo systemctl'

Now it matches the sc utility introduced in Windows many years back. Then remember the verb goes first.

I am going to be that guy, but I went full runit for similar reasons.

Give me files for my logs, give me a single place for my service definitions, be simple.

After years of systemd, I have never really "got it", while it took a weekend for runit.

It's not always our choice, corporate world is something else, I know...

Because this is awful? The way most other tools work is <command> <subcomand> <sub-subcommand> --option=argument argument.

There are so many ways to recall the command you typed from history... I don't understand your complains at all.

I think this isn't shoddy engineering; I think you disagree with a design tradeoff that was consciously made here.

If CLIs are designed around facilitating the easiest means of editing the most commonly-edited word, different programs will end up with semantically very different CLIs. In some programs, the "noun" (e.g. file path) will be the thing most frequently edited. In some others, like systemctl, it'll be the "verb", like start/stop. That means that different programs designed around this principle will be semantically extremely inconsistent with each other.

On the other hand, if consistency of "base_command sub_command --subcommand-arg sub_sub_command --option argument" is taken as the guiding principle, many different tools will act semantically similarly. This enables unfamiliar users (talking first-time users or people who have just opened the manpage for the first time) to intuit the right way to present commands to those tools, rather than expecting them to memorize (or re-look-up as needed) each one's specific semantics.

While there's merit to both, I think the second one--systemd's CLI approach--is better. Put another way: the user-centric and consistent (with other applications) design are sometimes at odds in this way. A tool that is hyper-focused on optimizing the most common tasks for its (power) users risks oddball status and hostility to new users. It's important to pick a point on the spectrum that appropriately balances those two concerns. Python ("There should be one-- and preferably only one --obvious way to do it") and the Apple HIG ecosystem both understand the truth of this: that it is sometimes necessary to trade away efficiency for familiarity/consistency. There's a reason Perl languished while Python grew.

Like, I get it. I've been a sysadmin/devops for decades, and the paper cuts add up. But it's easy to forget the paper cuts I'm not getting: modern tools are (generally, with exceptions) more consistent; there are fewer commands that are resistant to memorization and need to be looked up each time; fewer commands that lead to questions like "wait, is it 'cmd help subcommand', 'cmd --help subcommand', or 'cmd subcommand --help'? Am I going to have to Google how to get the help output of this command?"

Cause you can manipulate multiple services in a single command? Not a big deal when you're looking at one or two services but when you've got a 5 to 15 interlinked and interdependent services and in situations where you may not want to restart everything, it's nice to just have one CLI with tab completion to deal with that.

Are there other cases of verb-last besides pre-systemd init systems?

apt-get/yum/dnf install foo git add file

And the normal CLI utilities: rm/touch/cat/ls/mv/cp etc are all verbs, and they act on nouns that come last.