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?
Anyway on to the init. I do sorta like the init system except the use of the stop-start-daemon. Works fine if everything has well but is as a dumb piece of shit when it doesn't. Will happily insist that something is running when it isn't or that it isn't when it is. Have for some services now changed the scripts to stop using that crap anyway.
Have asked this on the gentoo forum but noone so far has given me a reason let alone a good reason why the stop-start-daemon is used at all. Especially for stuff like apache where the gentoo initscript has less options then apachectl has.
Anyway rebooting just to see the init scripts seems a bit, odd. Kinda like saying you like windows crashes because of the cool splash screen. Get a girl :)
But if you ever do an emerge -u portage and then etc-update make sure you know what you are doing. A lot of the updates you can simply do EXCEPT for the files wich you may have changed. Problem is you may have forgotten and then you could really break something. I had it happen once when I accidently overwrote the net configuration. No a smart move on a remote machine. Noticed it only after hosting provided added hardware and then rebooted it as a very secure server (no netaccess).
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
You will pry the Slackware init scripts from my cold dead hands!
/etc, because of RedHat's non-standard installation. Not to mention the mass of files in /etc and all over the hdd that I had NO ideea what their purpose was. At that point I realised that the advantage of rpms was far outweighed by the horrible system management in RedHat. Then I tried pretty much all distros out there, and I finally settled on Slackware for my workstation and laptop as well.
On a more serious note, I had always run Slackware on my gateways (about 6 years total), so I know the scripts pretty much inside and out. I have a lot of very specialised scripts that I wrote from scratch tailored specifically for my gateway and home network. But on my workstation I tried a variety of distribuitons, and for a very long time I ran RedHat (from rh4.2 to rh7.3.), mainly because I enjoyed constantly upgrading rpms and trying out new things.
I ran into the same problem you did around the time RedHad came out with rh8.0. I found it amost impossible to track every config file in
I happen to like the BSD style scripts. They make maintainance a breeze, and they almost never need to be changed. Even when I reinstall Slack (for whatever reason, last time it was a hdd starting to fail), I find that most scripts and config files can just be copied over to the new distro. I actually had a masquarading script that lasted me from kernel 2.0.20 untill 2.4.x was released.
So there you have it, I _love_ the Slack init scripts. I'm not sure there are much better ones out there in terms of simplicity and complete control. Sure, maybe RedHat's linuxconf (is that thing still around?) may make changing stuff and automation easier, but at a significant loss of control. And God forbit you fubar linuxconf's dependencies so you can't run it. Then you'll really appreciate Slackware.
You want ssh? /etc/rc.d/sshd start /etc/rc.d/rc.httpd start /etc/rc.d/rc.samba start
Apache?
Samba?
Same goes for nfsd, inetd, gpm, cups, bind, acpid, etc...
rc.6 for restart, rc.0 is statically linked to it to make sure they're always the same.
rc.S is called on runlevel 1 by default, as rc.M is called for 3.
On top of that, if you like your System 5 scripts, call rc.sysvinit.
Where exactly is the problem?
I don't think the lack of "/etc/init.d/daemon stop" is that big a disadvantage. "killall daemon" works just as well - in fact, that's all most stop scripts do. The only thing you lose is the pretty color graphics.
This is definitely prime material for a religious war, though, as neither approach offers any real benefit. You can easily make either approach do whatever you want. With SysV-style scripts, it's slightly easier to let packages say how they should be started; with BSD-style scripts, it's slightly easier to understand the "big picture."
The notion of a run-level is a flaw that is fatal, and will lock you in. However, the BSD's never did lock themselves into this notion, and in fact doesn't support init levels except for compatibility. NetBSD doesn't support init 6 for instance, but freebsd does. I think OpenBSD, and Slackware are the only distro's left that use the old BSD way, as NetBSD and FreeBSD now use rcNG (next generation) in their startup. The think is that system startup is linier in nature (aka in line, and in order). The sysV style startup is based on the shell's lexical ordering, which is nice, but is way too simple. You cannot have complex dependancies like scriptA depends on scriptFOO, and scriptFOO might depend on scriptB. Lexical ordering is easy, but too simple. For example the timed might depend on the network to be started before it can contact the stratum servers. So the new BSD startup scripts has a notion of ordering that isn't dependant on lexical alphabet soup. Your script PROVIDES a service, and might REQUIRE another service before it starts, and might need to run BEFORE another service. These keywords can be placed in commenst of yoru startup scripts to control the startup ordering of the services via the program called rcorder, which parses all the startup scripts, and then executes them in order. This the best way to startup because it doesn't depend on a flawed notion of run-levels which plauge the unix history. the only problem is that they do not provide a way to starup sevices in tandem, or to execute an forget orphan services which neither REQUIRE another service to startup, or need to be run before anything else. It would be possible to speed up startup execution if you could have job-control in the startup scripts. Luck for us the shell can do this, but nobody seems to use it. The problem with having complex dependancies is that you remove the simplicity of lexical orderign which seems so intuative. Now you have to edit the scripts to achive the ordering you want, which is cumbersom, and only for a few seconds increase in overall startup speed. And to think that all this is as simply as /sbin/init executing one user land process (a shell script). Certainly when you think of it this way it is simple, but nobody wants to write startup scripts, which is basicly redesigning the wheel.
It isn't a lie if you belive it.
The company I work for end up with a motley crew of turbolinux machines that had daemontools put on them, I did not like it, but some people swear by being able to do a svc -u /service/apache instead of a /etc/init.d/apache start, I guess it comes down to what you are comfortable with, but I've gotten used to /etc/rc.X/S* start|stop|restart from solaris, just pick one and stay with it.
09f911029d74e35bd84156c5635688c0
If you regularly have long uptimes you will fall into the trap of just doing things from the command line, but never 'saving' that anywhere. If you dont force yourself to use init scripts, then more often then never you will simply run an obscure - but very important command - and it wont be carried out on the next reboot. If you typed it in a week ago you might remember it, and remember the man page (and possibly even have it in your shells history file). If you typed it in 6mo ago you might have compleatly forgeten it. You might waste 5 minutes relearning it, but you might waste 5 hours too.
A varriation on "laziness is a virtue".
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.