[HN Gopher] Show HN: Interactive systemd - a better way to work ...
___________________________________________________________________
Show HN: Interactive systemd - a better way to work with systemd
units
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! :)
Author : kai-tub
Score : 316 points
Date : 2025-01-18 16:22 UTC (6 hours ago)
(HTM) web link (isd-project.github.io)
(TXT) w3m dump (isd-project.github.io)
| heywire wrote:
| This looks very nice, I'll have to give it a try!
| greenavocado wrote:
| I use systemd heavily. I'll definitely check this out!
| kai-tub wrote:
| Happy to hear!
|
| Please open an issue on GitHub if you encounter any silly alpha
| issues.
| johnchristopher wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| I will investigate it!
|
| https://github.com/isd-project/isd/issues/6
| wasted_intel wrote:
| 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 wrote:
| 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 wrote:
| This looks really well done. Congratulations!
| renewiltord wrote:
| 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).
| cdiamand wrote:
| The security section is good to see. Thanks for that!
| kai-tub wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| ExecStop works the way you want for type=forking
| ww520 wrote:
| Still has the same problem even with type=forking. Only way
| to get it working was RemainAfterExit=yes
| shawnz wrote:
| I think you actually probably want type=oneshot (and also
| RemainAfterExit=yes) for the kind of service you're
| describing
| brirec wrote:
| 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 wrote:
| Having different semantics with different proprieties on
| the same command is really confusing.
| shawnz wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| geenat wrote:
| Out of curiosity, any tools that provide a systemd gui minus the
| fzf dependency?
| marginalia_nu wrote:
| Looks very useful. Standard tooling for systemd is such an
| annoying maze to navigate.
| jchw wrote:
| > 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 wrote:
| I am completely confused as to why this comment seems to be
| poorly received. Can someone explain?
| speed_spread wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "systemctl" would be less of an issue if "sysctl" didn't
| already exist and do something completely different.
| johnisgood wrote:
| Yes, it is something I had to learn in the very
| beginning, but I never made the mistake ever again.
| kjkjadksj wrote:
| 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.
| viraptor wrote:
| 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 wrote:
| Sorry I conflate the two since they share a lot of
| similarity. Launchd is what I use as its a macos system.
| MrDrMcCoy wrote:
| > 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.
| Denvercoder9 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| zamadatix wrote:
| 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.
| Denvercoder9 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I'm not expressing expectations systemd change this for
| everyone or this is something I'm expecting to become
| pleased with by the end of the theard. It's just a note
| of my personal biggest annoyance with the systemd
| commands and outputs. The ability to externally create a
| personal bespoke workaround (something for which I try to
| avoid for various unrelated reasons) to the particular
| displeasure with the way the tool is built does not
| change my displeasure with the part of the tool itself -
| nor does it mean you have to agree!
| kai-tub wrote:
| Nice! I didn't know that was an option. Definitely
| something I should make configurable in `isd` :+1:
| SJC_Hacker wrote:
| > 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
| kristopolous wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pkkm wrote:
| > 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
| kstrauser wrote:
| For me:
|
| * /etc/init.d/my-service stop
|
| and Ubuntu's:
|
| * service my-service stop
|
| both lurk in my brain.
| pkkm wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ripitout wrote:
| 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.
| godelski wrote:
| 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/
| IgorPartola wrote:
| 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.
| brontitall wrote:
| Doing it the way it does allows specifying multiple
| services.
|
| systemctl status myapp mydb
| autoexec wrote:
| Why not allow for both and accept the option at any
| location?
|
| Something like:
|
| systemctl --stop myapp mydb
|
| systemctl myapp mydb --stop
| bronson wrote:
| unnecessary flexibility brings unnecessary bugs
| gf000 wrote:
| Press alt+B twice?
| smallmancontrov wrote:
| 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)
| kjellsbells wrote:
| 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.
| emmelaich wrote:
| It actually should be possible to switch them around. No-
| ones going to call their service 'stop' or 'service' right?
| frizlab wrote:
| It's because service was the other way around, I'm sure.
| DHowett wrote:
| systemd services are named "foo.service", and you do not
| need to specify the ".service" in almost any case.
| tremon wrote:
| 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)
| PhilipRoman wrote:
| I just wish systemd allowed abbreviations for the subcommands,
| like "ip" (and git, for long options).
| kai-tub wrote:
| 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 :)
| throeurir wrote:
| 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 wrote:
| 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 wrote:
| This is incredible! I will use this a ton. Only thing missing
| is a deb package...
| airstrike wrote:
| 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!
| Fnoord wrote:
| 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 wrote:
| Yeah, silly me. It is fixed now, thanks for letting me know!
| willm wrote:
| Nice! How did you find working with the Textual library?
| btbuilder wrote:
| The switching of command and service in the argument order from
| the init script days still catches me out.
|
| foo restart vs restart foo
| hedora wrote:
| 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 wrote:
| 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 wrote:
| That was my first thought as well, seems to fill a very similar
| niche, just for systemd instead of kubernetes
| abdellah123 wrote:
| kudos, this is super neat and useful !! Thank you
| yonatan8070 wrote:
| 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 wrote:
| 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 wrote:
| 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!
| alpb wrote:
| Why have you picked Python for this project? I feel like Rust/Go
| have better TUI ecosystems and the ability to use native
| bindings.
| elric wrote:
| 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.
| mahoro wrote:
| 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.
___________________________________________________________________
(page generated 2025-01-18 23:00 UTC)