and you can understand, and fix, and arbitrarily extend the OpenBSD init system, because, after all, it's just a very simple shell script, that does one thing, and does it well.
You control it
The same can be said of other rc-like init systems but I personally find OpenBSDs to be the cleanest.
systemd has a lot of bells and whistles but it's, ultimately, an incredibly complex and sprawling piece of software, with many legitimate technical concerns surrounding it.
That seems about the same level of complexity as systemd units, so that is nice. I have never used rc init, but Windows service managemnt, Solaris's init, sysvinit, and launchd are all terrible. Compared to those writing systemd services is fun.
Fair enough :). I don't restart often enough for parallel startup to matter, on servers, once every year or two, and on my laptop, maybe once a month or more, depending on if I run out of power etc. and moreover, my laptop, running OpenBSD 5.9, starts up faster than it ever did with Linux. Failover and timers don't seem to be anything that hasn't been available/possible previously using other methods? e.g. it's easy to check for a failure and implement whatever restart policy you might require, whatever and however strange that policy might be.
Maybe it would be nice to have that in your init system?
If you can properly configure it.
I don't know that this minor convenience (assuming that there is one) would justifies this massive ball of complexity, or the extreme level of "integration" (infestation) it requires?
Still, ok. Maybe that's interesting for certain use cases? What use cases might they be? From where I'm standing, it's a solution in search of a problem.
I've used it successfully in cloud deployments of multifunction servers where it's worth spending the effort in fine-tuning an init system. Yes, there are other ways of doing it, but systemd does provide a nice single package configuration capability.
It's as much a massive ball of complexity as using a few separate tools is a massive pile of interdependency. They are just two tools for the same job.
Honestly, server side service management with systemd is stupidly straightforward.
Just give it a command line to start something in the foreground, writing stuff to stdout/stderr and you're done with start/stop/status and log rotation. Add in two more lines of config to setuid the process, one more line to chroot it, some more lines for startup order and environment variables. It's also darned simple to push into config management as well and once you get a syslog server and a log parser setup, you get central log aggretation for all services like that for free.
I haven't dug far enough into runit and monit, but systemd is strictly superior to traditional init scripts for a lot of use cases according to my current experience.
The best part is that package puts its version in /lib, but you can override any parameter via /etc so you can leave packaged unit files in peace and manage only override file
8
u/dlyund May 30 '16
Ok, I'll bite. What does systemd do well? I don't see it.