OpenWRT is a mess. It started as a small distro for routers, but it stopped being that long ago.
Now it can host telephony services, full-blown Docker orchestration systems, etc. So you get all the pleasures of complex systems running on antiquated infrastructure.
> so you only get to just write a unit file and call it a day in the most trivial of cases.
What "start/stop verification"? Give examples, please. Systemd natively supports device dependencies, network status, other services, etc.
It's a very rare case when you _need_ shell in systemd.
> Now it can host telephony services, full-blown Docker orchestration systems, etc.
What features that systemd provides that aren't provided by openrc, runit, monit, openrc's init system, etc, etc, etc that are needed by software like Asterisk, Docker/runc, Kubernetes, and similar?
If what OpenWRT is running works fine to bring that up, then systemd doesn't have any relevant compelling features that aren't provided by another init system. Switching away from something just because it's "antiquated" is a great resume-building tactic, but it's a pretty poor strategy when your objective is to keep things that have been working working with a minimum of effort.
> What "start/stop verification"? Give examples, please.
One example (out of many) are pre-start, pre-stop, and pre-restart configuration file correctness verification so that a typo or thinko doesn't bring a service down.
A concrete example of this is Gentoo's running of 'named-checkconf' in BIND 9's service file [0]. Gentoo's BIND 9 systemd unit file [1] tries, but probably does not do the same thing... I don't know if 'ExecStartPre' runs before systemd brings down a service on a 'restart' action, but I bet you that it definitely does not run on service stop.
I just checked and Ubuntu 22 does NOT do this sort of checking for its bind9 package, which is pretty wild.
> It's a very rare case when you _need_ shell [or other such helpers] in systemd.
Then you're either running "seatbelts off" (maybe without even knowing that you are), or you rarely deal with anything nontrivial. This need comes up a LOT in my day-to-day.
[2] You might look at that file and be like "wow, TL;WR", but do try to notice how much of that file is dedicated to creating useful, human-readable status messages and error messages with good corrective instructions. If you care at all about your sysadmins, that complexity has to go somewhere, and that somewhere cannot be inside a systemd unit file... systemd just doesn't provide the features required to do that (and it would be kind of insane for the devs to even try).
> What features that systemd provides that aren't provided by openrc, runit, monit, openrc's init system, etc, etc, etc that are needed by software like Asterisk, Docker/runc, Kubernetes, and similar?
Dependencies, watchdogs, start only when the given network interfaces are available, declarative configuration so that can be partially customized, etc.
> If what OpenWRT is running works fine
Unless you try to update it. And end up with merge conflicts in the /etc directory. And then it stops booting, and you have to get in via the serial port.
No, OpenWRT is most definitely not fine. It's stuck in the past, and doesn't support automated rollback, configuration management, etc.
> A concrete example of this is Gentoo's running of 'named-checkconf' in BIND 9's service file [0]
Wow, what a... But named config has always been a disaster zone.
With systemd _none_ of that crap is needed. It can use its own namespacing and cgroup support to ensure that BIND9 can't read outside of its allowlisted tree.
If you want to run /usr/bin/named-checkconf, then it's just an ExecStartPre directive in the unit file. And unlike SysV that just fails to run and forces you to dig into the logs, systemd provides you a nice status saying that the pre-exec had failed.
> You might look at that file and be like "wow, TL;WR", but do try to notice how much of that file is dedicated to creating useful, human-readable status messages and error messages with good corrective instructions.
Yeah, and hanging indefinitely, forcing me to do a trip to the datacenter at night (true story): https://lwn.net/Articles/619565/
1) That's a list of systemd features. Some of which are nice to have, but none of which are needed for the software I mentioned.
2) On-upgrade merge conflicts for entirely-unmodified-from-their-stock-settings system configuration files are why I gave up on Ubuntu. Systemd doesn't solve anything here.
3) Systemd doesn't handle BIND configuration... or any non-systemd application configuration. And most nontrivial init systems (with systemd as one notable exception) have facilities for printing info, warn, and error messages in service startup files rather than demanding that you pick through the application logs to find out why startup failed.
Now it can host telephony services, full-blown Docker orchestration systems, etc. So you get all the pleasures of complex systems running on antiquated infrastructure.
> so you only get to just write a unit file and call it a day in the most trivial of cases.
What "start/stop verification"? Give examples, please. Systemd natively supports device dependencies, network status, other services, etc.
It's a very rare case when you _need_ shell in systemd.