6 ms·

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

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.

chousuke 11y ago
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.
- VLM 11y ago
  The key is the expense vs reward ratio. 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.
  - EmanueleAina 11y ago
    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. (Not to mention how subtly tricky programming in shell is even when you're doing trivial things, see http://www.dwheeler.com/essays/filenames-in-shell.html http://www.dwheeler.com/essays/filenames-in-shell.html )
    - JdeBP 11y ago
      knowing the systemd unit options is not a reusable skill That is, to an extent, not true. There is at least one system that can import systemd unit files, subject to some fairly obvious limits on Linux idiosyncrasies. http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/worked-example.html http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
- digi_owl 11y ago
  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.
pppp 11y ago
I wouldn't say the init scripts on OpenBSD are complex: # cat smtpd #!/bin/sh # # $OpenBSD: smtpd,v 1.4 2012/10/26 06:51:59 ajacoutot Exp $ daemon="/usr/sbin/smtpd" . /etc/rc.d/rc.subr pexp="smtpd: \[priv\]" rc_reload=NO rc_cmd $1
- EmanueleAina 11y ago
  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.
  - falcolas 11y ago
    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.
    - rjcz 11y ago
      > 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. Ouch... Shell (or Bourne Shell to be exact), not bash. Bash is a type of Shell and it's not* even available (thank goodness) on either of the BSDs in their base system (only as a port and/or package). On OpenBSD, the actual command line interpreter is actually Korn, not the Bourne, Shell.
    - EmanueleAina 11y ago
      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.
EmanueleAina 11y ago
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. I don't see why you should feel homeless.

chousuke 11y ago

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.

VLM 11y ago
The key is the expense vs reward ratio. 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.
- EmanueleAina 11y ago
  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. (Not to mention how subtly tricky programming in shell is even when you're doing trivial things, see http://www.dwheeler.com/essays/filenames-in-shell.html http://www.dwheeler.com/essays/filenames-in-shell.html )
  - JdeBP 11y ago
    knowing the systemd unit options is not a reusable skill That is, to an extent, not true. There is at least one system that can import systemd unit files, subject to some fairly obvious limits on Linux idiosyncrasies. http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/worked-example.html http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
digi_owl 11y ago
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.

pppp 11y ago

I wouldn't say the init scripts on OpenBSD are complex: # cat smtpd #!/bin/sh # # $OpenBSD: smtpd,v 1.4 2012/10/26 06:51:59 ajacoutot Exp $ daemon="/usr/sbin/smtpd" . /etc/rc.d/rc.subr pexp="smtpd: \[priv\]" rc_reload=NO rc_cmd $1

EmanueleAina 11y ago
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.
- falcolas 11y ago
  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.
  - rjcz 11y ago
    > 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. Ouch... Shell (or Bourne Shell to be exact), not bash. Bash is a type of Shell and it's not* even available (thank goodness) on either of the BSDs in their base system (only as a port and/or package). On OpenBSD, the actual command line interpreter is actually Korn, not the Bourne, Shell.
  - EmanueleAina 11y ago
    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.

EmanueleAina 11y ago

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. I don't see why you should feel homeless.