> I have to look up the very fiddly and unintuitive systemd commands all the time. service start? service.foo start? start foo.service? Oh right, sudo systemctl start service.foo

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

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

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

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

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

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

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

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

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

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

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

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

Author here: Yeah, I agree.

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

> As a very occasional linux sysadmin just trying to make things work, the "typing at a console" systemd interfaces are not fun to work with. Maybe nobody should be doing that. In an enterprise, sure that's different. I think interfaces should be human, and linux should still be fun.

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

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

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

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.

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

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

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

    alias sc='sudo systemctl'

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

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

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

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

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