Show HN: Interactive systemd – a better way to work with systemd units (isd-project.github.io)

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.

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.

That makes a lot of sense. There's not really much trivial that I think you can do to deal with that.

> PS: I have no idea why your post is ill-received :/

It's not really a big deal, I was just surprised and wondered if anyone who was compelled to vote down might come back to explain why.

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.

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.

Yeah, tell me about it.

We had a production-down support ticket filed for one of the things that I work on at $DAYJOB. The customer's VM's disk was full. Why? Because the 'timer unit' that was supposed to run logrotate every day had never been run and was never scheduled to run. (The VM had been up for a month at this point.) No other customers had ever reported this issue, and we'd not changed anything about that timer unit or what it is supposed to run in ages.

No amount of gyration or agitation with 'systemctl' and friends OR rebooting of the VM kicked the cron replacement into proper functioning. 'logrotate' was simply never being scheduled to run. This fucker was WEDGED, and the tools weren't helping us understand why.

We read through all the docs on all the various kinds of units and don't see what we're doing wrong. We do a BUNCH of digging, and find an -IIRC- open Github issue from years back where someone was running into this problem. More or less the last word on the issue was Poettering saying something like "Well... actually, now that we've said that that particular cascade of options isn't actually supposed to work, now I'm not so sure that they're NOT supposed to work.". And that was -apparently- that.

IMO, when your cron replacement can be easily configured in such a way as to never even try to run the thing that you scheduled it to run, you really need to go back and rethink how you've built your cron replacement.

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

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

How about

systemctl status foo | tail

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.

This wouldn't be my problem with systemd. Not by a long shot.

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

and Ubuntu’s:

* service my-service stop

both lurk in my brain.

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/

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

I'm used to `service` command, so I have muscle memory which `systemd` breaks. The way `systemd` commands are laid out is better, it just messes with `service` command muscle memory.

Many (most?) of us are all over the place, expected to “wear many hats” and aren’t in a single IDE or language all day every day. Certainly if I were a “Linux admin” I would have systemd pretty committed to memory. Anyone else probably wouldn’t.

sudo service my-service stop

alias s=sudo systemctl status alias r=sudo systemctl restart

And if I'm only working with one service, I'll throw the service name in there too.

Where I work we also use defectdojo to catalogue and manage CVRs in our projects, but it's more involved to setup the testing pipeline and deploy the required services.