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

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 · a year ago

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 · a year ago

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.

yread · a year ago

ExecStop works the way you want for type=forking

ww520 · a year ago

Still has the same problem even with type=forking. Only way to get it working was RemainAfterExit=yes

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

kai-tub · a year ago

> 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 · a year ago

> 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 · a year ago

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

speed_spread · a year ago

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.

wasted_intel · a year ago

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!

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 · a year ago

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

gurgeous · a year ago

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

Fnoord · a year ago

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.

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

mahoro · a year ago

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.

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

johnchristopher · a year ago

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

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 · a year ago

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

throeurir · a year ago

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.