It got the job done by making the 99% majority of use cases more difficult in order to make the 1% minority simpler. This is a design pattern I think is being repeated in systemd.
I kinda had the opposite impression. I first encountered systemd when I started messing around with arch for a couple little vps projects. At the time I was doing sysadmin that involved both Ubuntu and CentOS, and I definitely found day-to-day tasks easier with systemd (better built in monitoring, consistent syntax, etc). For simple cases, writing a unit file sucks a lot less than writing an initscript. The warts in systemd only started to irritate me when I was first setting up my personal machines (one laptop, one tower) to run arch [1]. Even then, the bloat in the design irked me more than actually using it. So, I'm in favor of systemd, but not thrilled (dbus everywhere is annoying).
Then again, I don't maintain any packages with strange and/or complex daemons. If anybody's had a really hard time getting their stuff to work with systemd, I'd be interested to hear stories.
1: Not completely true. I want my damn log files back.
This is why I suspect that most of the divisions in the sysadmin community regarding systemd are generational. For people (like me!) who have been writing init scripts forever and can do it in their sleep, they'd prefer the flexibility and familiarity of init scripts to a new system that at first glance appears more limited.
For people who are less experien^H^H^H^H^H^H^H^Hcrusty :-), init scripts look like a horrifying way to manage a startup process, and just about anything -- including Yet Another Config File Format -- looks preferable.
I think this is also why so little progress is being made on resolving conflicts over systemd. There really isn't a whole lot of room for compromise; one group simply wants things to stay more or less the same (or evolve incrementally), the other group simply wants to throw it all out and start over.
I bet there would've been a lot less argument and vitriol about systemd if Debian hadn't made the decision to default to it, basically leaving all the crusty sysadmins homeless. Once Debian switched, there was a near guarantee that all of Linux was going to move to systemd. That suits one group just fine, another one not so much.
On the plus side, the BSDs should be seeing a really nice upswell of installations over the next couple of years, which is great, because they've been quietly building some pretty great operating systems that deserve more love.
It's perfectly possible to run scripts with systemd unit files, so there's no real "flexibility" lost anywhere. The primary improvement is that systemd handles by default most of what used to be boiler-plate in every script, on top of calculating dependencies automatically. Then you get integrated process supervisor capabilities so that the init system actually knows whether services are running or not.
Speed was certainly a major motivator as well, considering the increasing popularity of containers and on-demand virtual machines.
To me it seems that "gradual evolution" was exactly what they did, and it wasn't really going anywhere. Lennart came up with systemd and convinced enough people that it's worth the pain of migration to get a clean start.
I don't know how to write sysvinit scripts any more than I know how to write fizzbuzz. What I do know is how to program and specifically how to write and maintain and debug shell scripts. I NEED that for other automation purposes and cannot get rid of that mandatory requirement so it used to dovetail quite well with init scripts. There are corner cases and security issues and tradition, which means copying a known good init script and editing nothing but the executable names is a great start, but its not really a serious problem. I don't care if its verbose, as long as its simple and understandable and most importantly, predictable.
Now instead of applying a language and tradition I know to a simple task like init, I get to learn a whole new ecosystem and technology to do about the same thing I always did except vastly more complicated, and I can't even shed the old knowledge because its needed elsewhere. That makes overall systems harder to use, slower, buggier, and less reliable. And thats defined as "progress" because its new so it must be better.
Honestly, I don't think that argument holds much water.
Init systems are not "just shell". If you go and try to write a sysv init script with only shell skills, chances are your init script will be broken in some obscure way. Perhaps because you didn't specify LSB headers correctly, or your PID file handling is subtly broken, or you're missing a check somewhere and the script is racey. I can't really say how much reading it would take to catch all the corner cases with sysv init scripts, but for simple cases, you will be able to write a correct unit file after about 15 minutes of reading the manuals.
Knowing shell helps, but you'll still need the tool-specific knowledge.
I don't think it's really fair to compare writing unit files to being able to program in shell.
True, knowing the systemd unit options is not a reusable skill, but it's not a huge effort either: the syntax is trivial (INI-inspired, the same as .desktop files) and the options themselves are rather well documented.
And for sure, these options are immensely more reusable when writing a new unit file than mixing and matching shell snippets taken from different init script using different styles and conventions.
It was around before the Debian Technical Committee made its decision. It wasn't one of the options to choose from, but it was an existence proof, for those making the decisions, that systemd unit files will not lock them in and that there's a route for Debian packages that have systemd units on Debian kFreeBSD and Debian Hurd.
Too bad it is not the unit files one should worry about, but the continued scope creep of the systemd project.
by the time one want to move from systemd to nosh, or anything more limited in scope, one may have face the rebuilding of Linux user space from the ground up.
It's not the unit files as a potential lock-in that one need worry about now, because of the nosh project. But it most definitely was one thing that people thought about then.
Possible sure, but it the systemd compatiblity with sysv scripts are listed as 99%. Meaning that complex scripts are liable to break, and it is exactly those that you want the compatibility for.
Indeed. But at that point you have a DSL which is no longer obvious when one only knows about shell scripting (eg. I have no idea what `pexp="smtpd: \[priv\]"` does), so using a completely declarative language with a trivial syntax doesn't seem a huge issue either.
One may think about systemd's unit files as a set of shell variables that gets sourced by the real script.
That's not a DSL, that's a shell script. As for what `pexp="..."` does - it's just setting the pexp variable. If you'd like to know what that does, you can just look up the bash source of `/etc/rc.d/rc.subr`, another bash script.
No DSL knowledge required, at all. Just shell knowledge, and the willingness to look at sourced shell scripts.
I mean, I know that it sets a variable, I can't even guess what are the effect of setting that variable.
And "look at the source" is a sad answer, no matter if the source is a shell script or C program.
The point is that with your example you need domain knowledge, knowing bash is not enough: what does the pexp assignment do, what rc_reload=NO means, should flags be specified in the daemon variable or that's meant to only contain the binary, does that path be full or it takes in consideration a standard PATH?
And now you got two things to know: the bash (or even strictly posix sh) language (which, admittedly, isn't the best one in the world) and the domain specific functions/variables.
This isn't much different than with systemd: the language is much more simple and far less surprising being INI-like (the same as .desktop files), and it's basically just setting a list of rather well documented variables.
pexp
A regular expression to be passed to pgrep(1) in order to find the desired process or to be passed to pkill(1) to stop it. By default this variable contains the daemon and daemon_flags variables. To override the default value, an rc.d script has to redefine this variable after sourcing rc.subr.
Thanks, that wasn't the point. What I was trying to say is that if you use those helpers you're looking up stuff in a man page anyway, so knowing shell scripting isn't enough any longer.
My personal opinion is that having a simple, INI-derived language is better than keeping the weirdness of the shell language just to assign a couple of variables (and you can still launch shell scripts from units anyway).
That you can import shell scripts into shell scripts is one of those things that catch many off guard when first encountered. But when grok-ed, really demonstrate how far shell script can go.
Yep, my point is that knowing shell scripting alone is no longer enough and it's not different than running `man systemd.service`, only that you're keeping the weirdness of the shell language just to set a couple of variables.
Except that rc.subr is shell scripting alone. It's literally a shell script that gets sourced into another shell script (in this case, your initscript), which is - again - ordinary shell behavior. Yeah, you have to learn a couple of shell functions and variables, but that's not really that big of a deal for someone with even cursory knowledge of shell scripting.
The bigger point, though, is that if your only goal is to have terse daemon configuration with a minimum of boilerplate, you can already do this with shell scripts. Even if you decide that shell scripts are the spawn of the devil and ought to be burned on the stake (which, honestly, isn't all that unreasonable of a decision), it's quite possible to implement the same functionality using Ruby or Python or Perl or C or Go or Rust or Erlang or Lisp or PHP or COBOL or MIPS assembly or whatever-the-hell-else you feel like writing init "scripts" in (with some exceptions; FreeBSD and NetBSD, for example, apparently launch initscripts with 'sh' instead of following the OpenBSD and GNU/Linux approach of calling initscripts as executables).
The biggest point, though, is that because of this, if your only goal is to have terse daemon configuration with a minimum of boilerplate, you can have that without having to learn at minimum two languages (one to write your initscripts and one to do all the rest of your day-to-day administration tasks). You just learn shell and you're done. With systemd, you still have to learn shell scripting for even systemd-related tasks (let alone non-systemd-related tasks) plus a new DSL that looks like INI but isn't quite INI. I guess that's tolerable coming from, say, the Windows world (where you're learning DOS batch language and PowerShell and VBScript and INI and Lord-knows-what-else), but that's double what a seasoned Unix admin requires in a non-systemd environment, which is pretty significant.
Again, "read the source" is a sad answer. I can read systemd C sources too, but given that it comes with proper documentation there should be no need to do it.
My point is that either one has to get some domain-specific knowledge or they have to reverse engineer some code. Given that I believe that the second one is a bad choice (people will rely on the implementation rather than on the intended interface) if you have to get some domain-specific knowledge it does not matter if you're using posix sh syntax or a INI-style one.
> your only goal is to have terse daemon configuration with a minimum of boilerplate, you can already do this with shell scripts
Literally nobody ever claimed that systemd "only goal" is to have terse daemon configuration. It was one of the many goals. Sure, it could have been done with posix sh syntax, nobody disputes that, but since backward compatibility was being dealt in other ways (using LSB header), switching to a INI-style format seems a good choice if one wants to enforce a declarative-only style.
And if someone claims that init script are needlessy complex and redundant it is because that's the situation of most distributions before the switch to systemd. Switching to OpenRC would probably have fixed that aspect, but systemd solves many more problems that distributors faced and OpenRC did not address, faring more positively in a costs/benefits analysis.
> Again, "read the source" is a sad answer. I can read systemd C sources too, but given that it comes with proper documentation there should be no need to do it.
rc.subr also comes with proper documentation, in the form of the rc.subr manpage, which comprehensively documents its behavior.
Barring that, you're delusional if you think that C is anywhere near as readable as shell in this sort of context.
> My point is that either one has to get some domain-specific knowledge
Arguably less of it in the case of rc.subr, since said knowledge is already part of basic shell scripting knowledge.
> Literally nobody ever claimed that systemd "only goal" is to have terse daemon configuration.
Nor did I. That doesn't change the fact that "OMG initscripts are so verbose with so much boilerplate; my unit files are so much better" is a commonly-cited reason for people to prefer systemd over other init systems, never mind that said reasoning is plainly false.
> the fact that "OMG initscripts are so verbose with so much boilerplate; my unit files are so much better" is a commonly-cited reason for people to prefer systemd over other init systems, never mind that said reasoning is plainly false
Indeed, I agree with that. The only advantage is that the restricted syntax of unit files is more suitable for error checking rather than having the shell complain more or less randomly, but compactness is not an intrinsic advantage of it.
That said, not every distribution standardized on such kind of helpers (ie. Debian), so in those cases compactness was one of the benefits of switching to systemd (not exclusive to it).
You can still use plain shell-based LSB-compliant init scripts just fine, which is what Debian is still doing as they didn't want to have flag days like all the other distributions who switched.
The nice thing about initscripts, though, is that you can get the best of both worlds by sourcing in common functions, as is the default and recommended practice on OpenBSD. For example, here's the initscript for dovecot on my (OpenBSD-running) mail server (with some comments and newlines omitted for brevity):
Pretty straightforward: you set $daemon to the path of your daemon's executable (in this case, dovecot), source in rc.subr, and call rc.subr's rc_cmd command with $1 (which represents a command, like 'start', 'stop', 'restart', etc.).
rc.subr, meanwhile, holds all the complexity one will ever likely need in an initscript, in the form of various shell functions encapsulating things like starting, stopping, etc. And if that's not enough for whatever reason, it's easy to add more functionality either to the individual initscript or to rc.subr, since it's shell scripts all the way down. In my experience, reasoning about this sucks a lot less than writing a systemd unit file, let alone an initscript on a system without such niceties.
Slackware's a bit of a peculiar case. It does indeed use /etc/rc.d in a somewhat-BSD-style manner, but there are two key differences:
* Slackware doesn't use a BSD-style /etc/rc.conf. Instead, daemons are enabled/disabled by setting the executable flag on each initscript. While this loses some of the features of /etc/rc.conf, I personally like this method better.
* Slackware doesn't include an equivalent to /etc/rc.d/rc.subr, which means there's a lot of boilerplate in its initscripts.
But yes, systemd's primary objections to shell-based init systems in general seem to stem from a limited scope.
I kinda had the opposite impression. I first encountered systemd when I started messing around with arch for a couple little vps projects. At the time I was doing sysadmin that involved both Ubuntu and CentOS, and I definitely found day-to-day tasks easier with systemd (better built in monitoring, consistent syntax, etc). For simple cases, writing a unit file sucks a lot less than writing an initscript. The warts in systemd only started to irritate me when I was first setting up my personal machines (one laptop, one tower) to run arch [1]. Even then, the bloat in the design irked me more than actually using it. So, I'm in favor of systemd, but not thrilled (dbus everywhere is annoying).
Then again, I don't maintain any packages with strange and/or complex daemons. If anybody's had a really hard time getting their stuff to work with systemd, I'd be interested to hear stories.
1: Not completely true. I want my damn log files back.