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.)
The choice is "important" in terms of minimising workload / maximising efficiency - the different approaches allow you to do different things more or less easily.
This discussion is not particularly important, the poster was just "curious" - although people may well give useful information to each other as a direct result of its existence...
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!
I use the Slackware scripts(some hacks here and there).
/etc/rc.d/rc.goatd start to start my goat daemon(I don't think there's such a thing, better check Goo gle to make sure), for example.
I have never felt the need to control whatever service is started at init, I never have many services either. And the ones I don't need I might as well start manually. Just a simple
I totally dislike the way the scipts are handled in RedHat and such popular distrubutions. I hate INODE spam, that's why I use devfs(yes, I know that it is deprecated, I'm also using a deprecated kernel(2.6.2-pre2, maybe), but as long as there are no problems I will not really care.).
The classic essay on "worse is better" is either misunderstood
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.
I mean if we are going to pay sco to use linux we might as well use something besides errno.h and abi eh?
But seriously I agree with the poster I love my sys-v init on SuSE
Wang33
PAGERANK++ Robsell.com
I think I'm going to upgrade to BOOT.ini.
"Derp de derp."
I like staying close to the metal on my machine. /etc/rc.local has my customization, other stuff is run manually from ~root/.bash_history. I don't like layers, and hence `linuxconf` is beneath contempt.
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."
Having written my own init scripts and played with BSD, the one thing I miss in BSD is he ability to switch run levels. SysV is a bit much with run levels from 0 to 6. I'd like 3 run levels. single user, multi user, multi with X. I don't really think that the need for 0 and 6 is really there. Instead of saying init 0 or init 6 why not just say reboot or shutdown and skip the init sequence. That is about all I ever use. BSD has boot -s and multi, so if they were to adopt one more I'd be happy with them.
Truth is most people only use 2 .. either runlevel 3 or 5 and single user mode....
Only 'flamers' flame!
Does slashdot hate my posts?
If you had bothered to actually look at Gentoo's bootscripts, you would have noticed there is no python. It is all bash based.
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.
I love Gentoo's system. It's everything an RC system should be and more. Everything else is antiquated junk IMO.
-73, de n1ywb
www.n1ywb.com
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
Its nice to have /etc/inittab for some workstations, but I could easily configure it in both styles. The only really annoying thing, different directories for startup scripts. I like /etc/init.d, so I have to symlink on some systems, just easier that way.
BSD style seems a little more work, for no more gain.
Parent apparently decided to "minimise" grammer and "maximise" misspellings.
IBM Dev Pages had an interesting view on this. Althougt it is more for desktop setups (system boots faster - who needs that?). But still it is IMO interesting: Boot Linux Faster.
okay, here in Canada, we have two official spellings: 'minimize' or 'minimise', and in the UK they go so far as to only use the second spelling. Anyway, it's sort of the pot calling the kettle black, seeing as 'grammar' is spelled with two A's.
Standing at the very edge of my imagination, I peered into the inky void and realised -- I couldn't think up a new sig.
For setup and forget, you can't beat BSD init. Sure, as BSD boxen mostly fall into this category (servers).
Now if you're tinkering with your box, you need something like runlevels and separate start/stop script for every daemon and some more things out there. Either traditional SysV or the new parallel style that's emerging from Gentoo and some other places.
But in the end, you'll most likely stick with what your favourite distro provides.
I've got to say that I've gotten used to the "Red Hat Style" startup, especially in the past couple of years where you have an /etc/init.d/ directory to do things like /etc/init.d/httpd restart or whatever.
/usr/local/ndc restart, or was it kill -HUP `cat /var/run/named.pid`... A simple /etc/init.d/named restart takes care of it. Sounds like freebsd has a real similar way of doing this too.
One thing I've disliked about BSD style startup is that while there is a lot of potential, a busy admin is all-too-likely to just pop one more line in rc.local and call it good.
It's nice not to have to recall every bizarre syntax for daemon restarts -- lets see, is it
Look on the bright side -- anything is better than start->control panel->services->pick service->right-click->advanced tab->dependencies->etc. etc. yikes...
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
Though partially a joke, I mean that as a not entirely unserious preference.
/tmp and /var.
And nothing more. I can do all that in about
15 lines, why do I need that scattered over
half as many files?
When I started learning to use Linux, I found the layout of init scripts as one of the single most confusing "features". Once the system makes it up, everything seems so simple as to make you cry when you need to admin a Windows box. You invoke a program, it has a corresponding process, you can kill that process if you want to. Even "special" programs, such as daemons, work that way. Only kernel modules really differ, and even they have a conceptually similar interface - You can insmod, lsmod, and rmmod to start, check, and kill them (if applicable).
But then we come to init scripts... Oy. What runs when? What order? With what permissions? Does script X really run, or just take up space in the rc.d directory? Yeah, I know how to answer all of those questions, and know the default answers for a few different styles, but I don't see the need to have them as questions at all. In many ways, a nice monolithic autoexec.bat-style boot script would, for the vast majority of installations, more than suffice.
On my own systems, I usually go through and remove 99% of the init crap. I want to fsck my disks and then mount them, actvate swap if needed, start dhcpd or set up a static interface, load sshd and perhaps a handful of other daemons depending on the purpose of the machine, and perhaps clean up
On more than one system I control, I have inittab do nothing but rc.local, end of configuration. It works just fine, and anyone capable of using an up-and-running Linux box can tweak its bootup activity just as easily.
I started with Slackware, which primarily uses BSD style scripts. Therefore it is more natural for me. The other way, conversely, seems unnatural.
-- $SIGNATURE
If you're that worried about startup, why not roll your own scripts?
Hell, I remember a great approach to starting/init'ing services using Makefiles a few months back. The article can be found here:
http://lwn.net/Articles/50115/
That article inspired me to create my own binary that gets called from init. My binary is basically just a static series of system() calls. I chose these over exec() because they require one less call to sh.
Long story short - using a Makefile or a simple C binary can allow you to fine tune your startup. However, the flip side of this is that you'll have to know your system startup inside and out.
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
I've never really used runlevels at all, so I don't care much about that. What I do like is DJB's /service setup. It's easy to control daemons with the svc command, and if they ever crash they'll automatically be restarted.
For a short time I as applying this system to as much of the system as possible. It was very nice but it was alot of work so I've not used it recently except for qmail and friends.
Slackware's bsd-style init scripts were also good.
However, I do like using 'svscan' (DJB) behind the init scripts. Shutdown/restart/etc is simple and logging is handled well.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
I switched to Gentoo from Slackware a few months ago (I had been a slackware user for years).
I moved to Gentoo for the package management. I really miss the simplicity of Slackware's init scripts. Maybe it is just because I used it for years, but they are really easy and simple. However, I mostly only use one runlevel on my laptop (and who cares about init scripts on my servers since they never get rebooted).
I heard portage is getting ported to Slackware. I may have to go back to slackware.
... because they both (as typically implemented, anyway) start/stop each servide one at a time. Way too much unnecessary serialization!
A good system would explicitly know about dependencies, and would then concurrently start/stop everything for which the dependencies are already satisfied. That's what multi-tasking is for. Each time a daemon reports a successful start, all the other services whose dependencies are satisfied by it, would immediately be concurrently launched.
Problem is, no distribution seems to have standardized an implementation of this, although I've heard of experimental examples.
There's no good reason for computers to take forever to start and stop. We accept it because we're used to it. Aside from the fscking, the rest of the bootup should take only a few seconds.
Maybe I'm a bit old-fashioned with the "do-it-yourself" mentality, but I shy away from too much automation.
The second script runs something analagous to daemontools's svscan and runs svdirs, which are obviously superior to init scripts because you do not replicate any code. All of the start/stop/etc handling is done by the process that controls the daemon.
The most obvious benefits are that .pid files are obsolete as it's obvious which process is being run by the system (as it is a child of a runsv process that monitors it) and that services can be started in parallel with dependency handling. Additionally, runit will automatically restart processes that die/crash and handle logging their stderr to rotated logfiles via multilog.
Debian users can apt-get install runit runit-run and experience this themselves. I have run runit as process 0 on my laptop and desktop machines for months and use it on servers to monitor daemon processes, it has worked without a hitch. I highly recommend it (and wish that Debian would provide more runit svdirs for daemon processes :))
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".
There are a couple of init styles associated with Slackware's booting. . . The basic, and most prominent laying around are the rc.d startup scripts. Slackware also has a directory in /etc/rc.d/ where you can put all your init.d scripts. It is actually an extremely easy conversion if you want to do it.
YOU'RE WINNER !
Another lame blog
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.
to shut down oracle.
/etc/init.d/oracle 's stop) section.
You stick dbshut inside
If you want a controlled way to free resources which isn't handled by just sending a signal to a daemon, then it's nice to have a script that can handle it, and a procedure to call it.
Plus it's also nice to link in a K99final script into rc0.d that does something like unlock all tapes in a carousel, send a message to a router or load balancer or whatever.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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!
I totally agree with you here. The very least that they should offer is: /dev/hda1 /boot /dev/hda2 swap /dev/hda3 /root
Obviously, the more technical people can recommend something better, but the point should be clear.
As for 2 tabs or whatever, I agree. I hate having to see a diff of 2 files that have no significant changes. They smarttened up a bit by automatically merging comments. I think that people should be shot when they just spacing because it wastes everybody's time.
A cool option would be to autmatically merge init scripts but not the others.
testing out my trending skills
testing out my trending skills
Now I know why init scripts are one of the major dark areas remaining in my understanding of BSD and Linux: the entire subject area is flamebait.
I think there's a conceptual problem here. Whether a topic is flamebait or not does not stem from the topic, but the audience for the topic.
If my wife asks me "why are you angry?" and I respond "that's flamebait" does that reflect badly on me or my wife?
Probably more to the point, the reason this topic is flamebait is that init scripts are one of the great embarrassments of the BSD/Linux universe. It strikes me that the most passionate arguments occur around the most embarrassing features. In order to hide our embarrassment, we profess love.
Personally, I haven't seen an init script yet that if made human wouldn't show up at a Trek convention dressed as Wesley Crusher.
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?
Like VMWare, it just *expects* Sys V init, so installing it in Slackware is kinda painful for a newbie.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
It's a good thing you didn't put this in apple /., because by now otherwise you'd have everyone telling you their favourite was AppleScript.
I can't say that I don't give a fuck. I've just run out of fuck to give.
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.
Gentoo supports arbitrary runlevels.
/etc/runlevels. Use "rc-update add <service> <new runlevel>".
/etc/conf.d/rc.
For example, on my laptop I have boot, default, net, and X. Boot and default are the ones that come with Gentoo's base installation, and they have things like filesystem check, loading modules, hotplug, etc. Net loads PCMCIA modules and the driver for the wireless card, and I start it only if I actually have the card plugged in. X loads the sound drivers, video card modules, and xdm.
Setup: make a directory with the runlevel name in
Use: "rc <new runlevel>".
I'm not an old hand at this UNIX/BSD stuff like most people here seem to be, but I can't think of anything else I'd like from an init system.
P.S.- Gentoo supports parallel startup, too. It's a flag in
testing out my trending skills
Join moola.com, play games to earn money.
I found BSD-style scripts much simpler than sys V; you don't have a bunch of directories and files lying around on FreeBSD and Slackware Linux. I also love the two "runlevels" of FreeBSD; single-user and multiuser, isn't that clear? :-)
While we're on the subject about things we don't like with Gentoo ;)
It is very annoying that Gentoo's rc program was written in a compiled language. I feel as much as possible relating to init should be written in bash. I also don't like rc-update. Gentoo's init scripts are the most annoying things in the world. They aren't even bash scripts iirc. If you look at the top of one it's shebang is to another program (not running gentoo right now so I couldn't tell you which).
Best init scripts I think are the ones from Linux from Scratch. It uses symlinking (/etc/rc.d/rc3.d etc. etc.). It is basically all written in bash. The init scripts are simple as hell. It comes with a templete init script so you can write your own in the same style. Has external functions for cleanly loading and killing the process (loadproc and killproc). Gentoo's overly cluttered init system just leads to very messy init scripts. K.I.S.S.