|
What's the difference between Slackware startup scripts and System V startup scripts?
Author: kkeller
Slackware Release: Slackware 7.0 and higher
Written on: 2002-06-24
Okay, this answer is very long. Just a warning.
Slackware uses BSD-style init scripts; many other distros use System V-style init scripts. Both SysV scripts and BSD scripts are human-readable, in that they are shell scripts, not compiled programs. The main difference is in how the scripts are designed.
SysV scripts tend to take arguments like start, stop, restart, and others, depending on the program it's starting. So you could say something like /etc/ init.d/bind start to start BIND, and /etc/init.d/bind stop to stop BIND.
SysV-style init also tends to use symlinks to organize the boot process: in /etc/rc.d/rc.4/, there might be various symlinks to actual scripts in another directory. The symlinks are named like S10network, S25xdm, and so on, where the S means to start the service (K means kill it), and the numbers designate the order in which scripts should run.
The main advantage of SysV style init scripts is that they can be set up to configure a lot of stuff automagically. If, for example, you go into runlevel 6, you can have a symlink in /etc/rc.d/rc.6/ called K75bind, which will kill off BIND if the file to which its linked is set up to do that.
The main disadvantage of SysV style is that it's terribly convoluted. If I want to add a service, for example, I need to write a SysV-style script (which is certainly nontrivial) to at least handle "start" (and possibly "stop"). Then I need to make sure I've got the symlink set up correctly in each runlevel where I want it to run, and if I happen to need it to execute between two scripts that are consecutively numbered, I need to do some symlink renumbering (e.g., if S10xxx and S11yyy exist, and I want zzzz to run between, I need to resymlink one of those files to squeeze zzzz between them).
It's also a huge pain to alter the SysV boot process temporarily--if I want service xxx to not run on next boot, the easiest way is to remove the S10xxx symlink. Not too hard, but if I want to remove it from every runlevel, I need to remove the S10xxx symlink from every directory. Then if I change my mind and want xxx to run again, I need to recreate all of the appropriate symlinks by hand.
It's one extra level of complexity to the already-complicated boot process, and one which Slackware doesn't use: it uses BSD-style startup scripts instead.
BSD-style scripts are straight-ahead shell scripts that tend to run sequentially and don't take arguments like start or stop. They run when the system enters their runlevel, and that's it.
The main disadvantage of BSD-style is that you have to use some other method of controlling daemons. For example, if I want to stop BIND, I need to ps ax|grep named, find named's PID, and kill the pid. (Or I can find the pid file.) But I can't say /etc/init.d/bind stop (unless I write a SysV-style script for that).
The main advantage of BSD-style scripts is that they're terribly easy to read and edit. For example, if I add a new service zzzz, I can add the line /usr/ local/bin/zzzz to /etc/rc.d/rc.local, and zzzz will run in the runlevels where rc.local executes. If I know I want zzzz only in runlevel 4, I can put it in /etc/ rc.d/rc.4 (no longer a directory, but a shell script). If I need to change the order, I can just put the call to zzzz between the services where it should run; most editors can handle inserting text in the middle of a file (even ed!). Also, you can easily comment out a service to stop it from running, and uncomment it later.
So, while most distributions use SysV style, Slackware uses BSD-style. For many Slackware users, the ease-of-use of the BSD-style greatly outweighs the power of SysV-style. You can certainly form your own opinion. 
Contrary to popular belief, it's not that difficult to switch from one style to the other--just grab the inittab and rc files from one system and copy them to another. The init binary itself is not changed--most of the ''style'' is set in inittab and the scripts it calls. |
|