第一節 init & sysvinit 6
I sysvinit 運行順序... 6
II Sysvinit和系統關閉... 7
III Sysvinit 的小結... 7
IV 運行級別... 7
V /etc/inittab文件... 8
第二節 systemd. 9
I 系統管理... 10
II Unit 10
III Target 14
IV 日志管理 15
第一章 Linux守護進程（daemon）
https://www.ibm.com/developerworks/cn/linux/1407_liuming_init1/
https://www.ibm.com/developerworks/cn/linux/1407_liuming_init3/
第一節 init & sysvinit
Linux 操作系統的啟動首先從 BIOS 開始，接下來進入 boot loader，由 bootloader 載入內核，進行內核初始化。內核初始化的最后一步就是啟動 pid 為 1 的 init 進程。這個進程是系統的第一個進程。它負責產生其他所有用戶進程。
init 以守護進程方式存在，是所有其他進程的祖先。init 進程非常獨特，能夠完成其他進程無法完成的任務。
Init 系統能夠定義、管理和控制 init 進程的行為。它負責組織和運行許多獨立的或相關的始化工作(因此被稱為 init 系統)，從而讓計算機系統進入某種用戶預訂的運行模式。
僅僅將內核運行起來是毫無實際用途的，必須由 init 系統將系統代入可操作狀態。比如啟動外殼 shell 后，便有了人機交互，這樣就可以讓計算機執行一些預訂程序完成有實際意義的任務。或者啟動 X 圖形系統以便提供更佳的人機界面，更加高效的完成任務。這里，字符界面的 shell 或者 X 系統都是一種預設的運行模式。
大多數 Linux 發行版的 init 系統是和 System V 相兼容的，被稱為 sysvinit。這是人們最熟悉的 init 系統。
sysvinit 就是 system V 風格的 init 系統，顧名思義，它源於 System V 系列 UNIX。它提供了比 BSD 風格 init 系統更高的靈活性。是已經風行了幾十年的 UNIX init 系統，一直被各類 Linux 發行版所采用。
Sysvinit 用術語 runlevel（運行級別） 來定義"預訂的運行模式"。Sysvinit 檢查 '/etc/inittab' 文件中是否含有 'initdefault' 項。 這告訴 init 系統是否有一個默認運行模式。如果沒有默認的運行模式，那么用戶將進入系統控制台，手動決定進入何種運行模式。
sysvinit 中運行模式描述了系統各種預訂的運行模式。通常會有 8 種運行模式，即運行模式 0 到 6 和 S 或者 s。
每種 Linux 發行版對運行模式的定義都不太一樣。但 0，1，6 卻得到了大家的一致贊同：
0 關機
1 單用戶模式
6 重啟
通常在 /etc/inittab 文件中定義了各種運行模式的工作范圍。比如 RedHat 定義了 runlevel 3 和 5。運行模式 3 將系統初始化為字符界面的 shell 模式；運行模式 5 將系統初始化為 GUI 模式。無論是命令行界面還是 GUI，運行模式 3 和 5 相對於其他運行模式而言都是完整的正式的運行狀態，計算機可以完成用戶需要的任務。而模式 1，S 等往往用於系統故障之后的排錯和恢復。
很顯然，這些不同的運行模式下系統需要初始化運行的進程和需要進行的初始化准備都是不同的。比如運行模式 3 不需要啟動 X 系統。用戶只需要指定需要進入哪種模式，sysvinit 將負責執行所有該模式所必須的初始化工作。
I sysvinit 運行順序
Sysvinit 巧妙地用腳本，文件命名規則和軟鏈接來實現不同的 runlevel。首先，sysvinit 需要讀取/etc/inittab 文件。分析這個文件的內容，它獲得以下一些配置信息：
· 系統需要進入的 runlevel
· 捕獲組合鍵的定義
· 定義電源 fail/restore 腳本
· 啟動 getty 和虛擬控制台
得到配置信息后，sysvinit 順序地執行以下這些步驟，從而將系統初始化為預訂的 runlevel X。
· /etc/rc.d/rc.sysinit
· /etc/rc.d/rc 和/etc/rc.d/rcX.d/ (X 代表運行級別 0-6)
· /etc/rc.d/rc.local
· X Display Manager（如果需要的話）
rc.local 是 Linux 留給用戶進行個性化設置的地方。您可以把自己私人想設置和啟動的東西放到這里，一台 Linux Server 的用戶一般不止一個，所以才有這樣的考慮。
II Sysvinit和系統關閉
Sysvinit 不僅需要負責初始化系統，還需要負責關閉系統。在系統關閉時，為了保證數據的一致性，需要小心地按順序進行結束和清理工作。
比如應該先停止對文件系統有讀寫操作的服務，然后再 umount 文件系統。否則數據就會丟失。
這種順序的控制這也是依靠/etc/rc.d/rcX.d/目錄下所有腳本的命名規則來控制的，在該目錄下所有以 K 開頭的腳本都將在關閉系統時調用，字母 K 之后的數字定義了它們的執行順序。
這些腳本負責安全地停止服務或者其他的關閉工作。
l K開頭的代表系統關閉的時候執行，執行K腳本的時候會查詢/var/lock/subsys/下是否有與K開頭腳本同名的空文件名，如果沒有就不去執行。
l S開頭的代表開機的時候執行，啟動的時候要在/var/lock/subsys/先touch一個與K01后面同名的空文件.同時也要調用/etc/rc.d/init.d/functions能夠接受star與stop命令信號。
III Sysvinit 的小結
Sysvinit 的優點是概念簡單。Service 開發人員只需要編寫啟動和停止腳本，概念非常清楚；將 service 添加/刪除到某個 runlevel 時，只需要執行一些創建/刪除軟連接文件的基本操作；這些都不需要學習額外的知識或特殊的定義語法(UpStart 和 Systemd 都需要用戶學習新的定義系統初始化行為的語言)。
其次，sysvinit 的另一個重要優點是確定的執行順序：腳本嚴格按照啟動數字的大小順序執行，一個執行完畢再執行下一個，這非常有益於錯誤排查。UpStart 和 systemd 支持並發啟動，導致沒有人可以確定地了解具體的啟動順序，排錯不易。
但是串行地執行腳本導致 sysvinit 運行效率較慢，在新的 IT 環境下，啟動快慢成為一個重要問題。此外動態設備加載等 Linux 新特性也暴露出 sysvinit 設計的一些問題。
IV 運行級別
修改/etc/inittab文件中內容 id:3:initdefault
用 init -x切換級別，如想進入圖形界面則輸入 init -5即可切換；
0 所有進程將被終止，機器將有序的停止，關機時系統處於這個運行級別。
1 單用戶模式：用於系統維護，只有少數進程運行，同時所有服務也不啟動。
2 多用戶模式：和運行級別3一樣，只是網絡文件系統（NFS）服務沒被啟動。
3 多用戶模式：允許多用戶登錄系統，是系統默認的啟動級別。
4 留給用戶自定義的運行級別。
5 多用戶模式：並且在系統啟動后運行X-Window，給出一個圖形化的登錄窗口。
6 所有進程被終止，系統重新啟動。
init -5與startx區別：
啟動時/Gnome注銷后：在Gnome登錄窗口。Startx進入桌面，注銷后回到CUI
ll -h /lib/systemd/system/*.target
ll -h /etc/systemd/system/*.target
V /etc/inittab文件
systemd不再使用運行級別，而使用運行目標。所以/etc/inittab文件不再使用。
/usr/lib/systemd/system/*.target
系統有7種：但CentOS 初始化不再使用級別，而是對像。
0關機 1單用戶 2命令多用戶但少NFS
3多用戶命令 5多用戶圖形
6重啟 4預留自定義
/etc/rc* & /etc/init*
CentOS 7.4 中：（#與初始化運行級別對應）
將/etc/init.d鏈接到/etc/rc.d/init.d目錄下，將/etc/rc#.d鏈接到/etc/rc.d/rc#.d/目錄下。
而/etc/rc.d/rc#.d/下的二個文件鏈接到/etc/rc.d/init.目錄下。【K50netconsole -> ../init.d/netconsole K90network -> ../init.d/network】
第二節 systemd
http://www.ruanyifeng.com/blog/2016/03/systemd-tutorial-commands.html
歷史上，Linux 的啟動一直采用init進程。
$ sudo /etc/init.d/apache2 start
# 或者
$ service apache2 start
這種方法有兩個缺點：
一是啟動時間長。init進程是串行啟動，只有前一個進程啟動完，才會啟動下一個進程。
二是啟動腳本復雜。init進程只是執行啟動腳本，不管其他事情。腳本需要自己處理各種情況，這往往使得腳本變得很長。
Systemd 就是為了解決這些問題而誕生的。它的設計目標是，為系統的啟動和管理提供一套完整的解決方案。
根據 Linux 慣例，字母d是守護進程（daemon）的縮寫。 Systemd 這個名字的含義，就是它要守護整個系統。
使用了 Systemd，就不需要再用init了。Systemd 取代了initd，成為系統的第一個進程（PID=1），其他進程都是它的子進程。
Systemd 的優點是功能強大，使用方便，缺點是體系龐大，非常復雜。事實上，現在還有很多人反對使用 Systemd，理由就是它過於復雜，與操作系統的其他部分強耦合，違反"keep simple, keep stupid"的Unix 哲學。
Picture 1 Systemd架構
I 系統管理
s systemctl是 Systemd 的主命令，用於管理系統。
# 啟動進入救援狀態（單用戶狀態）
$ sudo systemctl rescue
s systemd-analyze命令用於查看啟動耗時。
# 查看啟動耗時
$ systemd-analyz
# 顯示瀑布狀的啟動過程流
$ systemd-analyze critical-chain
s hostnamectl命令用於查看當前主機的信息。
s localectl命令用於查看本地化設置。
s timedatectl命令用於查看當前時區設置。
s loginctl命令用於查看當前登錄的用戶。
II Unit
Systemd 可以管理所有系統資源。不同的資源統稱為 Unit（單位）。
Unit 一共分成12種。
1) Service unit：系統服務
2) Target unit：多個 Unit 構成的一個組
3) Device Unit：硬件設備
4) Mount Unit：文件系統的掛載點
5) Automount Unit：自動掛載點
6) Path Unit：文件或路徑
7) Scope Unit：不是由 Systemd 啟動的外部進程
8) Slice Unit：進程組
9) Snapshot Unit：Systemd 快照，可以切回某個快照
10) Socket Unit：進程間通信的 socket
11) Swap Unit：swap 文件
12) Timer Unit：定時器
systemctl list-units命令可以查看當前系統的所有 Unit 。
systemctl status命令用於查看系統狀態和單個 Unit 的狀態。
Unit 管理
對於用戶來說，最常用的是下面這些命令，用於啟動和停止 Unit（主要是 service）。
# 立即啟動一個服務
$ sudo systemctl start apache.service
# 立即停止一個服務
$ sudo systemctl stop apache.service
# 重啟一個服務
$ sudo systemctl restart apache.service
# 殺死一個服務的所有子進程
$ sudo systemctl kill apache.service
# 重新加載一個服務的配置文件
$ sudo systemctl reload apache.service
# 重載所有修改過的配置文件
$ sudo systemctl daemon-reload
# 顯示某個 Unit 的所有底層參數
$ systemctl show httpd.service
# 顯示某個 Unit 的指定屬性的值
$ systemctl show -p CPUShares httpd.service
# 設置某個 Unit 的指定屬性
$ sudo systemctl set-property httpd.service CPUShares=500
依賴關系
Unit 之間存在依賴關系：A 依賴於 B，就意味着 Systemd 在啟動 A 的時候，同時會去啟動 B。
systemctl list-dependencies命令列出一個 Unit 的所有依賴。
$ systemctl list-dependencies nginx.service
上面命令的輸出結果之中，有些依賴是 Target 類型（詳見下文），默認不會展開顯示。如果要展開 Target，就需要使用--all參數。
$ systemctl list-dependencies --all nginx.service
Unit 的配置文件
注意發行版本的差異：文件目錄
每一個 Unit 都有一個配置文件，告訴 Systemd 怎么啟動這個 Unit 。
Systemd 默認從目錄/etc/systemd/system/讀取配置文件。但是，里面存放的大部分文件都是符號鏈接，指向目錄/usr/lib/systemd/system/，真正的配置文件存放在那個目錄。
systemctl enable命令用於在上面兩個目錄之間，建立符號鏈接關系。
$ sudo systemctl enable clamd@scan.service
# 等同於
$ sudo ln -s '/usr/lib/systemd/system/clamd@scan.service' '/etc/systemd/system/multi-user.target.wants/clamd@scan.service'
如果配置文件里面設置了開機啟動，systemctl enable命令相當於激活開機啟動。
與之對應的，systemctl disable命令用於在兩個目錄之間，撤銷符號鏈接關系，相當於撤銷開機啟動。
$ sudo systemctl disable clamd@scan.service
配置文件的后綴名，就是該 Unit 的種類，比如sshd.socket。如果省略，Systemd 默認后綴名為.service，所以sshd會被理解成sshd.service。
配置文件的狀態
systemctl list-unit-files命令用於列出所有配置文件。
# 列出所有配置文件
$ systemctl list-unit-files
# 列出指定類型的配置文件
$ systemctl list-unit-files --type=service
這個命令會輸出一個列表。
$ systemctl list-unit-files
UNIT FILE STATE
chronyd.service enabled
clamd@.service static
clamd@scan.service disabled
這個列表顯示每個配置文件的狀態，一共有四種。
s enabled：已建立啟動鏈接
s disabled：沒建立啟動鏈接
s static：該配置文件沒有[Install]部分（無法執行），只能作為其他配置文件的依賴
s masked：該配置文件被禁止建立啟動鏈接
注意，從配置文件的狀態無法看出，該 Unit 是否正在運行。這必須執行前面提到的systemctl status命令。
$ systemctl status bluetooth.service
一旦修改配置文件，就要讓 SystemD 重新加載配置文件，然后重新啟動，否則修改不會生效。
$ sudo systemctl daemon-reload
$ sudo systemctl restart httpd.service
配置文件的格式
配置文件就是普通的文本文件，可以用文本編輯器打開。
$ systemctl cat sshd.service
$ cat /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.service
Wants=sshd-keygen.service
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target
從上面的輸出可以看到，配置文件分成幾個區塊。每個區塊的第一行，是用方括號表示的區別名，比如[Unit]。注意，配置文件的區塊名和字段名，都是大小寫敏感的。
每個區塊內部是一些等號連接的鍵值對。
[Section]
Directive1=value
Directive2=value
注意，鍵值對的等號兩側不能有空格。
[Unit]區塊
[Unit]區塊通常是配置文件的第一個區塊，用來定義 Unit 的元數據，以及配置與其他 Unit 的關系。它的主要字段如下。
s Description：簡短描述
s Documentation：文檔地址
s Requires：當前 Unit 依賴的其他 Unit，如果它們沒有運行，當前 Unit 會啟動失敗
s Wants：與當前 Unit 配合的其他 Unit，如果它們沒有運行，當前 Unit 不會啟動失敗
s BindsTo：與Requires類似，它指定的 Unit 如果退出，會導致當前 Unit 停止運行
s Before：如果該字段指定的 Unit 也要啟動，那么必須在當前 Unit 之后啟動
s After：如果該字段指定的 Unit 也要啟動，那么必須在當前 Unit 之前啟動
s Conflicts：這里指定的 Unit 不能與當前 Unit 同時運行
s Condition...：當前 Unit 運行必須滿足的條件，否則不會運行
s Assert...：當前 Unit 運行必須滿足的條件，否則會報啟動失敗
[Install]區塊
[Install]通常是配置文件的最后一個區塊，用來定義如何啟動，以及是否開機啟動。它的主要字段如下。
s WantedBy：它的值是一個或多個 Target，當前 Unit 激活時（enable）符號鏈接會放入/etc/systemd/system目錄下面以 Target 名 + .wants后綴構成的子目錄中
s RequiredBy：它的值是一個或多個 Target，當前 Unit 激活時，符號鏈接會放入/etc/systemd/system目錄下面以 Target 名 + .required后綴構成的子目錄中
s Alias：當前 Unit 可用於啟動的別名
s Also：當前 Unit 激活（enable）時，會被同時激活的其他 Unit
[Service]區塊
[Service]區塊用來 Service 的配置，只有 Service 類型的 Unit 才有這個區塊。它的主要字段如下。
s Type：定義啟動時的進程行為。它有以下幾種值。
Type=simple：默認值，執行ExecStart指定的命令，啟動主進程
Type=forking：以 fork 方式從父進程創建子進程，創建后父進程會立即退出
Type=oneshot：一次性進程，Systemd 會等當前服務退出，再繼續往下執行
Type=dbus：當前服務通過D-Bus啟動
Type=notify：當前服務啟動完畢，會通知Systemd，再繼續往下執行
Type=idle：若有其他任務執行完畢，當前服務才會運行
s ExecStart：啟動當前服務的命令
s ExecStartPre：啟動當前服務之前執行的命令
s ExecStartPost：啟動當前服務之后執行的命令
s ExecReload：重啟當前服務時執行的命令
s ExecStop：停止當前服務時執行的命令
s ExecStopPost：停止當其服務之后執行的命令
s RestartSec：自動重啟當前服務間隔的秒數
s Restart：定義何種情況 Systemd 會自動重啟當前服務，可能的值包括always（總是重啟）、on-success、on-failure、on-abnormal、on-abort、on-watchdog
s TimeoutSec：定義 Systemd 停止當前服務之前等待的秒數
s Environment：指定環境變量
Unit 配置文件的完整字段清單，請參考官方翻譯文檔。
III Target
啟動計算機的時候，需要啟動大量的 Unit。如果每一次啟動，都要一一寫明本次啟動需要哪些 Unit，顯然非常不方便。Systemd 的解決方案就是 Target（對像）。
簡單說，Target 就是一個 Unit 組，包含許多相關的 Unit 。啟動某個 Target 的時候，Systemd 就會啟動里面所有的 Unit。從這個意義上說，Target 這個概念類似於"狀態點"，啟動某個 Target 就好比啟動到某種狀態。
傳統的init啟動模式里面，有 RunLevel 的概念，跟 Target 的作用很類似。不同的是，RunLevel 是互斥的，不可能多個 RunLevel 同時啟動，但是多個 Target 可以同時啟動。
# 查看當前系統的所有 Target
$ systemctl list-unit-files --type=target
# 查看一個 Target 包含的所有 Unit
$ systemctl list-dependencies multi-user.target
# 查看啟動時的默認 Target
$ systemctl get-default
# 設置啟動時的默認 Target
$ sudo systemctl set-default multi-user.target
# 切換 Target 時，默認不關閉前一個 Target 啟動的進程，
# systemctl isolate 命令改變這種行為，
# 關閉前一個 Target 里面所有不屬於后一個 Target 的進程
$ sudo systemctl isolate multi-user.target
Target 與 傳統 RunLevel 的對應關系如下。
Traditional runlevel New target name Symbolically linked to...
Runlevel 0 | runlevel0.target -> poweroff.target
Runlevel 1 | runlevel1.target -> rescue.target
Runlevel 2 | runlevel2.target -> multi-user.target
Runlevel 3 | runlevel3.target -> multi-user.target
Runlevel 4 | runlevel4.target -> multi-user.target
Runlevel 5 | runlevel5.target -> graphical.target
Runlevel 6 | runlevel6.target -> reboot.target
它與init進程的主要差別如下：
（1）默認的 RunLevel（在/etc/inittab文件設置）現在被默認的 Target 取代，位置是/etc/systemd/system/default.target，通常符號鏈接到graphical.target（圖形界面）或者multi-user.target（多用戶命令行）。
（2）啟動腳本的位置，以前是/etc/init.d目錄，符號鏈接到不同的 RunLevel 目錄 （比如/etc/rc3.d、/etc/rc5.d等），現在則存放在/lib/systemd/system和/etc/systemd/system目錄（systemd兼容init.d）。
（3）配置文件的位置，以前init進程的配置文件是/etc/inittab，各種服務的配置文件存放在/etc/sysconfig目錄。現在的配置文件主要存放在/lib/systemd目錄，在/etc/systemd目錄里面的修改可以覆蓋原始設置。
IV 日志管理
Systemd 統一管理所有 Unit 的啟動日志。帶來的好處就是，可以只用journalctl一個命令，查看所有日志（內核日志和應用日志）。日志的配置文件是/etc/systemd/journald.conf。
journalctl功能強大，用法非常多。
# 查看所有日志（默認情況下 ，只保存本次啟動的日志）
$ sudo journalctl
# 查看內核日志（不顯示應用日志）
$ sudo journalctl -k
# 查看系統本次啟動的日志
$ sudo journalctl -b
$ sudo journalctl -b -0
# 查看上一次啟動的日志（需更改設置）
$ sudo journalctl -b -1
# 查看指定時間的日志
$ sudo journalctl --since="2012-10-30 18:17:16"
$ sudo journalctl --since "20 min ago"
$ sudo journalctl --since yesterday
$ sudo journalctl --since "2015-01-10" --until "2015-01-11 03:00"
$ sudo journalctl --since 09:00 --until "1 hour ago"
# 顯示尾部的最新10行日志
$ sudo journalctl -n
# 顯示尾部指定行數的日志
$ sudo journalctl -n 20
# 實時滾動顯示最新日志
$ sudo journalctl -f
# 查看指定服務的日志
$ sudo journalctl /usr/lib/systemd/systemd
# 查看指定進程的日志
$ sudo journalctl _PID=1
# 查看某個路徑的腳本的日志
$ sudo journalctl /usr/bin/bash
# 查看指定用戶的日志
$ sudo journalctl _UID=33 --since today
# 查看某個 Unit 的日志
$ sudo journalctl -u nginx.service
$ sudo journalctl -u nginx.service --since today
# 實時滾動顯示某個 Unit 的最新日志
$ sudo journalctl -u nginx.service -f
# 合並顯示多個 Unit 的日志
$ journalctl -u nginx.service -u php-fpm.service --since today
# 查看指定優先級（及其以上級別）的日志，共有8級
# 0: emerg
# 1: alert
# 2: crit
# 3: err
# 4: warning
# 5: notice
# 6: info
# 7: debug
$ sudo journalctl -p err -b
# 日志默認分頁輸出，--no-pager 改為正常的標准輸出
$ sudo journalctl --no-pager
# 以 JSON 格式（單行）輸出
$ sudo journalctl -b -u nginx.service -o json
# 以 JSON 格式（多行）輸出，可讀性更好
$ sudo journalctl -b -u nginx.serviceqq -o json-pretty
# 顯示日志占據的硬盤空間
$ sudo journalctl --disk-usage
# 指定日志文件占據的最大空間
$ sudo journalctl --vacuum-size=1G
# 指定日志文件保存多久
$ sudo journalctl --vacuum-time=1years