了解Linux系統(tǒng)的發(fā)展歷程，能夠更好的了解系統(tǒng)，掌握系統(tǒng)。
systemvinit -- >?upstart?-- > systemd
UPSTART（https://www.cnblogs.com/plxx/p/5493073.html? 這個link也不錯）
前言
眾所周知，/sbin/init 是linux內(nèi)核啟動后運行的首個用戶進程，早期的init程序由sysvinit包提供。 SysVinit軟件包包含了一組控制系統(tǒng)最基本函數(shù)的進程，它包含了系統(tǒng)初始化程序init，init 是系統(tǒng)啟動時被kernel最先啟動的進程，它控制著其它所有進程的啟動、運行以及停止。Sysvinit 中的init daemon 是一個基于運行級別的初始化程序，它使用了運行級別（如單用戶、多用戶等）并通過從 /etc/rc?.d 目錄到 /etc/init.d 目錄的初始化腳本的鏈接來啟動與終止系統(tǒng)服務(wù)。例如大家熟悉的級別3進入text模式，級別5為graphis模式；以及/etc/rc?.d 目錄下數(shù)字代表啟動的優(yōu)先級，K代表停止某個服務(wù)，S代表啟動服務(wù)等。
Ubuntu 從6.10版本開始使用 upstart來代替sysvinit， upstart包提供了新的init daemon。Upstart init daemon 本質(zhì)上不是基于運行級別的啟動init進程，但為了跟傳統(tǒng)的sysvinit兼容，upstart提供了兼容的runlevel和telinit等工具，以及也使用/etc/rc?.d 作為啟動或者停止某個服務(wù)。但運行級別3不在是text模式，而且也不能通過改變運行級別來改變進入text模式。
Upstart 初探
Upstart 跟Sysvinit 本質(zhì)上一樣，都是用于linux開機自動啟動某些后臺服務(wù)，同時還承擔監(jiān)控這些服務(wù)運行狀態(tài)的功能。但Sysvinit中的init daemon 不能解決諸如系統(tǒng)接收到打印機等熱插拔事件安裝時來啟動某種特定的服務(wù)這類問題，而upstart則可以。
ustart init daemon 是基于事件的，當系統(tǒng)中的什么情況發(fā)生變化時，它會運行某個特定的程序。這里被運行的程序多半是用來啟動或終止服務(wù)的腳本。這個配置方式和systemv 在系統(tǒng)進入某個運行級別的時候運行init腳本的鏈接的概念實際上是非常類似的，只不過 upstart 更加靈活一些。Upstart 不僅能在運行級別改變的時候啟動或終止服務(wù)，也能在接收到系統(tǒng)發(fā)生其他改變的信息的時候啟動或終止服務(wù)。這些系統(tǒng)的改變被稱為“事件”。例如，當 upstart 從 udev 接收到運行時文件系統(tǒng)加載、打印機安裝或其他類似的設(shè)備添加或刪除的信息，并采取相應(yīng)的行動。Upstart 也可以在系統(tǒng)啟動、關(guān)閉或某個任務(wù)狀態(tài)改變的時候啟動或關(guān)閉服務(wù)。
在upstart中存在如下幾個概念：
Process: process 是由jobs定義的services或者task，它將被init daemon 運行。 每個job可以定義一個或者多個不同的process，分別在其生命周期的不同狀態(tài)運行。Process 定義如下：
Exec COMMAND?
Scritp … end script?
Pre-start exec|script?
Post-start exec|script
Pre-stop exec|script?
Post-stop exec|script
Event： 事件，事件（event）是 init 可以得到的狀態(tài)變更信息。幾乎系統(tǒng)所有的內(nèi)部或外部狀態(tài)變更都可以觸發(fā)一個事件。比如，引導程序會觸發(fā)啟動（startup）事件，系統(tǒng)進入運行級別2會 觸發(fā)運行級別2（runlevel 2）事件，而文件系統(tǒng)加載則會觸發(fā)路徑加載（path-mounted）事件，拔掉或安裝一個熱插拔或USB設(shè)備（如打印機）也會觸發(fā)一個時間。用戶還可 以通過 initctl emit 命令來手動觸發(fā)一個事件。事件定義格式如下：
start? on Event [[KEY=] Value … and| or …]?
stop? on Event [[KEY=] Value … and| or …]
Job： 一個工作（job）是 init 可以理解的一系列指令。典型的指令包括一個程序（二進制文件或是腳本）和事件的名稱。Upstart init daemon 會在事件觸發(fā)的時候運行相應(yīng)的程序。用戶可以分別用 initctl start 和 stop 命令手動啟動或終止一項工作。工作又可以分為任務(wù)和服務(wù)。
My? job 示例
用戶也可以自己定義一個事件，并讓一個工作被這個事件觸發(fā)。如下的 myjob 工作定義文件定義了一個被 hithere 事件觸發(fā)的工作：
$cat /etc/event.d/myjob
start on hithere script ??? ? ? ?
echo “Hi there, here I am!” > /tmp/myjob.out? ????????
date >> /tmp/myjob.out
end script
myjob 文件提供了另一種運行命令的方法：在 script 和 end script 關(guān)鍵字之間包含了兩行命令。這兩個關(guān)鍵字常常導致 init 去運行 /bin/sh。例中的命令將一條消息和日期輸出到了 /tmp/myjob.out 文件。現(xiàn)在可以使用 initctl emit 命令觸發(fā)這個工作。如下，init 展示了 myjobs 在我們的觸發(fā)下所經(jīng)歷的各個狀態(tài)：
$sudo initctl emit hithere
$cat /tmp/myjob.out?
Hi there, here I am!
Sun Apr 24 13:25:43 CST 2011
$sudo initctl list ?| grep myjob?
myjob (stop) waiting
在上面的例子里，cat 展示了 myjob 產(chǎn)生的輸出，initctl 展示了工作的狀態(tài)。同樣也可以用 initctl start myjob（或直接用 start myjob）來運行它。initctl start 十個非常有用的命令，這樣你就可以在沒有事件的情況下啟動一個工作。比如，你可以用 initctl start mudat 來直接運行前面例子中的 mudat 工作而不會觸發(fā) runlevel 2 事件。
Upstart 事件監(jiān)控實現(xiàn)
在init daemon 中需要監(jiān)測某個進程的狀態(tài)，例如存在repasw機制，監(jiān)測getty進程是否退出，如果退出則需要再次啟動getty以便用戶登錄。 為實現(xiàn)對事件的監(jiān)測，要么采用輪詢要么采用事件驅(qū)動的回調(diào)機制，upstart采用事件驅(qū)動機制。為實現(xiàn)基于事件驅(qū)動的機制，通常涉及跨進程調(diào)用，Upstart利用dbus來完成iPC通信。但upstart init daemon啟動時dbus-daemon并沒有運行，實際dbus-daemon是由upstart來啟動。因此，upstart 采用? private D-bus 連接（unxi:address=/com/ubuntu/upstart）來實現(xiàn)IPC；其它進程（如telinit等）通過該連接來通知init daemon 產(chǎn)生某個事件。
Upstart init daemon 運行時會產(chǎn)生startup事件，在/etc/init下很多job都start on 該事件，其中比較著名的是：
rc-default job . 該job會調(diào)用telinit N來登錄N用戶級別，同時產(chǎn)生runevel事件。而runevel事件觸發(fā)ttyN job，從而調(diào)用getty程序。對于圖形界面的登錄程序如gdm的觸發(fā)為另外的條件，后面再續(xù)。
為完成監(jiān)控內(nèi)核事件，例如usb的熱插拔，upstart提供upstart-udev-bridge.conf job來完成該功能,即在/etc/init 下存在upstart-udev-bridge.conf 文件。當udev event發(fā)生時，該job將產(chǎn)生 upstart事件通知init。這類事件通常采用如下格式：
“-device-
因此upstart-udev-bridge.conf 可能為：
net-device-added net-device-removed graphics-device-added drm-device-added
用戶自動登錄和定制XWindows
在工作中，常常存在如下需求：
開機運行l(wèi)inux，自動登錄，無需輸入用戶名密碼；
登錄后自動運行我們的GUI軟件，且無需ubuntu等桌面環(huán)境
在使用upstart的ubuntu系統(tǒng)中，控制登錄的腳本主要是：
/etc/init/ttyN.conf
/etc/init/gdm.conf
Gdm.conf用戶啟動gdm，即ubuntu的圖形桌面；由于我們并不需要桌面，因此首先刪除gdm.conf. 刪除gdm.conf將不能啟動linux GUI桌面，但由于我們開機運行的GUI軟件本質(zhì)還是一個X11 Client程序，因此需要啟動X Server。這時可以startx 腳本就派生用場了，在傳統(tǒng)的用戶text模式下，大都通過startx進入GUI系統(tǒng)。因此我們可以配置.xinitrc 腳本： 例如如下:
// user gui programmer
Metacity
為保證用戶登錄后即運行startx，可以在~/.bash_profile 中寫入：
exec startx
上述過程保證了用戶登錄后即運行startx 啟動了用戶程序，但如何實現(xiàn)用戶自動登錄呢？ 這需要修改/etc/init/ttyN.conf ，默認使用getty程序登錄，該程序不支持用戶自動登錄。Linux下有一個叫minigetty 程序支持該功能，下載并修改/etc/init/ttyN.conf 文件，大致如下：
Exec /sbin/mingetty –autologin root tty1
其它init 實現(xiàn)
Systemd是一個比upstart設(shè)計思路更超前的init系統(tǒng)，見http://0pointer.de/blog/projects/systemd.html。?? 其核心是為了加快linux的啟動速度，研究如何并行化啟動init以后的用戶進程，可以參考http://linuxtoy.org/archives/more-than-upstart-systemd.html
//SysVinit（https://blog.csdn.net/weixin_34040079/article/details/92395376?這個link也不錯）
剛開始網(wǎng)上查/etc/rc.local能實現(xiàn)開機自動運行腳本..但是不知道為啥..
后來偶然在rc?.d/README發(fā)現(xiàn)了玄機...再后來一直順著README的方向看下去...終于明白了
Ubuntu 的 運行級別
0 系統(tǒng)停機
1 單用戶或系統(tǒng)維護狀態(tài)
2~5 多用戶
6 重新啟動
我們通常運行的2~5級別
/etc/rc2.d/README 摘要
The scripts in this directory are executed each time the system enters
this runlevel.
The scripts are all symbolic links whose targets are located in
/etc/init.d/ .
To disable a service in this runlevel, rename its script in this
directory so that the new name begins with a 'K' and a two-digit
number, and run 'update-rc.d script defaults' to reorder the scripts
according to dependencies.? A warning about the current runlevels
being enabled not matching the LSB header in the init.d script will be
printed.? To re-enable the service, rename the script back to its
original name beginning with 'S' and run update-rc.d again.
For a more information see /etc/init.d/README.
這個目錄的腳本在系統(tǒng)進入這個運行級別的時候就被啟動.
這些腳本全是目標位于/etc/init.d/的符號鏈接
S??XXX, S代表啟動,K代表停止,??數(shù)字代表順序
root@ubuntu:/etc/rc2.d# ll
total 20
drwxr-xr-x? 2 root root? 4096? 7月 27 10:21 ./
drwxr-xr-x 131 root root 12288? 7月 27 10:04 ../
-rw-r--r--? 1 root root? 677? 6月? 4? 2013 README
lrwxrwxrwx? 1 root root? ? 20? 7月 25 22:19 S20kerneloops -> ../init.d/kerneloops*
lrwxrwxrwx? 1 root root? ? 27? 7月 25 22:19 S20speech-dispatcher -> ../init.d/speech-dispatcher*
lrwxrwxrwx? 1 root root? ? 15? 7月 25 22:19 S50rsync -> ../init.d/rsync*
lrwxrwxrwx? 1 root root? ? 15? 7月 25 22:19 S50saned -> ../init.d/saned*
lrwxrwxrwx? 1 root root? ? 19? 7月 25 22:19 S70dns-clean -> ../init.d/dns-clean*
lrwxrwxrwx? 1 root root? ? 18? 7月 25 22:19 S70pppd-dns -> ../init.d/pppd-dns*
lrwxrwxrwx? 1 root root? ? 14? 7月 25 22:19 S75sudo -> ../init.d/sudo*
lrwxrwxrwx? 1 root root? ? 21? 7月 25 22:19 S99grub-common -> ../init.d/grub-common*
lrwxrwxrwx? 1 root root? ? 18? 7月 25 22:19 S99ondemand -> ../init.d/ondemand*
lrwxrwxrwx? 1 root root? ? 18? 7月 25 22:19 S99rc.local -> ../init.d/rc.local*
可以看出S99rc.local 會啟動 /etc/init.d/rc.local 且是最后執(zhí)行的
來到/etc/init.d,查看README
Configuration of System V init under Debian GNU/Linux
Most Unix versions have a file here that describes how the scripts
in this directory work, and how the links in the /etc/rc?.d/ directories
influence system startup/shutdown.
For Debian, this information is contained in the policy manual, chapter
"System run levels and init.d scripts".? The Debian Policy Manual is
available at:
? ? http://www.debian.org/doc/debian-policy/#contents
The Debian Policy Manual is also available in the Debian package
"debian-policy".? When this package is installed, the policy manual can be
found in directory /usr/share/doc/debian-policy. If you have a browser
installed you can probably read it at
? ? file://localhost/usr/share/doc/debian-policy/
Some more detailed information can also be found in the files in the
/usr/share/doc/sysv-rc directory.
Debian Policy dictates that /etc/init.d/*.sh scripts must work properly
大多數(shù)的Unix版本在這里的文件描述了這個文件夾的腳本怎樣工作 --- (額，這句貌似在說README，廢話么)
?...xxx.xxx..xxx一堆跟前面的README重復(fù)的話
直接來到它說的網(wǎng)站,來到http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit
粘一下（字很小,建議查看源網(wǎng)站）:
9.3 System run levels and init.d scripts
9.3.1 Introduction
The /etc/init.d directory contains the scripts executed by init at boot time and when the init state (or "runlevel") is changed (see init(8)).
There are at least two different, yet functionally equivalent, ways of handling these scripts. For the sake of simplicity, this document describes only the symbolic link method. However, it must not be assumed by maintainer scripts that this method is being used, and any automated manipulation of the various runlevel behaviors by maintainer scripts must be performed using update-rc.d as described below and not by manually installing or removing symlinks. For information on the implementation details of the other method, implemented in the file-rc package, please refer to the documentation of that package.
These scripts are referenced by symbolic links in the /etc/rcn.d directories. When changing runlevels, init looks in the directory /etc/rcn.d for the scripts it should execute, where n is the runlevel that is being changed to, or S for the boot-up scripts.
The names of the links all have the form Smmscript or Kmmscript where mm is a two-digit number and script is the name of the script (this should be the same as the name of the actual script in /etc/init.d).
When init changes runlevel first the targets of the links whose names start with a K are executed, each with the single argument stop, followed by the scripts prefixed with an S, each with the single argument start. (The links are those in the /etc/rcn.d directory corresponding to the new runlevel.) The K links are responsible for killing services and the S link for starting services upon entering the runlevel.
For example, if we are changing from runlevel 2 to runlevel 3, init will first execute all of the K prefixed scripts it finds in /etc/rc3.d, and then all of the S prefixed scripts in that directory. The links starting with K will cause the referred-to file to be executed with an argument of stop, and the S links with an argument of start.
The two-digit number mm is used to determine the order in which to run the scripts: low-numbered links have their scripts run first. For example, the K20 scripts will be executed before the K30 scripts. This is used when a certain service must be started before another. For example, the name server bind might need to be started before the news server inn so that inn can set up its access lists. In this case, the script that starts bind would have a lower number than the script that starts inn so that it runs first:
? ? /etc/rc2.d/S17bind
? ? /etc/rc2.d/S70inn
The two runlevels 0 (halt) and 6 (reboot) are slightly different. In these runlevels, the links with an S prefix are still called after those with a K prefix, but they too are called with the single argument stop.
9.3.2 Writing the scripts
Packages that include daemons for system services should place scripts in /etc/init.d to start or stop services at boot time or during a change of runlevel. These scripts should be named /etc/init.d/package, and they should accept one argument, saying what to do:
start
start the service,
stop
stop the service,
restart
stop and restart the service if it's already running, otherwise start the service
reload
cause the configuration of the service to be reloaded without actually stopping and restarting the service,
force-reload
cause the configuration to be reloaded if the service supports this, otherwise restart the service.
The start, stop, restart, and force-reload options should be supported by all scripts in /etc/init.d, the reload option is optional.
The init.d scripts must ensure that they will behave sensibly (i.e., returning success and not starting multiple copies of a service) if invoked with start when the service is already running, or with stop when it isn't, and that they don't kill unfortunately-named user processes. The best way to achieve this is usually to use start-stop-daemon with the --oknodo option.
Be careful of using set -e in init.d scripts. Writing correct init.d scripts requires accepting various error exit statuses when daemons are already running or already stopped without aborting the init.d script, and common init.d function libraries are not safe to call with set -e in effect[81]. For init.d scripts, it's often easier to not use set -e and instead check the result of each command separately.
If a service reloads its configuration automatically (as in the case of cron, for example), the reload option of the init.d script should behave as if the configuration has been reloaded successfully.
The /etc/init.d scripts must be treated as configuration files, either (if they are present in the package, that is, in the .deb file) by marking them as conffiles, or, (if they do not exist in the .deb) by managing them correctly in the maintainer scripts (see Configuration files, Section 10.7). This is important since we want to give the local system administrator the chance to adapt the scripts to the local system, e.g., to disable a service without de-installing the package, or to specify some special command line options when starting a service, while making sure their changes aren't lost during the next package upgrade.
These scripts should not fail obscurely when the configuration files remain but the package has been removed, as configuration files remain on the system after the package has been removed. Only when dpkg is executed with the --purge option will configuration files be removed. In particular, as the /etc/init.d/package script itself is usually a conffile, it will remain on the system if the package is removed but not purged. Therefore, you should include a test statement at the top of the script, like this:
? ? test -f program-executed-later-in-script || exit 0
Often there are some variables in the init.d scripts whose values control the behavior of the scripts, and which a system administrator is likely to want to change. As the scripts themselves are frequently conffiles, modifying them requires that the administrator merge in their changes each time the package is upgraded and the conffile changes. To ease the burden on the system administrator, such configurable values should not be placed directly in the script. Instead, they should be placed in a file in /etc/default, which typically will have the same base name as the init.d script. This extra file should be sourced by the script when the script runs. It must contain only variable settings and comments in SUSv3 sh format. It may either be a conffile or a configuration file maintained by the package maintainer scripts. See Configuration files, Section 10.7 for more details.
To ensure that vital configurable values are always available, the init.d script should set default values for each of the shell variables it uses, either before sourcing the /etc/default/ file or afterwards using something like the : ${VAR:=default} syntax. Also, the init.d script must behave sensibly and not fail if the /etc/default file is deleted.
Files and directories under /run, including ones referred to via the compatibility paths /var/run and /var/lock, are normally stored on a temporary filesystem and are normally not persistent across a reboot. The init.d scripts must handle this correctly. This will typically mean creating any required subdirectories dynamically when the init.d script is run. See /run and /run/lock, Section 9.1.4 for more information.
9.3.3 Interfacing with the initscript system
Maintainers should use the abstraction layer provided by the update-rc.d and invoke-rc.d programs to deal with initscripts in their packages' scripts such as postinst, prerm and postrm.
Directly managing the /etc/rc?.d links and directly invoking the /etc/init.d/ initscripts should be done only by packages providing the initscript subsystem (such as sysv-rc and file-rc).
9.3.3.1 Managing the links
The program update-rc.d is provided for package maintainers to arrange for the proper creation and removal of /etc/rcn.d symbolic links, or their functional equivalent if another method is being used. This may be used by maintainers in their packages' postinst and postrm scripts.
You must not include any /etc/rcn.d symbolic links in the actual archive or manually create or remove the symbolic links in maintainer scripts; you must use the update-rc.d program instead. (The former will fail if an alternative method of maintaining runlevel information is being used.) You must not include the /etc/rcn.d directories themselves in the archive either. (Only the sysvinit package may do so.)
By default update-rc.d will start services in each of the multi-user state runlevels (2, 3, 4, and 5) and stop them in the halt runlevel (0), the single-user runlevel (1) and the reboot runlevel (6). The system administrator will have the opportunity to customize runlevels by simply adding, moving, or removing the symbolic links in /etc/rcn.d if symbolic links are being used, or by modifying /etc/runlevel.conf if the file-rc method is being used.
To get the default behavior for your package, put in your postinst script
? ? update-rc.d package defaults
and in your postrm
? ? if [ "$1" = purge ]; then
? ? update-rc.d package remove
? ? fi
. Note that if your package changes runlevels or priority, you may have to remove and recreate the links, since otherwise the old links may persist. Refer to the documentation of update-rc.d.
This will use a default sequence number of 20. If it does not matter when or in which order the init.d script is run, use this default. If it does, then you should talk to the maintainer of the sysvinit package or post to debian-devel, and they will help you choose a number.
For more information about using update-rc.d, please consult its man page update-rc.d(8).
9.3.3.2 Running initscripts
The program invoke-rc.d is provided to make it easier for package maintainers to properly invoke an initscript, obeying runlevel and other locally-defined constraints that might limit a package's right to start, stop and otherwise manage services. This program may be used by maintainers in their packages' scripts.
The package maintainer scripts must use invoke-rc.d to invoke the /etc/init.d/* initscripts, instead of calling them directly.
By default, invoke-rc.d will pass any action requests (start, stop, reload, restart...) to the /etc/init.d script, filtering out requests to start or restart a service out of its intended runlevels.
Most packages will simply need to change:
? ? /etc/init.d/<package>
? ? ? ? ? <action>
in their postinst and prerm scripts to:
? ? if which invoke-rc.d >/dev/null 2>&1; then
? ? invoke-rc.d package <action>
? ? else
? ? /etc/init.d/package <action>
? ? fi
A package should register its initscript services using update-rc.d before it tries to invoke them using invoke-rc.d. Invocation of unregistered services may fail.
For more information about using invoke-rc.d, please consult its man page invoke-rc.d(8).
9.3.4 Boot-time initialization
There used to be another directory, /etc/rc.boot, which contained scripts which were run once per machine boot. This has been deprecated in favour of links from /etc/rcS.d to files in /etc/init.d as described in Introduction, Section 9.3.1. Packages must not place files in /etc/rc.boot.
9.3.5 Example
An example on which you can base your /etc/init.d scripts is found in /etc/init.d/skeleton.
翻譯如下:
介紹
/etc/init.d目錄包含著當運行級別改變時在boot時啟動的腳本(不是重點)
有兩點不同...一堆廢話夾中間...出于易讀考慮,這篇文檔只描述符號鏈接方法.xxx xxx...
不同運行級別的自動化操作必須用update-rc.d來安裝或者刪除符號鏈接.
然后...K代表停止,S代表執(zhí)行,數(shù)字代表順序(前面已說過)
寫腳本
包含系統(tǒng)服務(wù)daemon(后臺程序)的packages(包)應(yīng)該把腳本放在/etc/init.d來開啟和停止服務(wù)at boot time 或者 during ?a change of runlevel,
這些腳本應(yīng)該被命名為/etc/init.d/package,他們應(yīng)該接受這些參數(shù)
start
start the service,
stop
stop the service,
restart
stop and restart the service if it's already running, otherwise start the service
reload
cause the configuration of the service to be reloaded without actually stopping and restarting the service,
force-reload
cause the configuration to be reloaded if the service supports this, otherwise restart the service.
在init.d里面的腳本都應(yīng)該支持這些參數(shù).
管理鏈接(重要)
By default update-rc.d will start services in each of the multi-user state runlevels (2, 3, 4, and 5) and stop them in the halt runlevel (0), the single-user runlevel (1) and the reboot runlevel (6).
默認update-rc.d會在多人運行級別(2,3,4,5)和在停止級別(halt level(0)),單人級別(1)開啟服務(wù)命令!:
update-rc.d package defaults 添加鏈接
and in your postrm 在你的發(fā)出的移除命令中
if [ "$1" = purge ]; then
? ? update-rc.d package remove
? ? fi
可以看出 update-rc.d package remove是移除鏈接 參數(shù)-f代表強制(如果init.d沒有該腳本)
init.d腳本例子:
An example on which you can base your /etc/init.d scripts is found in /etc/init.d/skeleton.
----------------另外我知道的比如/etc/init.d/mysqld start 可以寫為 service mysqld start
============================================rc.local實現(xiàn)開機啟動腳本原理================================================
root@ubuntu:/etc/rc2.d# ll
total 20
drwxr-xr-x? 2 root root? 4096? 7月 27 10:21 ./
drwxr-xr-x 131 root root 12288? 7月 27 10:04 ../
-rw-r--r--? 1 root root? 677? 6月? 4? 2013 README
lrwxrwxrwx? 1 root root? ? 20? 7月 25 22:19 S20kerneloops -> ../init.d/kerneloops*
lrwxrwxrwx? 1 root root? ? 27? 7月 25 22:19 S20speech-dispatcher -> ../init.d/speech-dispatcher*
lrwxrwxrwx? 1 root root? ? 15? 7月 25 22:19 S50rsync -> ../init.d/rsync*
lrwxrwxrwx? 1 root root? ? 15? 7月 25 22:19 S50saned -> ../init.d/saned*
lrwxrwxrwx? 1 root root? ? 19? 7月 25 22:19 S70dns-clean -> ../init.d/dns-clean*
lrwxrwxrwx? 1 root root? ? 18? 7月 25 22:19 S70pppd-dns -> ../init.d/pppd-dns*
lrwxrwxrwx? 1 root root? ? 14? 7月 25 22:19 S75sudo -> ../init.d/sudo*
lrwxrwxrwx? 1 root root? ? 21? 7月 25 22:19 S99grub-common -> ../init.d/grub-common*
lrwxrwxrwx? 1 root root? ? 18? 7月 25 22:19 S99ondemand -> ../init.d/ondemand*
lrwxrwxrwx? 1 root root? ? 18? 7月 25 22:19 S99rc.local -> ../init.d/rc.local*
有了上部分的理論基礎(chǔ)，從上面S99rc.local可看出，系統(tǒng)會在開機時啟動/etc/init.d/rc.local看看/etc/init.d/rc.local有什么東西
#! /bin/sh
### BEGIN INIT INFO
# Provides:? ? ? ? ? rc.local
# Required-Start:? ? $all
# Required-Stop:
# Default-Start:? ? 2 3 4 5
# Default-Stop:
# Short-Description: Run /etc/rc.local if it exist
### END INIT INFO
PATH=/sbin:/usr/sbin:/bin:/usr/bin
. /lib/init/vars.sh
. /lib/lsb/init-functions
do_start() {
? ? ? ? if [ -x /etc/rc.local ]; then
? ? ? ? ? ? ? ? [ "$VERBOSE" != no ] && log_begin_msg "Running local boot scripts (/etc/rc.local)"
? ? ? ? ? ? ? ? /etc/rc.local
? ? ? ? ? ? ? ? ES=$?
? ? ? ? ? ? ? ? [ "$VERBOSE" != no ] && log_end_msg $ES
? ? ? ? ? ? ? ? return $ES
? ? ? ? fi
case "$1" in
? ? start)
? ? ? ? do_start
? ? ? ? ;;
? ? restart|reload|force-reload)
? ? ? ? echo "Error: argument '$1' not supported" >&2
? ? ? ? exit 3
? ? ? ? ;;
? ? stop)
? ? ? ? ;;
? ? *)
? ? ? ? echo "Usage: $0 start|stop" >&2
? ? ? ? exit 3
? ? ? ? ;;
esac
可以看出,/etc/init.d/rc.local會執(zhí)行/etc/rc.local這個腳本里面的內(nèi)容,也難怪在/etc/rc.local添加腳本會順利的執(zhí)行
————————————————
版權(quán)聲明：本文為CSDN博主「me10zyl」的原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/me10zyl/article/details/38168003
