upstart埃撵、SysVinit、Systemd //TODO

了解Linux系統(tǒng)的發(fā)展歷程虽另，能夠更好的了解系統(tǒng)暂刘，掌握系統(tǒng)。

systemvinit -- >?upstart?-- > systemd

UPSTART（https://www.cnblogs.com/plxx/p/5493073.html? 這個(gè)link也不錯(cuò)）

upstart 啟動(dòng)過程

前言

眾所周知捂刺，/sbin/init 是linux內(nèi)核啟動(dòng)后運(yùn)行的首個(gè)用戶進(jìn)程谣拣，早期的init程序由sysvinit包提供募寨。 SysVinit軟件包包含了一組控制系統(tǒng)最基本函數(shù)的進(jìn)程，它包含了系統(tǒng)初始化程序init森缠，init 是系統(tǒng)啟動(dòng)時(shí)被kernel最先啟動(dòng)的進(jìn)程拔鹰，它控制著其它所有進(jìn)程的啟動(dòng)、運(yùn)行以及停止贵涵。Sysvinit 中的init daemon 是一個(gè)基于運(yùn)行級(jí)別的初始化程序列肢，它使用了運(yùn)行級(jí)別（如單用戶、多用戶等）并通過從 /etc/rc?.d 目錄到 /etc/init.d 目錄的初始化腳本的鏈接來啟動(dòng)與終止系統(tǒng)服務(wù)宾茂。例如大家熟悉的級(jí)別3進(jìn)入text模式瓷马，級(jí)別5為graphis模式；以及/etc/rc?.d 目錄下數(shù)字代表啟動(dòng)的優(yōu)先級(jí)跨晴，K代表停止某個(gè)服務(wù)欧聘，S代表啟動(dòng)服務(wù)等。

Ubuntu 從6.10版本開始使用 upstart來代替sysvinit坟奥， upstart包提供了新的init daemon树瞭。Upstart init daemon 本質(zhì)上不是基于運(yùn)行級(jí)別的啟動(dòng)init進(jìn)程，但為了跟傳統(tǒng)的sysvinit兼容爱谁，upstart提供了兼容的runlevel和telinit等工具晒喷，以及也使用/etc/rc?.d 作為啟動(dòng)或者停止某個(gè)服務(wù)。但運(yùn)行級(jí)別3不在是text模式访敌，而且也不能通過改變運(yùn)行級(jí)別來改變進(jìn)入text模式凉敲。

Upstart 初探

Upstart 跟Sysvinit 本質(zhì)上一樣，都是用于linux開機(jī)自動(dòng)啟動(dòng)某些后臺(tái)服務(wù)寺旺，同時(shí)還承擔(dān)監(jiān)控這些服務(wù)運(yùn)行狀態(tài)的功能爷抓。但Sysvinit中的init daemon 不能解決諸如系統(tǒng)接收到打印機(jī)等熱插拔事件安裝時(shí)來啟動(dòng)某種特定的服務(wù)這類問題，而upstart則可以阻塑。

ustart init daemon 是基于事件的蓝撇，當(dāng)系統(tǒng)中的什么情況發(fā)生變化時(shí)，它會(huì)運(yùn)行某個(gè)特定的程序陈莽。這里被運(yùn)行的程序多半是用來啟動(dòng)或終止服務(wù)的腳本渤昌。這個(gè)配置方式和systemv 在系統(tǒng)進(jìn)入某個(gè)運(yùn)行級(jí)別的時(shí)候運(yùn)行init腳本的鏈接的概念實(shí)際上是非常類似的，只不過 upstart 更加靈活一些走搁。Upstart 不僅能在運(yùn)行級(jí)別改變的時(shí)候啟動(dòng)或終止服務(wù)独柑，也能在接收到系統(tǒng)發(fā)生其他改變的信息的時(shí)候啟動(dòng)或終止服務(wù)。這些系統(tǒng)的改變被稱為“事件”私植。例如忌栅，當(dāng) upstart 從 udev 接收到運(yùn)行時(shí)文件系統(tǒng)加載、打印機(jī)安裝或其他類似的設(shè)備添加或刪除的信息曲稼，并采取相應(yīng)的行動(dòng)索绪。Upstart 也可以在系統(tǒng)啟動(dòng)湖员、關(guān)閉或某個(gè)任務(wù)狀態(tài)改變的時(shí)候啟動(dòng)或關(guān)閉服務(wù)。

在upstart中存在如下幾個(gè)概念：

Process: process 是由jobs定義的services或者task者春，它將被init daemon 運(yùn)行破衔。每個(gè)job可以定義一個(gè)或者多個(gè)不同的process，分別在其生命周期的不同狀態(tài)運(yùn)行钱烟。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ā)一個(gè)事件拴袭。比如读第，引導(dǎo)程序會(huì)觸發(fā)啟動(dòng)（startup）事件，系統(tǒng)進(jìn)入運(yùn)行級(jí)別2會(huì) 觸發(fā)運(yùn)行級(jí)別2（runlevel 2）事件拥刻，而文件系統(tǒng)加載則會(huì)觸發(fā)路徑加載（path-mounted）事件怜瞒，拔掉或安裝一個(gè)熱插拔或USB設(shè)備（如打印機(jī)）也會(huì)觸發(fā)一個(gè)時(shí)間。用戶還可以通過 initctl emit 命令來手動(dòng)觸發(fā)一個(gè)事件般哼。事件定義格式如下：

start? on Event [[KEY=] Value … and| or …]?

stop? on Event [[KEY=] Value … and| or …]

Job：一個(gè)工作（job）是 init 可以理解的一系列指令吴汪。典型的指令包括一個(gè)程序（二進(jìn)制文件或是腳本）和事件的名稱。Upstart init daemon 會(huì)在事件觸發(fā)的時(shí)候運(yùn)行相應(yīng)的程序蒸眠。用戶可以分別用 initctl start 和 stop 命令手動(dòng)啟動(dòng)或終止一項(xiàng)工作漾橙。工作又可以分為任務(wù)和服務(wù)。

My? job 示例

用戶也可以自己定義一個(gè)事件楞卡，并讓一個(gè)工作被這個(gè)事件觸發(fā)霜运。如下的 myjob 工作定義文件定義了一個(gè)被 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 文件提供了另一種運(yùn)行命令的方法：在 script 和 end script 關(guān)鍵字之間包含了兩行命令。這兩個(gè)關(guān)鍵字常常導(dǎo)致 init 去運(yùn)行 /bin/sh蒋腮。例中的命令將一條消息和日期輸出到了 /tmp/myjob.out 文件√约瘢現(xiàn)在可以使用 initctl emit 命令觸發(fā)這個(gè)工作。如下池摧，init 展示了 myjobs 在我們的觸發(fā)下所經(jīng)歷的各個(gè)狀態(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）來運(yùn)行它膘魄。initctl start 十個(gè)非常有用的命令，這樣你就可以在沒有事件的情況下啟動(dòng)一個(gè)工作宦棺。比如，你可以用 initctl start mudat 來直接運(yùn)行前面例子中的 mudat 工作而不會(huì)觸發(fā) runlevel 2 事件黔帕。

Upstart 事件監(jiān)控實(shí)現(xiàn)

在init daemon 中需要監(jiān)測(cè)某個(gè)進(jìn)程的狀態(tài)代咸，例如存在repasw機(jī)制，監(jiān)測(cè)getty進(jìn)程是否退出成黄，如果退出則需要再次啟動(dòng)getty以便用戶登錄呐芥。為實(shí)現(xiàn)對(duì)事件的監(jiān)測(cè)逻杖，要么采用輪詢要么采用事件驅(qū)動(dòng)的回調(diào)機(jī)制，upstart采用事件驅(qū)動(dòng)機(jī)制思瘟。為實(shí)現(xiàn)基于事件驅(qū)動(dòng)的機(jī)制荸百，通常涉及跨進(jìn)程調(diào)用，Upstart利用dbus來完成iPC通信滨攻。但upstart init daemon啟動(dòng)時(shí)dbus-daemon并沒有運(yùn)行够话，實(shí)際dbus-daemon是由upstart來啟動(dòng)。因此光绕，upstart 采用? private D-bus 連接（unxi:address=/com/ubuntu/upstart）來實(shí)現(xiàn)IPC女嘲；其它進(jìn)程（如telinit等）通過該連接來通知init daemon 產(chǎn)生某個(gè)事件。

Upstart init daemon 運(yùn)行時(shí)會(huì)產(chǎn)生startup事件诞帐，在/etc/init下很多job都start on 該事件欣尼，其中比較著名的是：

rc-default job . 該job會(huì)調(diào)用telinit N來登錄N用戶級(jí)別，同時(shí)產(chǎn)生runevel事件停蕉。而runevel事件觸發(fā)ttyN job愕鼓，從而調(diào)用getty程序。對(duì)于圖形界面的登錄程序如gdm的觸發(fā)為另外的條件慧起，后面再續(xù)菇晃。

為完成監(jiān)控內(nèi)核事件，例如usb的熱插拔完慧，upstart提供upstart-udev-bridge.conf job來完成該功能,即在/etc/init 下存在upstart-udev-bridge.conf 文件谋旦。當(dāng)udev event發(fā)生時(shí)，該job將產(chǎn)生 upstart事件通知init屈尼。這類事件通常采用如下格式：

“-device-

因此upstart-udev-bridge.conf 可能為：

net-device-added net-device-removed graphics-device-added drm-device-added

用戶自動(dòng)登錄和定制XWindows

在工作中册着，常常存在如下需求：

開機(jī)運(yùn)行l(wèi)inux，自動(dòng)登錄甲捏，無需輸入用戶名密碼；

登錄后自動(dòng)運(yùn)行我們的GUI軟件鞭执，且無需ubuntu等桌面環(huán)境

在使用upstart的ubuntu系統(tǒng)中，控制登錄的腳本主要是：

/etc/init/ttyN.conf

/etc/init/gdm.conf

Gdm.conf用戶啟動(dòng)gdm厌衔，即ubuntu的圖形桌面理疙；由于我們并不需要桌面豌熄，因此首先刪除gdm.conf. 刪除gdm.conf將不能啟動(dòng)linux GUI桌面锻拘，但由于我們開機(jī)運(yùn)行的GUI軟件本質(zhì)還是一個(gè)X11 Client程序谴咸，因此需要啟動(dòng)X Server。這時(shí)可以startx 腳本就派生用場(chǎng)了，在傳統(tǒng)的用戶text模式下仅财，大都通過startx進(jìn)入GUI系統(tǒng)。因此我們可以配置.xinitrc 腳本：例如如下:

// user gui programmer

Metacity

為保證用戶登錄后即運(yùn)行startx潭兽，可以在~/.bash_profile 中寫入：

exec startx

上述過程保證了用戶登錄后即運(yùn)行startx 啟動(dòng)了用戶程序倦始，但如何實(shí)現(xiàn)用戶自動(dòng)登錄呢？這需要修改/etc/init/ttyN.conf 山卦，默認(rèn)使用getty程序登錄鞋邑，該程序不支持用戶自動(dòng)登錄诵次。Linux下有一個(gè)叫minigetty 程序支持該功能，下載并修改/etc/init/ttyN.conf 文件枚碗，大致如下：

Exec /sbin/mingetty –autologin root tty1

其它init 實(shí)現(xiàn)

Systemd是一個(gè)比upstart設(shè)計(jì)思路更超前的init系統(tǒng)逾一，見http://0pointer.de/blog/projects/systemd.html。?? 其核心是為了加快linux的啟動(dòng)速度肮雨，研究如何并行化啟動(dòng)init以后的用戶進(jìn)程遵堵，可以參考http://linuxtoy.org/archives/more-than-upstart-systemd.html

//SysVinit（https://blog.csdn.net/weixin_34040079/article/details/92395376?這個(gè)link也不錯(cuò)）

剛開始網(wǎng)上查/etc/rc.local能實(shí)現(xiàn)開機(jī)自動(dòng)運(yùn)行腳本..但是不知道為啥..

后來偶然在rc?.d/README發(fā)現(xiàn)了玄機(jī)...再后來一直順著README的方向看下去...終于明白了

Ubuntu 的運(yùn)行級(jí)別

0 系統(tǒng)停機(jī)

1 單用戶或系統(tǒng)維護(hù)狀態(tài)

2~5 多用戶

6 重新啟動(dòng)

我們通常運(yùn)行的2~5級(jí)別

/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.

這個(gè)目錄的腳本在系統(tǒng)進(jìn)入這個(gè)運(yùn)行級(jí)別的時(shí)候就被啟動(dòng).

這些腳本全是目標(biāo)位于/etc/init.d/的符號(hào)鏈接

S??XXX, S代表啟動(dòng),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 會(huì)啟動(dòng) /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版本在這里的文件描述了這個(gè)文件夾的腳本怎樣工作 --- (額，這句貌似在說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目錄包含著當(dāng)運(yùn)行級(jí)別改變時(shí)在boot時(shí)啟動(dòng)的腳本(不是重點(diǎn))

有兩點(diǎn)不同...一堆廢話夾中間...出于易讀考慮,這篇文檔只描述符號(hào)鏈接方法.xxx xxx...

不同運(yùn)行級(jí)別的自動(dòng)化操作必須用update-rc.d來安裝或者刪除符號(hào)鏈接.

然后...K代表停止,S代表執(zhí)行,數(shù)字代表順序(前面已說過)

寫腳本

包含系統(tǒng)服務(wù)daemon(后臺(tái)程序)的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).

默認(rèn)update-rc.d會(huì)在多人運(yùn)行級(jí)別(2,3,4,5)和在停止級(jí)別(halt level(0)),單人級(jí)別(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代表強(qiáng)制(如果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實(shí)現(xiàn)開機(jī)啟動(dòng)腳本原理================================================