Using another startup method besides SysV: totally reasonable. Lying to users by pretending that you are still using SysV when you are not: jaw-dropping.
-josh On Wed, Dec 31, 2008 at 04:49:23PM -0500, Jonathan Katz wrote: > 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.
