What's the difference between Slackware startup scripts and System V startup scripts?
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.
好了，說來話長。莫謂言之不預也。
Slackware 使用BSD風格的init腳本，而很多別的發行版使用System V風格的init腳本。SysV和BSD腳本都是能讓人讀懂的，即它們都是shell腳本，而不是已編譯的程序。主要的區別在于腳本是如何設計的。
SysV腳本傾向于接受諸如start、stop、restart之類的參數，依它所啟動的程序而定。所以你可以用 /etc/init.d/bind start 這樣的命令來啟動BIND，并用 /etc/init.d/bind stop 來停止BIND。
SysV的啟動還傾向于使用符號鏈接來組織啟動進程，例如在 /etc/rc.d/rc.4/中，可能會有指向別的目錄中的真正的腳本的各種各樣的符號鏈接。這些鏈接的命令會像是 S10network、S25xdm之類，其中的S表示啟動(start)該項服務(如果是K，則表示kill)，而數字指定了腳本執行的順序。
SysV風格的啟動腳本的主要優點在于能夠設置成自動配置許多東西。例如，若你進入runlevel 6，你可以建立一個鏈接叫K75bind來終止BIND，前提是鏈接所指向的文件已經設置好來做這件事。
SysV風格腳本的主要缺點是太過彎彎繞。假如我想增加一個服務，我要先寫一個SysV風格的腳本(不是容易的事)，它至少要處理“start”(還可能有“stop”)。然后，我必須確保在每個要運行這個服務的runlevel中正確地設置好符號鏈接。如果恰好這個服務需要在已經連續編號的兩個腳本之間運行，我就需要做一些對符號鏈接重新編號的工作(例如，S10xxx和S11yyy已經存在，而我想讓zzzz在它們之間運行，我就需要對前兩者之一重新建立符號鏈接來把zzzz擠進去)。
想暫時改變SysV的啟動進程也是非常痛苦的事情。假如我不想在下次啟動時運行xxx服務，最簡單的辦法是刪除S10xxx這個鏈接，不算難吧？但如果我想在每個runlevel中都去掉它，我就需要從每個有關目錄中刪除S10xxx這個鏈接。然后，假如我改了主意，想重新運行xxx，我需要手工重新建立所有的符號鏈接。
這樣子無疑是在已經很復雜的啟動進程上疊床架屋，而Slackware是不會這么做的：它用BSD風格的啟動腳本。
BSD風格的腳本是直接了當的shell腳本，它們傾向于順序運行，而不需要start或stop之類參數。只要系統進入了它們的runlevel就會執行，就這么簡單。
BSD風格的主要缺點是你需要一些其他方法來控制后臺服務。例如，若我要停止BIND，我要先用命令 ps ax|grep named 找出 named的PID，然后kill這個PID(或者用這個pid的文件名)。但是我不能簡單地下個命令 /etc/init.d/bind stop (除非我已經寫了個這樣的SysV腳本)。
BSD風格腳本的主要優點是它們非常容易閱讀和編輯。例如，若我想增加一個服務zzzz，我可以在 /etc/rd.d/rc.local中增加一行 /usr/local/bin/zzzz，這樣只要是執行rc.local的runlevel，zzzz就會隨之運行。假如我只想在runlevel 4執行zzzz，我可以把它放在 /etc/rc.d/rc.4 (不是目錄，而是一個腳本)中。如果我要改變執行順序，我只要把zzzz放在適當的服務之間，多數編輯器都支持在文件中間插入文本(就算ed都支持)。還有，你可以用注釋的方式停止一個服務，然后去掉注釋讓它重新運行。
因此，當多數發行版采用SysV風格時，Slackware采用了BSD風格。對于許多Slackware用戶，BSD風格的易用性勝過SysV風格的強大功能。當然，你可以有自己的意見。
與普遍的觀點相反，從一種風格轉到另一種并不那么困難，只要把inittab和rc文件從一個系統拷貝到另一個系統即可。init程序自身沒有改變，所謂“風格”多是在inittab和它所調用的腳本中設置的。
譯注：現在slackware為了提高兼容性，在/etc/rc.d/提供了rc.sysvinit腳本以適應某些基于SysV啟動過程的商業程序的需要。另外，在許多設置服務的腳本中，也接受start、stop、restart這一類參數，例如rc.sendmail、rc.sshd等。
66821730(技術支持)
