All, I think this is a specific SLES 10 init hate. I don't know if RHAT or other perversions do this. And as I write this out multiple hates are foaming in my brain...
The software that my company makes, and that I install, support, and consult upon uses Oracle in the background. I know, this in and of itself is its own brand of hate. However, as we're probably well aware, in order to start Oracle two startup scripts must be launched, one for the Oracle Database software and the other for Oracle's TCP/IP listener, know as tnslistener. In troubleshooting an installation we found that the Oracle DB would start just fine but tnslistener would fail repeatedly acting as if the network isn't up and running. "That's Odd" I thought. The startup script is in /etc/rc3.d and by then the system should have the network up. Well, I didn't realize it at the time, but runlevels are not always runlevels when it comes to Linux. See, in the sane, SYSV world that we're all accustomed to (Solaris, HPUX, etc.) rc3.d is run-level three, aka multi-user and by then the network is up and running on the system. It seems to be that way in SLES, too, but the network doesn't start in rc2.d, it starts in rc3.d. So our S01tnslistener script, which works on most other platforms, fails to work on SLES since they have S10network in rc3.d. OK, no biggie, a simple rename and a reboot and.... tnslistener fails again in exactly the same way. "That's Odd" I ponder again, as the startup scripts are in the proper numerical order! After further research by the local Linux admin (since that's not my day job anymore) there were two pieces to the puzzle that I didn't have. First, the 'init' process has a "parallel_start" option. So this cute little bugger essentially gets to ignore the notion that startup scripts are cumulative and hierarchical. It just seems to fork() the startup scripts as quickly as reasonable regardless of what it cares about. But the geniuses at Novell(?) realized this could break things because they added functionality to the startup scripts. By including special comments you can declare dependencies. After that is done you use the chkconfig command to "register" the new startup script and then it will actually work. What the fuck were these people thinking? We have a startup script standard (the SYSV startup standard) that has been around for almost 20 years. It provides an orderly method of starting a system up and allowing for dependencies to start first before their antecedents. "Let's make our system have better bogomips by using fork() ! We can start multiple things at once for a faster boottime so we can play quake!" So that's neat, so then they have to develop two more hacks on top of it to allow for dependencies in startup scripts, adding complexity and gaining a few moments of boot time.
