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

If I had to guess it's because of the 'service' command, which goes 'service foo start'.

It took me ages to unlearn that pattern for using systemctl, even though as you say: it's far more consistent

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}"
  

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/

For me:

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

and Ubuntu’s:

* service my-service stop

both lurk in my brain.

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.

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.

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

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.

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.

> 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

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
  

  /
  | etc
  | | cron.d
  | | cron.daily
  | | cron.hourly
  | | cron.monthly
  | | cron.weekly
  | | ...
  | | firewall
  | | firewalld

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.

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

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.

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.

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

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