10 ms·

I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. I love bash, I love nitpicking about how to use bash along with the other bash

I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. I love bash, I love nitpicking about how to use bash along with the other bash nazis in #bash@freenode. But I would never put myself through sysvinit again. I thoroughly enjoy using distros like CentOS 7, Fedora 23, RHEL7. They're a joy to manage and work with, in part thanks to Systemd. I never want to debug, troubleshoot, or even look at another sysvinit-script again. :)

lottin 11y ago
I've been using Linux for the last 15 years and I don't remember ever having to fiddle with any init scripts.
- chris_wot 11y ago
  I used to. It wasn't fun, but it wasn't terrible either. And I probably overused rc.local...
- guitarbill 11y ago
  Until you install something like Gerrit, or GoCD, which have absolutely appalling init scripts. And then you find out that e.g. Gerrit sets some ulimits in the init script. Yuck!
CaptSpify 11y ago
If all systemd did was sysvinit-script replacement, I'd be 100% behind it. I agree with you, sysvinit-scripts are terrible. It's all the other stuff, and the lack of modularity, that makes me dislike it.
- themartorana 11y ago
  Agreed. And upstart didn't suck for that.
hiddennetwork 11y ago
BSD handles all of this better than Linux. Text file. Easy. Linux has grown far too "complex". I like how OpenBSD adds modern touches yet keeps the OS free from binary blobs. systemd addresses some issues, but at the cost of complexity. I dislike binary blobs in my systems, hence, my servers run OpenBSD.
- chris_wot 11y ago
  What binary blobs are you referring to? Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities, the only other thing that is binary that I'm aware of is the binary log file, which can be reconfigured to revert to text if you so desire.
  - hiddennetwork 11y ago
    Aside from the binary logs, which are really not a great idea, systemd adds orders of magnitude more complexity to a system that really didn't need it. The init system could have been addressed without something like systemd. I'm old enough to remember and use Unix. Like a lot of IT guys my age, we all tend to think that adding complexity is wrong. This notion of one ring to rule them all mentality is really starting to take effect in IT. Unix-like operating systems are supposed to be non-complex. My example above, of OpenBSD, is true. Maintaining OpenBSD systems is trivial compared to similar Linux systems, and I maintain both. Sadly, I admin a series of CentOS PBX servers that are an absolute pain. A friend runs his on FreeBSD and has less than half the pain points I do. And we're running the same PBX software. I believe in lowest common denominator everytime. Binary anything is bad when alternatives exist. Linux has given itself over to binary blobs in the name of being more attractive to corporate users. Device drivers under Linux are now almost all binary blobs. You will not see this in OpenBSD, for example. The BSD folk reverse engineer the drivers and write their own free drivers -- and they are usually far and away better afterwards. Take the wireless chipset drivers for Ralink. The BSD guys took a 30,000 line driver and rewrote the entire thing in less than 1/3 of the code. That's just the whole attitude between Linux and BSD. Linux is a series of cobbled-together hacks on top of an ever-growing, ever-complex kernel (that really needs legacy crap removed). BSD, on the other hand, is engineered as a single OS with a small collection of pruned base programs. Big difference. If you've ever used BSD, you will know the joy of /etc/rc.conf vs the nightmare of Linux config files that live in myriad locations depending on the distro.
Sanddancer 11y ago
I'd argue that one of the biggest things that made sysvinit so ugly was that distro maintainers didn't enforce any type of startup script hygiene. Take a look at BSD-style init scripts some time. They're beautiful in their simplicity and readability. They source a common set of functions, have well-defined variables to control execution, and end up with a length about that of systemd units, without sacrificing the power of shell scripting. Systemd threw the baby out with the bathwater, and just makes diagnosing boot problems all that more difficult when you have to start tracing through magic symlinks.
- alwaysdownvoted 11y ago
  You nailed it. I rarely make use of the BSD scripts provided but I like them as simple examples of how various services are intended to be run. I find there is a certain amount of uniformity and consistency and arguably coherence to the rc.d system.
- INTPenis 11y ago
  I actually came from FreeBSD to Debian 8 years ago and the funny thing is that I don't remember editing rc scripts anywhere near as often as I edited sysvinit scripts on Debian. But that could easily be explained by the average complexity of services increasing along with my career path into Linux and Devops. I don't remember any clear differences between sysvinit and rc, the scripting is still left up to the user which means code style can diverge from whatever the maintainers had in mind. Systemd, albeit a binary blob, at least eliminates that from the equation and breaks down services into a limited number of types that it handles equally every time. I actually liked upstart too. :) I might sound mad for saying that but as a user of Linux upstart gave me just what I wanted. Bottom line is that I think discussions about scripting style have no place in the context of service management. Services should be dealt with in a simple way like upstart or systemd. If you want to add more complexity you can write a start script for the service but that should not be the norm.
  - woodman 11y ago
    > scripting is still left up to This is commonly provided by the port maintainer - I haven't conducted a survey but I'm pretty confident that service scripts in FreeBSD ports rarely make it into rc.d without a deliberate freebsdization.
pdkl95 11y ago
> sysvinit-script OpenRC fixes a lot of that, without adding the giant pile of dependencies that systemd imposes. As someone who is already comfortable with bash, OpenRC scripts should be easy. > I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. There are more options than sticking with Debian's ancient scripts. The larger problem is that init is only a tiny part of systemd. Systemd's mandatory link-time dependencies and tightly-coupled (monolithic) features are trying to be an entire wrapper around important parts of the kernel. Even if you like the init features of systemd, you should be looking at all the changes; do you really want to depend on all of systemd's features in the future? Do you enjoy depending on a moving target that changes at the whim of the systemd cabal and their reputation for WONTFIXing anything that they don't understand or haven't considered as a use case?
- chris_wot 11y ago
  "Systemd's mandatory link-time dependencies and tightly-coupled (monolithic) features are trying to be an entire wrapper around important parts of the kernel." What parts of the kernel are you referring to? Genuinely interested...
- vidarh 11y ago
  > The larger problem is that init is only a tiny part of systemd. That's because you can't reasonably fix the many problems with sysvinit (or OpenRC) without also providing a proper process manager, and dependency system that does far more than just trigger scripts in the right order. The biggest problem with init is that it's just init. > Do you enjoy depending on a moving target that changes at the whim of the systemd cabal and their reputation for WONTFIXing anything that they don't understand or haven't considered as a use case? I don't enjoy that, but the alternative of relying on sysvinit or OpenRC is so many times worse. Give me a better alternative, and I'll throw Systemd out of the window immediately. But to be better it will need to at a minimum: - Be able to sanely handle service restarts, including configurable behaviour on failure. - Be able to ensure service output is sanely logged. - Be able to reliably keep track of processes belonging to a service even if they double fork or the prent process dies. - Have a dependency system that allows starting and stopping services automatically depending on the status of other services, the availability of a directory or file. - Be able to schedule execution (like cron) but still subject them to the process management and dependency rules. .. to mention some.
bitwize 11y ago
Sysvinit scripts were shit. But as the AVGN might say, systemd took that shit sandwich and served it up with a side of buffalo vomit. It doesn't solve the "rat's nest of dependencies" problem, it makes it worse. Because now you have more moving parts which hard-depend on each other in various intricate ways and introduce unreliability into a formerly reliable startup process, combining the worst aspects of monolithic software with the worst aspects of modular software. Because development of components of systemd takes place in a bubble, there's not much room for feedback -- like is this a sane way to do system logging, network discovery, process group management, etc. That's easy to integrate with other pieces of software from the community? The systemd way to solve the integration issues is "pressure the major distros to adopt systemd. Then they'll HAVE to integrate with us!" It's possible to run sysvinit sanely, by having a few startup scripts that source in the appropriate boilerplate. Slackware's startup for instance has always been manageable.
kinkdr 11y ago
I am with you. I think it was long time for sysvinit scrips to die. But that doesn't mean that it should be replaced by systemd. Systemd, like a lot of things coming out of redhat these days (firewalld), feels like bloatware to me. Systemd, Firewalld, D-Bus, etc.. have no place in a server IMHO.
bpchaps 11y ago
You must have a machine built for it, since I've had tons and tons of niggling little issues with systemd. Random, unnamed services sometimes fail to start or shutdown. One of systemd's big claim to awesomeness is that the start scripts run simultaneously, yet that's all thrown out the window when "Attempting to start, attempt 55 1m30s remaining" bullshit happens constantly and randomly, without enough information to debug properly. The troubleshooting is ridiculous, too, because of the ridiculousness that comes with journald. Why does it feel the need to make me run an awfully formatted, and potentially complex set of parameters to print that? Especially considering that 9/10 times, the error message from journald is vague, ungreppable without -A or -B, and is often significantly shorter than the "use journald to print the error" output. So frustrating. I don't know how people deal with it. That said, I'm not a fan of sysvinit, either, but I don't have to deal with as much smoke and mirror behavior with it.
- chris_wot 11y ago
  Try installing syslogd then in journald.conf you just change storage to 1 and ForwardToSyslog to 1. That should hopefully get your old text based logs back.
  - bpchaps 11y ago
    Thanks for the advice, I'll definitely do that. There's a certain point where I threw my arms in the air and learned to accept it, and I hit it. :)
    - chris_wot 11y ago
      Yeah, binary logs are a bit insane.
itomato 11y ago
Lean unit syntax is not the defining feature of "System 500".

lottin 11y ago

I've been using Linux for the last 15 years and I don't remember ever having to fiddle with any init scripts.

chris_wot 11y ago
I used to. It wasn't fun, but it wasn't terrible either. And I probably overused rc.local...
guitarbill 11y ago
Until you install something like Gerrit, or GoCD, which have absolutely appalling init scripts. And then you find out that e.g. Gerrit sets some ulimits in the init script. Yuck!

CaptSpify 11y ago

If all systemd did was sysvinit-script replacement, I'd be 100% behind it. I agree with you, sysvinit-scripts are terrible. It's all the other stuff, and the lack of modularity, that makes me dislike it.

themartorana 11y ago
Agreed. And upstart didn't suck for that.

hiddennetwork 11y ago

BSD handles all of this better than Linux. Text file. Easy. Linux has grown far too "complex". I like how OpenBSD adds modern touches yet keeps the OS free from binary blobs. systemd addresses some issues, but at the cost of complexity. I dislike binary blobs in my systems, hence, my servers run OpenBSD.

chris_wot 11y ago
What binary blobs are you referring to? Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities, the only other thing that is binary that I'm aware of is the binary log file, which can be reconfigured to revert to text if you so desire.
- hiddennetwork 11y ago
  Aside from the binary logs, which are really not a great idea, systemd adds orders of magnitude more complexity to a system that really didn't need it. The init system could have been addressed without something like systemd. I'm old enough to remember and use Unix. Like a lot of IT guys my age, we all tend to think that adding complexity is wrong. This notion of one ring to rule them all mentality is really starting to take effect in IT. Unix-like operating systems are supposed to be non-complex. My example above, of OpenBSD, is true. Maintaining OpenBSD systems is trivial compared to similar Linux systems, and I maintain both. Sadly, I admin a series of CentOS PBX servers that are an absolute pain. A friend runs his on FreeBSD and has less than half the pain points I do. And we're running the same PBX software. I believe in lowest common denominator everytime. Binary anything is bad when alternatives exist. Linux has given itself over to binary blobs in the name of being more attractive to corporate users. Device drivers under Linux are now almost all binary blobs. You will not see this in OpenBSD, for example. The BSD folk reverse engineer the drivers and write their own free drivers -- and they are usually far and away better afterwards. Take the wireless chipset drivers for Ralink. The BSD guys took a 30,000 line driver and rewrote the entire thing in less than 1/3 of the code. That's just the whole attitude between Linux and BSD. Linux is a series of cobbled-together hacks on top of an ever-growing, ever-complex kernel (that really needs legacy crap removed). BSD, on the other hand, is engineered as a single OS with a small collection of pruned base programs. Big difference. If you've ever used BSD, you will know the joy of /etc/rc.conf vs the nightmare of Linux config files that live in myriad locations depending on the distro.

Sanddancer 11y ago

I'd argue that one of the biggest things that made sysvinit so ugly was that distro maintainers didn't enforce any type of startup script hygiene. Take a look at BSD-style init scripts some time. They're beautiful in their simplicity and readability. They source a common set of functions, have well-defined variables to control execution, and end up with a length about that of systemd units, without sacrificing the power of shell scripting. Systemd threw the baby out with the bathwater, and just makes diagnosing boot problems all that more difficult when you have to start tracing through magic symlinks.

alwaysdownvoted 11y ago
You nailed it. I rarely make use of the BSD scripts provided but I like them as simple examples of how various services are intended to be run. I find there is a certain amount of uniformity and consistency and arguably coherence to the rc.d system.
INTPenis 11y ago
I actually came from FreeBSD to Debian 8 years ago and the funny thing is that I don't remember editing rc scripts anywhere near as often as I edited sysvinit scripts on Debian. But that could easily be explained by the average complexity of services increasing along with my career path into Linux and Devops. I don't remember any clear differences between sysvinit and rc, the scripting is still left up to the user which means code style can diverge from whatever the maintainers had in mind. Systemd, albeit a binary blob, at least eliminates that from the equation and breaks down services into a limited number of types that it handles equally every time. I actually liked upstart too. :) I might sound mad for saying that but as a user of Linux upstart gave me just what I wanted. Bottom line is that I think discussions about scripting style have no place in the context of service management. Services should be dealt with in a simple way like upstart or systemd. If you want to add more complexity you can write a start script for the service but that should not be the norm.
- woodman 11y ago
  > scripting is still left up to This is commonly provided by the port maintainer - I haven't conducted a survey but I'm pretty confident that service scripts in FreeBSD ports rarely make it into rc.d without a deliberate freebsdization.

pdkl95 11y ago

> sysvinit-script OpenRC fixes a lot of that, without adding the giant pile of dependencies that systemd imposes. As someone who is already comfortable with bash, OpenRC scripts should be easy. > I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. There are more options than sticking with Debian's ancient scripts. The larger problem is that init is only a tiny part of systemd. Systemd's mandatory link-time dependencies and tightly-coupled (monolithic) features are trying to be an entire wrapper around important parts of the kernel. Even if you like the init features of systemd, you should be looking at all the changes; do you really want to depend on all of systemd's features in the future? Do you enjoy depending on a moving target that changes at the whim of the systemd cabal and their reputation for WONTFIXing anything that they don't understand or haven't considered as a use case?

chris_wot 11y ago
"Systemd's mandatory link-time dependencies and tightly-coupled (monolithic) features are trying to be an entire wrapper around important parts of the kernel." What parts of the kernel are you referring to? Genuinely interested...
vidarh 11y ago
> The larger problem is that init is only a tiny part of systemd. That's because you can't reasonably fix the many problems with sysvinit (or OpenRC) without also providing a proper process manager, and dependency system that does far more than just trigger scripts in the right order. The biggest problem with init is that it's just init. > Do you enjoy depending on a moving target that changes at the whim of the systemd cabal and their reputation for WONTFIXing anything that they don't understand or haven't considered as a use case? I don't enjoy that, but the alternative of relying on sysvinit or OpenRC is so many times worse. Give me a better alternative, and I'll throw Systemd out of the window immediately. But to be better it will need to at a minimum: - Be able to sanely handle service restarts, including configurable behaviour on failure. - Be able to ensure service output is sanely logged. - Be able to reliably keep track of processes belonging to a service even if they double fork or the prent process dies. - Have a dependency system that allows starting and stopping services automatically depending on the status of other services, the availability of a directory or file. - Be able to schedule execution (like cron) but still subject them to the process management and dependency rules. .. to mention some.

bitwize 11y ago

Sysvinit scripts were shit. But as the AVGN might say, systemd took that shit sandwich and served it up with a side of buffalo vomit. It doesn't solve the "rat's nest of dependencies" problem, it makes it worse. Because now you have more moving parts which hard-depend on each other in various intricate ways and introduce unreliability into a formerly reliable startup process, combining the worst aspects of monolithic software with the worst aspects of modular software. Because development of components of systemd takes place in a bubble, there's not much room for feedback -- like is this a sane way to do system logging, network discovery, process group management, etc. That's easy to integrate with other pieces of software from the community? The systemd way to solve the integration issues is "pressure the major distros to adopt systemd. Then they'll HAVE to integrate with us!" It's possible to run sysvinit sanely, by having a few startup scripts that source in the appropriate boilerplate. Slackware's startup for instance has always been manageable.

kinkdr 11y ago

I am with you. I think it was long time for sysvinit scrips to die. But that doesn't mean that it should be replaced by systemd. Systemd, like a lot of things coming out of redhat these days (firewalld), feels like bloatware to me. Systemd, Firewalld, D-Bus, etc.. have no place in a server IMHO.

bpchaps 11y ago

You must have a machine built for it, since I've had tons and tons of niggling little issues with systemd. Random, unnamed services sometimes fail to start or shutdown. One of systemd's big claim to awesomeness is that the start scripts run simultaneously, yet that's all thrown out the window when "Attempting to start, attempt 55 1m30s remaining" bullshit happens constantly and randomly, without enough information to debug properly. The troubleshooting is ridiculous, too, because of the ridiculousness that comes with journald. Why does it feel the need to make me run an awfully formatted, and potentially complex set of parameters to print that? Especially considering that 9/10 times, the error message from journald is vague, ungreppable without -A or -B, and is often significantly shorter than the "use journald to print the error" output. So frustrating. I don't know how people deal with it. That said, I'm not a fan of sysvinit, either, but I don't have to deal with as much smoke and mirror behavior with it.

chris_wot 11y ago
Try installing syslogd then in journald.conf you just change storage to 1 and ForwardToSyslog to 1. That should hopefully get your old text based logs back.
- bpchaps 11y ago
  Thanks for the advice, I'll definitely do that. There's a certain point where I threw my arms in the air and learned to accept it, and I hit it. :)
  - chris_wot 11y ago
    Yeah, binary logs are a bit insane.

itomato 11y ago

Lean unit syntax is not the defining feature of "System 500".