Slashdot Mirror
Which Style Init Scripts Do You Prefer?
An anonymous reader asks: "I started using Linux years ago, with a Red Hat distribution. When Red Hat's custom configurations started getting in my way, I jumped ship to Slackware. I have never looked back except that I cannot stand the BSD style init scripts. I like having a full compliment of run-levels and control on the fly over which scripts will be running, and which ones will not. That is hard to achieve, when you put multiple configurations in the same file. I also liked having the scripts around to start, stop, and restart services. While I was rewriting my own startup scripts [based on Debian's scripts], I discovered that there is a third style, based on dependencies. AFAIK this is the style adopted by Gentoo. I don't want to start a distro war; but, I am curious about what kind of init scripts Slashdot readers prefer, and what they think are the benefits of each."
You might want to take a gander at FreeBSD 5's RCng (also available in NetBSD, and possibly OpenBSD).
/etc/rc.d. Want to restart your sshd? /etc/rc.d/sshd restart. Very similar to init.d.
It combines, in my opinion, the best of both worlds:
1. Full control over each service through scripts in
2. Dependency-graphs determine service start order. Each file contains a special header declaring its dependencies and what it provides; the system analyzes these on boot, or when you request that a specific service be started, and handles the dependencies for you.
Mmm, tasty.
(And yes, this is quite similar to Gentoo's system, except that Gentoo translates the scripts into actual runlevels behind the scenes, whereas the BSDs do not. That, and this doesn't use python.)
Mac OS X does what I have long wanted to see in a UNIX system, parallell/dependent startup. For instance, "vtun" depends on "tunnel.kext" and "networking", but both "tunnel.kext" and "networking" can be started simultaneously. Also, the "StartupParameters.plist" meta-information file has some parameters related to order preference ("early", "late", and so on).
An article describing a similar concept for Linux can be seen at IBM DeveloperWorks.
Sounds like that may be what Gentoo does?
Init scripts concern my very little because I almost never reboot. For the record, I use Gentoo and they seem to work fine, but my Gentoo box is nearing a month of uptime. I only rebooted it because I recompiled the kernel. Maybe I should reboot now just to watch the init scripts for fun...
You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!
As other(s) have noted, this article is flamebait. My personal preference is BSD style. Beyond that, the only serious problem I've encountered with the SysV style is what happens if the "stop" case in a given script is flawed -- if it fails to exit, as in the case of trying to stop a program that is wedged due to failed hardware (i.e.: why you're trying to shutdown in the first place), the shutdown will hang at that point and you will be forced to reboot via the reset or power switches. This can result in serious data loss and is a failure in the SysV init design. This issue may have been addressed by now. Ideally, init should timeout if a given script takes "too long" and move on to the next one. Of course, this brings up the question of how long is too long and where you would set this, etc. Anyway, you asked.
and here's a good overview of it with more technical links. it is my favorite setup by far, and i'm very glad to see fbsd5 and gentoo adopting its style.
IIRC, sysV has all these /etc/rc.?/ directories (corresponding to run levels) with a whole lot of S??foo and K??bar symlinks going back to /etc/rc.d/foo and /etc/rc.d/bar. I remember thinking, hey that's kind of a neat way to do things. That was when I was learning UNIX (Digital/Compaq Tru*64).
/etc/rc.d didn't exist. Neither did the /etc/rc.?/ directories. I was befudled. Then I figured out everything was in /etc/init.d. The concept of run-levels (I can tell why they are usefull; if you don't know, you've never done any real server work) was reduced to "boot" and "default". Everything that was needed for the essential running of the system was put into the "boot" runlevel. Everything else was in the "default" runlevel. Then, I started looking at the scripts in /etc/init.d. They aren't the regular #!/bin/sh scripts I expected. They were essentially "set some variables, define the functions start(), stop(), restart()." Among other things, they can define what they REQUIRE and PROVIDE and what they must start BEFORE and AFTER.
/etc/rc.3, but boot to runlevel 5, did you start foo? And if you have K00foo in /etc/rc.3 and go from runlevel 5 to runlevel 3, do you start or stop foo? I don't know.
When I picked up Linux (RedHat 6.0), I felt like I knew what I was looking at because it was similar. After that, I stalled with the RedHat upgrade cycle at 7.3 because it worked and worked well.
Finally I had to upgrade my workstattion because chasing RPM dependencies got to be too much fun. (Yes, I know about apt, but then you have to hope that apt has what you want; if not, then the chase is on.) That's when I went looking for a new distro. Gentoo actually turned out to be my choice because it had "this thing called portage" which seemed very similar this other thing one of my former co-workers had been raving about with some BSD (free, I think; never tried any flavor of BSD) call "ports". Anyway, Gentoo sounded interesting and I gave it a try. After getting it installed and booted and configured, I started to try to figure out how it worked.
First major difference was startup scripts.
Now from this thread, I think this is very BSD-like. I know it isn't the sysV style I grew up with. I think it's better because it is too easy to not add a link in a runlevel directory to start/stop a daemon when you need to. That is, if you put a S99foo in
Now as to the questions of why use runlevel: if you have a *Real* server (big cabinet-style as seen in machine rooms at universities), you will find yourself at times needing to be at single-user mode for doing hardware checks/system maintenance. Other times, you need to allow more than one person on the machine, but don't want to have full services up: multi-user mode; let multiple parties perform their maintenance steps in parellel, but don't open the system up to everyone. Then, you can bring the system up to a level that allows a small set of users to log in and test prior to bringing the system up to full-service level. Sure, you can manually stop/start daemons as you move from one level to the next, but wouldn't it be neat if all you had to do was tell the machine "bring up the net work services" and it "knew" what to start? Oh, that's what a runlevel is for!
ftp://atrey.karlin.mff.cuni.cz/pub/local/mj/linux/ sss-0.0.1.tar.gz
It's easily configurable, as everything is kept in a single, hierarchicaly structured config file.
It's very convenient to use, since you can bring up whole subtrees of services up and down with a single command.
And it's damn FAST, allowing to boot my system under three seconds from LILO to running WindowMaker desktop. It achieves that by reading just the single config time just one time and then piping all the commands that it needs to execute to bring the system up to a single bash instance.
I used it once, and I can't never go back and replace the init scripts on every distro I use with it.
How long do your init scripts take to boot?
True. And IIRC many of these are either new standard packages or were removed from rc.inet[12] starting with Slackware 9.0 (so the original question is somewhat moot). However, there are still some services still buried with rc.inet[12]. If you never change services except by rebooting or changing runlevel, it doesn't make much difference. But say you need to restart DHCP after a reconfig, for example. Here are one set of steps to do it:
Maybe there's a better approach to doing quick restarts than the way I have suggested above. But personally, I find it much easier to have a /etc/rc.d/rc.service restart command do it in one shot. BTW, I also like the Solaris approach of hard links from rc*.d to init.d. It means I can do all my runlevel changes with filesystem commands, and never need to edit a file (and possibly introduce a syntax error) once it's created. But that method just gives people fits, so I won't go into it.
The two ways that impress me the most are exact opposites: one is simple, and one is complicated.
/etc/rc.conf.
The first one I really like is OpenBSD. Their boot scripts are the most straightforward. It's all just a very simple shell script. I also like the idea of
However, customizing those scripts could be a pain.
The other example I really like has been well articulated by Richard Gooch, creator of Linux devfs (now labelled a failed experiment by kernel hackers). You can read about what Richard has to say here. This is the idea of boot scripts with dependencies. This idea still needs a little bit of work to be done well.
I've often thought about writing my own boot scripts... It would be very simple, but also have dependencies, and track PIDs of daemons being run. It wouldn't have any runlevels, or, if it did, they would be easily redefinable.