• owyn 5 hours 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.

    • pkkm 3 hours ago

      > 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
      • IgorPartola an hour ago

        When it comes to starting and stopping services I want the verb to go last. Way easier to press up, backspace backspace backspace o p to change service ssh start to service ssh top. This is a frequent pattern I follow as I start/stop/restart/reload. Having to go back at least one word adds keystrokes that aren’t necessary.

        • kjellsbells 16 minutes ago

          I agree, but here's a handy Bashism:

          ^art^op

          Converts the "start" in "foo start bar" to "stop", ie runs "foo stop bar". Append :p to do the substitution but print the command instead of running it.

          • brontitall an hour ago

            Doing it the way it does allows specifying multiple services.

            systemctl status myapp mydb

            • autoexec 17 minutes ago

              Why not allow for both and accept the option at any location?

              Something like:

              systemctl --stop myapp mydb

              systemctl myapp mydb --stop

              • bronson a minute ago

                unnecessary flexibility brings unnecessary bugs

            • gf000 an hour ago

              Press alt+B twice?

              • smallmancontrov 38 minutes ago

                Alt + Bikeshed?

                (Kidding aside, quick reminder that on Mac you have to enable Settings>Profiles>Keyboard>Use Option as Meta key, or else Alt doesn't work)

            • kstrauser 3 hours ago

              For me:

              * /etc/init.d/my-service stop

              and Ubuntu’s:

              * service my-service stop

              both lurk in my brain.

              • pkkm 2 hours ago

                Sure, it's different from the old way, but I don't think "unintuitive" is the right word for that. systemd forced people to change their habits so that it could be more intuitive. Of course, people are going to disagree about whether it was worth it - it's the age-old question about breaking backwards compatibility for the sake of minor improvement. Personally, I got used to it pretty quickly and I like it more than the old commands now.

                • bbarnett 2 hours ago

                  Yet, the "ease" of use is a joke. Every try to stop and start a service at different points? At points you choose? Have fun!

                  Ah well, it's all been said before.

                  • kstrauser 2 hours ago

                    Yeah, I gave up resisting and I’m rolling with it. Ok, fine, this is the way now.

                    And yet my fingers still want to type it the other way.

                • godelski 2 hours ago

                  I feel the same way. The big part for me is that it tells us that owyn doesn't use tab completion if they're forgetting about the ".service" part. Sure, I don't remember either, I don't have to.

                  I'll add the abstraction for anyone confused

                    program [command [subcommand]] [flags] [object]
                    e.g.s
                    systemctl status sshd.service
                    systemctl enable --now sshd.service
                    touch -c test.sh
                    echo 'Hello World'
                    echo "Hello ${USER}"
                    
                  Anything in brackets is optional and might not appear or be available. By command I mean a category of commands. Such as 'pip install' vs 'pip uninstall', which are sub-programs inside the main program. But this can have layers such as 'uv pip install'. Often flags can be used in any order because you'll just loop over all the arguments but this is still the standard order.

                  There's also the two actor pattern

                    program [command [subcommand]] [flags] source destination
                    e.g.s
                    cp /foo/bar/baz.txt "${HOME%/}/"
                    scp -i "${HOME}/.ssh/foo" ${HOME}/to_upload.sh user@remote:~/
                    dd if=/dev/urandom of=/dev/diskToDestroy
                    rsync /mnt/hdd1/ /mnt/hdd2/
                  • ripitout 2 hours ago

                    Plus, you could always write a quick shell script to swap the arguments if it detects this specific failure. Inability to remember or learn which commands expect which arguments is, at some point, not the responsibility of the software to fix. Unfortunately, this field does necessitate some amount of memorization and ability to problem-solve.

                    • frizlab an hour ago

                      It’s because service was the other way around, I’m sure.

                      • DHowett an hour ago

                        systemd services are named "foo.service", and you do not need to specify the ".service" in almost any case.

                        • tremon 34 minutes ago

                          They're referring to Debian's service(8) command.

                            NAME
                                 service - run a System V init script
                            SYNOPSIS
                                 service SCRIPT COMMAND [OPTIONS]
                          
                          (the manpage wasn't updated, but the same command also supports systemd services nowadays)
                    • zamadatix 4 hours ago

                      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.

                      • kristopolous 3 hours ago

                        it's the same mentality that brought us the git design - the easiest, least typing options are rarely, if ever the thing you want to do.

                        Instead, these invocations give cryptic messages, throw errors, or sometimes, even break things.

                        The most common and helpful things are hidden deep behind multiple flags and command line arguments in manuals that read like dictionaries more than guides.

                        I'm always at a complete loss as to how such decisions are made. For instance, "git branch -vv" is the useful output you would like to see, every time, that should be "git branch". Why not make the current output, "git branch -qq"? Is a humane interface too much to ask for? Apparently...

                        I know people defend this stuff, but as a senior engineer in programming pits for 30 years, they're wrong. Needless mistakes and confusions are the norm. We can do better.

                        We need to stop conflating elitism with fucked up design.

                        • godelski an hour ago

                            > Why not make the current output, "git branch -qq"? Is a humane interface too much to ask for? Apparently...
                          
                          Yes, it is too much.

                          You have the wrong mentality, and I hope this can help make your life easier. Programs are made so that the simplest option is the base option. This is because there is a high expectation that things will be scripted AND understanding that there is a wide breadth of user preference. There's an important rule

                            DON'T TRY TO MAKE A ONE SIZE FITS ALL PROGRAM
                          
                          Customization is at the root of everything. We have aliases that solve most of the problems and small functions for everything else. You default to an non-noisy output, showing only __essentials__ and nothing more unless asked. Similarly, you do no filtering other than hidden files. This way, everyone can get what they want. Btw, this is why so many people are upset with default options on things like fdfind and ripgrep.

                          For your problem with git, there are 2 solutions you have.

                            # alias git branch using git
                            git config --global alias.branch 'branch -vv'
                          
                            # write a simple function and add to .bashrc or .zshrc or .*rc
                            git() {
                                case "$1" in
                                    branch)
                                        shift
                                        command git branch -vv "$@"
                                        ;;
                                    *)
                                        command git "$@"
                                        ;;
                                esac
                            }
                          
                            > We need to stop conflating elitism with fucked up design.
                          
                          The design isn't fucked up, it is that you don't understand the model. This is okay. You aren't going to learn it unless you read docs or books on linux. If you learn the normal way, by usage, then it is really confusing at first. But there is a method to the madness. Things will start making more sense if you understand the reason for the design choices. (In a sibling comment I wrote the abstraction to command patterns that makes the gp's confusion odd. Because systemd follows the standard)

                          Side note: if you try to design something that works for everyone or works for the average person, you end up designing something that is BAD for most people. This is because people's preference is not uniformly distributed, meaning the average person is not representative of any person in the distribution. This is because anything that is normally distributed has its density along the shell while a uniform distribution has a uniform density all throughout it.

                          • nativeit an hour ago

                            Fully this. For all its foibles, Linux was built to never presume too much, and its users tend to be power users who will almost certainly have dotfiles to tune their systems to their needs. In the context of making choices that will necessarily be universal, I admire how thoughtfully most standard Linux packages have been designed to never interfere with the users’ intentions.

                            • godelski an hour ago

                              And to all the linux noobies[0], you'll be a hell of a lot more efficient if you learn the philosophy of the design early. It will make it so that you can learn a new command and instantly know how to use several options. It will dramatically reduce the number of things you have to learn. I also HIGHLY suggest learning a bit of bash scripting.

                              Take a look at the manual

                                https://www.gnu.org/software/bash/manual/html_node/index.html
                              
                              and bookmark "Bash Pitfalls"

                                https://mywiki.wooledge.org/BashPitfalls
                              
                              Live in the terminal as much as you can. It is harder at first, but you will get huge boosts in productivity quicker than you would know it (easily <2 weeks). It sucks doing things "the hard way" but sometimes that comes with extra lessons. The thing is, those extra lessons are the real value.

                              [0] no matter how many years you've been using it there's no shame in being a noobie

                            • kristopolous an hour ago

                              You're fundamentally misunderstanding things.

                              If every person has the same point of confusion than they are not the problem, it's the thing that refuses to change for whatever reason.

                              The method is the madness.

                              There's better ways to do things and calling people naive for suggesting them is the problem.

                              And about your side note, no. For example, when people checkout a branch, they want it to track the remote branch. That's the 99.9% use case. It should be the default.

                              The default journalctl should be a useful log showing where things have failed, that's why people are invoking it.

                              Also there's plenty of counterexamples that are sensible. When I do "ping host" it genuinely, pings the host. When I do "ssh host" it genuinely, ssh's into the host.

                              I didn't have to specify say, the encryption algorithm, that I want a shell, use say, "--resolve=dns" to specify the hostname resolution... It has sensible defaults that mostly do what people intend.

                              There's things like certbot, apt, Tune2fs, mkfs, awk, cut, paste, grep, sort, so many reasonable things. Even emacs is reasonable.

                              But systemd and git, nope.

                          • Denvercoder9 4 hours ago

                            In case you don't know, you can use the `-n` argument to `systemctl status` to tweak the log output, e.g. `-n0` to disable the log output and `-n40` to get more than the default 10 lines.

                            • zamadatix 3 hours ago

                              That's a great option to tweak the behavior and I hadn't known about it (or if I ever had, I'd well forgotten). Thanks!

                              From the man page it ?looks like? if you want reverse or full then it's still off to the journalctl command and arguments but at least "-n9999" is better than "always 10 lines".

                              • godelski an hour ago

                                FWIW, I don't want that behavior. 10 lines is great for my usage.

                                And IIRC you can change the default behavior. In the worst case, just alias it if it is bothering you that much.

                                • zamadatix 20 minutes ago

                                  I'd assume at least some people like the behavior or it wouldn't've been made that way. No default makes everyone happy of course but the unique mix of command outputs even though the options controlling it vary between them seems to be a common enough qualm to be alright to mention.

                                  I'd rather be aware of the rough spots of the super common tools I use (systemd, git, grep, etc) but just learn the best ways it offers to deal with them over maintaining a long list of bespoke wrappers which don't apply or translate outside my personal usage. Some tools do a better job of being consistently flexible for that kind of usage, overall systemd does alright... it's just so large there's bound to be something.

                                  To be clear I'm not expressing an expectation systemd change or that this be something which I expect to become happy with by the end of this thread. It's just a note of my personal biggest annoyance with the systemd commands and outputs.

                              • kai-tub an hour ago

                                Nice! I didn't know that was an option. Definitely something I should make configurable in `isd` :+1:

                              • SJC_Hacker 3 hours ago

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

                                How about

                                systemctl status foo | tail

                              • Denvercoder9 4 hours ago

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

                                • godelski an hour ago

                                  It's also worth noting that this is a fairly standard pattern in /etc

                                    /
                                    | etc
                                    | | fail2ban
                                    | | | action.d
                                    | | | fail2band.d
                                    | | | filter.d
                                    | | | jail.d
                                    | | ssh
                                    | | | ssh_config
                                    | | | sshd_config
                                    | | systemd
                                    | | | network   # network wide context
                                    | | | nspawn    # containers
                                    | | | system    # system wide context
                                    | | | user      # user wide context
                                    
                                  Personally I like it more than

                                    /
                                    | etc
                                    | | cron.d
                                    | | cron.daily
                                    | | cron.hourly
                                    | | cron.monthly
                                    | | cron.weekly
                                    | | ...
                                    | | firewall
                                    | | firewalld
                                  
                                  Keeps things less cluttered. Hierarchical categorization is >> than lateral
                                • rcxdude 4 hours ago

                                  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.

                                  • greenavocado 4 hours ago

                                    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

                                    • bityard an hour ago

                                      I used to do this but frankly it's easier to run a system-level unit as whatever user you want and keep all the files in /etc instead of scattered around /home.

                                      The user-level units are most useful when running an actual multi-user system. If you trust your users to not abuse them, anyway.

                                    • kai-tub an hour ago

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

                                      • PhilipRoman 2 hours ago

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

                                        • mixmastamyk 5 hours 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 5 hours 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 5 hours ago

                                              "systemctl" would be less of an issue if "sysctl" didn't already exist and do something completely different.

                                              • johnisgood 5 hours ago

                                                Yes, it is something I had to learn in the very beginning, but I never made the mistake ever again.

                                          • kjkjadksj 4 hours ago

                                            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.

                                            • MrDrMcCoy 18 minutes ago

                                              > cron just does what it says on the tin with no problems.

                                              I can name a rather large problem with cron that systemd timers solve handily: long-running job duplication. When jobs take longer to run than the space between their triggering times, duplicates start piling up. I've had to rescue numerous systems from such states, which are difficult to detect until things have gotten quite bad. Sure, you can write a bunch of boilerplate to handle this yourself with cron, but with systemd timers it's all handled for you along with other niceties like capturing all output in journald and ensuring that the next run starts at soon as possible.

                                              • viraptor 2 hours ago

                                                Launchd is not used in systemd - why would anything be wrapped in it? The config is simple - User for the user and Group for the group. You can print it the result of "id" if you're not sure what the result is.

                                                • kjkjadksj 32 minutes ago

                                                  Sorry I conflate the two since they share a lot of similarity. Launchd is what I use as its a macos system.

                                            • ww520 6 hours 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 5 hours 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 4 hours 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 4 hours 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 4 hours 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.

                                                      • Cyph0n 3 hours ago

                                                        If that helps you understand it better, then sure.

                                                        All I am trying to say is that the name of the option makes sense as-is: it literally runs the provided command(s) on service stop (“execute on stop”).

                                                        Similarly, ExecStart literally means command(s) to execute on start.

                                                        If the command runs a blocking daemon/server (usually the case), then the server will be implicitly stopped by definition - because if you’re stopping the systemd service, you’re interrupting any commands that are still running/blocking.

                                                • yread 5 hours ago

                                                  ExecStop works the way you want for type=forking

                                                  • ww520 5 hours ago

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

                                                    • shawnz 5 hours ago

                                                      I think you actually probably want type=oneshot (and also RemainAfterExit=yes) for the kind of service you're describing

                                                      • brirec 5 hours ago

                                                        This was ultimately what I needed to do when I wrote a systemd service that managed some firewall rules. It really was a footgun though, what with having essentially different meanings/purposes for ExecStop whether you’re doing a Type=forking, a Type=oneshot, or a Type=oneshot with RemainAfterExit=yes.

                                                        And relatedly, I honestly have no idea when I’d want to use ExecStartPre, or multiple ExecStarts, or ExecStartPost, and so on.

                                                        • ww520 4 hours ago

                                                          Having different semantics with different proprieties on the same command is really confusing.

                                                          • shawnz 4 hours ago

                                                            I would argue the semantics of ExecStop are always the same. It's the command that's executed to stop the service. On the other hand, what it means for a service to be "running" or "stopping" naturally depends on what type of service it is (i.e., is it a daemon or not?)

                                                            • ww520 4 hours ago

                                                              > the command that's executed to stop the service

                                                              That’s what is assumed. But in reality it runs after the started process stops.

                                                              • shawnz 3 hours ago

                                                                Yes, so whether the service is stopping as a result of the process exiting, or whether you requested the service to stop manually, it will run the ExecStop in either case.

                                                                That makes sense to me personally. What would be the more intuitive design in your mind?

                                                            • yencabulator 2 hours ago

                                                              Think of it as an enum, Type branches the logic.

                                                                  enum Service {
                                                                      Exec { ExecStart: String, ... }
                                                                      Forking { ExecStart: String, ... }
                                                                      OneShot { ExecStart: String, ... }
                                                                  }
                                                              
                                                              You can argue that sometimes that ExecStart could be a different term, but it'd still end up being the same across multiple enum variants.
                                                  • mahoro 40 minutes 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.

                                                    • wasted_intel 6 hours 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 6 hours 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.

                                                      • elric an hour 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.

                                                        • Fnoord 4 hours 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 an hour ago

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

                                                          • ripley12 5 hours 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 4 hours ago

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

                                                            • throeurir 5 hours 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.

                                                              • johnchristopher 6 hours 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 6 hours 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 6 hours 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.

                                                              • gchamonlive 3 hours 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 an hour 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/

                                                                  Let me know if anything is missing!

                                                                • yonatan8070 3 hours 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?

                                                                  • hedora 3 hours 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.

                                                                    • cdiamand 6 hours ago

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

                                                                      • kai-tub 6 hours 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!

                                                                      • jonwest 3 hours 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 3 hours ago

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

                                                                        • airstrike 5 hours 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!

                                                                          • marginalia_nu 6 hours ago

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

                                                                            • jchw 5 hours 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 an hour ago

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

                                                                                • speed_spread 24 minutes 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.

                                                                              • willm 4 hours ago

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

                                                                                • alpb 2 hours 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.

                                                                                  • btbuilder 4 hours 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

                                                                                    • geenat 6 hours ago

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

                                                                                      • greenavocado 6 hours ago

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

                                                                                        • kai-tub 6 hours ago

                                                                                          Happy to hear!

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

                                                                                        • abdellah123 3 hours ago

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

                                                                                          • heywire 6 hours ago

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

                                                                                            • johng 6 hours ago

                                                                                              This looks really well done. Congratulations!

                                                                                              • renewiltord 6 hours 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).