30 ms·

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

546 points by kai-tub 2y ago

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! :)

heywire 2y ago
This looks very nice, I’ll have to give it a try!
greenavocado 2y ago
I use systemd heavily. I'll definitely check this out!
- kai-tub 2y ago
  Happy to hear! Please open an issue on GitHub if you encounter any silly alpha issues.
johnchristopher 2y 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. )
- kai-tub 2y ago
  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 2y 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.
    - kai-tub 2y ago
      I will investigate it! https://github.com/isd-project/isd/issues/6 https://github.com/isd-project/isd/issues/6
wasted_intel 2y 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!
- kai-tub 2y ago
  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.
johng 2y ago
This looks really well done. Congratulations!
renewiltord 2y ago
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).
- kai-tub 2y ago
  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
  - noisy_boy 2y ago
    Maybe you can keep it uniform by always presuming "host" as one of the parameters (and localhost just happens to be the default for it).
cdiamand 2y ago
The security section is good to see. Thanks for that!
- kai-tub 2y ago
  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!
ww520 2y ago
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 2y 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 2y 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.
    - Cyph0n 2y ago
      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.
      - ww520 2y ago
        Then ExecStop is basically on-cleanup, not to-stop. ExecStart really is to-start, not on-start. In the httpd server case, ExecStart runs the httpd command.
geenat 2y ago
Out of curiosity, any tools that provide a systemd gui minus the fzf dependency?
marginalia_nu 2y ago
Looks very useful. Standard tooling for systemd is such an annoying maze to navigate.
jchw 2y ago
> 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.
- jchw 2y ago
  I am completely confused as to why this comment seems to be poorly received. Can someone explain?
  - speed_spread 2y 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.
owyn 2y ago
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.
- mixmastamyk 2y ago
  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.
  - johnisgood 2y ago
    Yeah, and you can omit the ".service" suffix, and you could use ".timer" suffix, too, if you have a timer for that service. As much as I do not like systemd, I do not think its commands are an issue, and I use "systemctl status" and "journalctl" as well with some flags at times.
    - robinsonb5 2y ago
      "systemctl" would be less of an issue if "sysctl" didn't already exist and do something completely different.
      - johnisgood 2y ago
        Yes, it is something I had to learn in the very beginning, but I never made the mistake ever again.
throeurir 2y 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.
ripley12 2y 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 https://github.com/rgwood/systemctl-tui
- gurgeous 2y ago
  This is incredible! I will use this a ton. Only thing missing is a deb package...
airstrike 2y ago
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!
- kai-tub 2y ago
  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.
  - airstrike 2y ago
    Absolutely! Really well done. I now think you're the best person to do the same for ffmpeg lol
willm 2y ago
Nice! How did you find working with the Textual library?
- kai-tub 2y ago
  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!
btbuilder 2y ago
The switching of command and service in the argument order from the init script days still catches me out. foo restart vs restart foo
Fnoord 2y 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.
- kai-tub 2y ago
  Yeah, silly me. It is fixed now, thanks for letting me know!
hedora 2y ago
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.
jonwest 2y ago
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.
- wint3rmute 2y ago
  That was my first thought as well, seems to fill a very similar niche, just for systemd instead of kubernetes
- kai-tub 2y ago
  I have never used or touched k9s nor Kubernetes, so... Maybe?
abdellah123 2y ago
kudos, this is super neat and useful !! Thank you
yonatan8070 2y ago
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?
gchamonlive 2y ago
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 2y ago
  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/ https://isd-project.github.io/isd/security/ Let me know if anything is missing!
  - gchamonlive 2y ago
    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.
alpb 2y ago
Why have you picked Python for this project? I feel like Rust/Go have better TUI ecosystems and the ability to use native bindings.
- kai-tub 2y ago
  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.
elric 2y ago
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 2y ago
  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?
mahoro 2y 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.
- kai-tub 2y ago
  Hey, thanks for mentioning this! I have included the flag in the docs.
amelius 2y ago
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)?
- distype 2y ago
  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.
rglover 2y ago
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.
udev4096 2y ago
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
- eliaspro 2y ago
  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.
larusso 2y ago
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.
alduin32 2y ago
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 !
- kai-tub 2y ago
  - 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.
  - alduin32 2y ago
    I've opened an issue about the reordered attribute values (+ another bug I found). Tab pane switching stopped being slow (I suppose my laptop was simply overloaded, and I'm too used to things being fast even when it is).
egberts1 2y ago
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-grsecurity.html https://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecu...
- detuur 2y ago
  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.
  - egberts1 2y ago
    You read across as a security-indifferent.
- surajrmal 2y ago
  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.
egberts1 2y ago
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.
- crabbone 2y ago
  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.
  - egberts1 2y ago
    You must not be an sysadmin
    - detuur 2y ago
      Ah yes, famously one can only be a sysadmin if they're unable to use a different cli verb order. Come on now. Either present a real argument or accept the fact that tooling isn't forever going to be frozen to what you used in your 20's. Newer tooling uses newer best practices and the improved verb order is part of that.
    - crabbone 2y ago
      I work in a company that creates (admittedly crappy) product for sysadmins (I have no say in design though, so don't blame that on me). I work in the infra / automation, so close to sysadmin, but not quite. So, this isn't a foreign world to me... I still don't think that: 1. Starting a service is a big issue in general (most of the time this happens automatically anyways). 2. The command syntax of systemcl is defective in any way. Of all things that might be problematic with systemd, this is just not in the list at all. It's such a bizarre complaint to have... kind of like arguing whether "gray" or "grey" is the right way to spell it. Really, it's a whatever. There are much larger issues, even when it comes to comfort, not functionality of systemd tools. Like, for example, the autogenerated names of device units. I hate trying to recall the rules for writing these, and on top of that, having to escape characters just to type the unit's name. That's just a ridiculous design.
IshKebab 2y ago
Is there no GUI for SystemD?
crabbone 2y ago
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).
Saris 2y ago
Isn't `service nginx status` a shorter way to do it? I've always done that instead of the longer systemctl commands.
rwarfield 2y ago
I absolutely love this, and love it even more because of the Nix integration. Fantastic job.

546 points by kai-tub 2y ago

heywire 2y ago

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

greenavocado 2y ago

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

kai-tub 2y ago
Happy to hear! Please open an issue on GitHub if you encounter any silly alpha issues.

johnchristopher 2y 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. )

kai-tub 2y ago
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 2y 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.
  - kai-tub 2y ago
    I will investigate it! https://github.com/isd-project/isd/issues/6 https://github.com/isd-project/isd/issues/6

wasted_intel 2y 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!

kai-tub 2y ago
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.

johng 2y ago

This looks really well done. Congratulations!

renewiltord 2y ago

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

kai-tub 2y ago
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
- noisy_boy 2y ago
  Maybe you can keep it uniform by always presuming "host" as one of the parameters (and localhost just happens to be the default for it).

cdiamand 2y ago

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

kai-tub 2y ago
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!

ww520 2y ago

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 2y 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 2y 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.
  - Cyph0n 2y ago
    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.
    - ww520 2y ago
      Then ExecStop is basically on-cleanup, not to-stop. ExecStart really is to-start, not on-start. In the httpd server case, ExecStart runs the httpd command.

geenat 2y ago

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

marginalia_nu 2y ago

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

jchw 2y ago

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

jchw 2y ago
I am completely confused as to why this comment seems to be poorly received. Can someone explain?
- speed_spread 2y 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.

owyn 2y ago

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.

mixmastamyk 2y ago
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.
- johnisgood 2y ago
  Yeah, and you can omit the ".service" suffix, and you could use ".timer" suffix, too, if you have a timer for that service. As much as I do not like systemd, I do not think its commands are an issue, and I use "systemctl status" and "journalctl" as well with some flags at times.
  - robinsonb5 2y ago
    "systemctl" would be less of an issue if "sysctl" didn't already exist and do something completely different.
    - johnisgood 2y ago
      Yes, it is something I had to learn in the very beginning, but I never made the mistake ever again.

throeurir 2y 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.

ripley12 2y 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 https://github.com/rgwood/systemctl-tui

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

airstrike 2y ago

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!

kai-tub 2y ago
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.
- airstrike 2y ago
  Absolutely! Really well done. I now think you're the best person to do the same for ffmpeg lol

willm 2y ago

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

kai-tub 2y ago
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!

btbuilder 2y ago

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

Fnoord 2y 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.

kai-tub 2y ago
Yeah, silly me. It is fixed now, thanks for letting me know!

hedora 2y ago

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.

jonwest 2y ago

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.

wint3rmute 2y ago
That was my first thought as well, seems to fill a very similar niche, just for systemd instead of kubernetes
kai-tub 2y ago
I have never used or touched k9s nor Kubernetes, so... Maybe?

abdellah123 2y ago

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

yonatan8070 2y ago

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?

gchamonlive 2y ago

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 2y ago
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/ https://isd-project.github.io/isd/security/ Let me know if anything is missing!
- gchamonlive 2y ago
  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.

alpb 2y ago

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

kai-tub 2y ago
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.

elric 2y ago

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 2y ago
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?

mahoro 2y 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.

kai-tub 2y ago
Hey, thanks for mentioning this! I have included the flag in the docs.

amelius 2y ago

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

distype 2y ago
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.

rglover 2y ago

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.

udev4096 2y ago

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

eliaspro 2y ago
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.

larusso 2y ago

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.

alduin32 2y ago

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 !

kai-tub 2y ago
- 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.
- alduin32 2y ago
  I've opened an issue about the reordered attribute values (+ another bug I found). Tab pane switching stopped being slow (I suppose my laptop was simply overloaded, and I'm too used to things being fast even when it is).

egberts1 2y ago

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-grsecurity.html https://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecu...

detuur 2y ago
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.
- egberts1 2y ago
  You read across as a security-indifferent.
surajrmal 2y ago
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.

egberts1 2y ago

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.

crabbone 2y ago
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.
- egberts1 2y ago
  You must not be an sysadmin
  - detuur 2y ago
    Ah yes, famously one can only be a sysadmin if they're unable to use a different cli verb order. Come on now. Either present a real argument or accept the fact that tooling isn't forever going to be frozen to what you used in your 20's. Newer tooling uses newer best practices and the improved verb order is part of that.
  - crabbone 2y ago
    I work in a company that creates (admittedly crappy) product for sysadmins (I have no say in design though, so don't blame that on me). I work in the infra / automation, so close to sysadmin, but not quite. So, this isn't a foreign world to me... I still don't think that: 1. Starting a service is a big issue in general (most of the time this happens automatically anyways). 2. The command syntax of systemcl is defective in any way. Of all things that might be problematic with systemd, this is just not in the list at all. It's such a bizarre complaint to have... kind of like arguing whether "gray" or "grey" is the right way to spell it. Really, it's a whatever. There are much larger issues, even when it comes to comfort, not functionality of systemd tools. Like, for example, the autogenerated names of device units. I hate trying to recall the rules for writing these, and on top of that, having to escape characters just to type the unit's name. That's just a ridiculous design.

IshKebab 2y ago

Is there no GUI for SystemD?

crabbone 2y ago

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

Saris 2y ago

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

rwarfield 2y ago

I absolutely love this, and love it even more because of the Nix integration. Fantastic job.