Systemd

Centos 7中的systemd：
  概述：
  CentOS 6和以前版本採用SysV init的系統啓動進程管理體系，通常用戶均可經過在/etc/inittab文件的配置，來個性化本身的系統啓動序列。但也常常會因爲特殊環境的硬件等關係問題，形成其串行的啓動進程控制流，由於可能任務的阻塞而影響啓動過程。
  CentOS 7開始使用SystemD，因此咱們必需要了解SystemD。本章將從CentOS 7的啓動流程、Unit、服務管理，啓動排錯，破解口令以及修復grub2等方面來介紹Systemd的相關內容。

  系統啓動流程
　　POST—> Boot Sequence—> Bootloader—> kernel + initramfs(initrd)—> rootfs(根切換)—> /sbin/init
  init程序：
　　CentOS 5: SysV init
　　CentOS 6: Upstart
　　CentOS 7: Systemd

  Systemd：系統啓動和服務器守護進程管理器，負責在系統啓動或運行時激活系統資源、服務器進程和其它進程

  Systemd新特性
　系統引導時實現服務並行啓動：
　　爲了加速整個系統啓動和並行啓動更多的進程，systemd 在實際啓動守護進程以前建立監聽socket，而後傳遞 socket 給守護進程。在系統初始化時，首先爲全部守護進程建立 socket ，而後再啓動全部的守護進程。若是一個服務由於須要另外一個服務的支持而沒有徹底啓動，而這個鏈接可能正在提供服務的隊列中排隊，那麼這個客戶端進程在此次請求中就處於阻塞狀態。不過只會有這一個客戶端進程會被阻塞，並且僅是在這一次請求中被阻塞。服務間的依賴關係也再也不須要經過配置來實現真正的並行啓動(由於一次開啓了全部的 socket ，若是一個服務須要其餘的服務，它顯然能夠鏈接到相應的 socket)

  按需啓動守護進程：
　　只有在某個服務被真正請求的時候才啓動它。當該服務結束，systemd 能夠關閉它，等待下次須要時再次啓動它。

　自動化的服務依賴關係管理：
　　systemd 支持服務(或 unit)間的多種依賴關係。在 unit 配置文件中使用 After/Before、Requires 和 Wants 選項能夠固定 unit 激活的順序。Requires 和 Wants 表示一個正向(強制或可選)的需求和依賴關係，Conflicts 表示一個負向的需求和依賴關係。其餘選項較少用到。若是一個 unit 須要啓動或關閉，systemd 就把它和它的依賴關係添加到臨時執行列表，而後確認它們的相互關係是否一致(或全部unit 的前後順序是否含有循環)。若是答案是否的話，systemd 將嘗試修復它，刪除能夠消除循環的無用工做。

　D-Bus 激活策略啓動服務：
　　經過使用總線激活策略，服務能夠在接入時立刻啓動。同時，總線激活策略使得系統能夠用微小的消耗實現 D-Bus 服務的提供者與消費者的同步開啓請求。(同時開啓多個服務，若是一個比總線激活策略中其餘服務快就在 D-Bus 中排隊其請求，直到其餘管理肯定本身的服務信息爲止)

　支持快照和系統狀態恢復：
　　快照能夠用來保存/恢復系統初始化時全部的服務和 unit 的狀態。它有兩種主要的使用狀況：容許用戶暫時進入一個像 "Emergency Shell" 的特殊狀態，終止當前的服務；提供一個回到先前狀態的簡單方法，從新啓動先前暫時終止的服務
　　systemd 支持按需啓動，所以系統的運行狀態是動態變化的，人們沒法準確地知道系統當前運行了哪些服務。Systemd 快照提供了一種將當前系統運行狀態保存並恢復的能力。
　　好比系統當前正運行服務 A 和 B，能夠用 systemd 命令行對當前系統運行情況建立快照。而後將進程 A 中止，或者作其餘的任意的對系統的改變，好比啓動新的進程 C。在這些改變以後，運行 systemd 的快照恢復命令，就可當即將系統恢復到快照時刻的狀態，即只有服務 A，B 在運行。一個可能的應用場景是調試：好比服務器出現一些異常，爲了調試用戶將當前狀態保存爲快照，而後能夠進行任意的操做，好比中止服務等等。等調試結束，恢復快照便可。
　　這個快照功能目前在 systemd 中並不完善，彷佛開發人員也沒有特別關注它，所以有報告指出它還存在一些使用上的問題，使用時尚需慎重。

  維護掛載和自掛載點：
　　systemd 監視全部的掛載點的進出狀況，也能夠用來掛載或卸載掛載點。/etc/fstab 也能夠做爲這些掛載點的一個附加配置源。經過使用 comment= fstab 選項能夠標記 /etc/fstab 條目使其成爲由 systemd 控制的自掛載點。
　　傳統的 Linux 系統中，用戶能夠用/etc/fstab 文件來維護固定的文件系統掛載點。這些掛載點在系統啓動過程當中被自動掛載，一旦啓動過程結束，這些掛載點就會確保存在。這些掛載點都是對系統運行相當重要的文件系統，好比 HOME 目錄。和 sysvinit 同樣，Systemd 管理這些掛載點，以便可以在系統啓動時自動掛載它們。Systemd 還兼容/etc/fstab 文件，您能夠繼續使用該文件管理掛載點。
　　有時候用戶還須要動態掛載點，好比打算訪問 DVD 內容時，才臨時執行掛載以便訪問其中的內容，而不訪問光盤時該掛載點被取消(umount)，以便節約資源。傳統地，人們依賴 autofs 服務來實現這種功能。Systemd 內建了自動掛載服務，無需另外安裝 autofs 服務，能夠直接使用 systemd 提供的自動掛載管理能力來實現 autofs 的功能

  採用 Linux的Cgroup特性跟蹤和管理進程的生命週期：
　　systemd 則利用了 Linux 內核的特性即 CGroup 來完成跟蹤的任務。當中止服務時，經過查詢 CGroup，systemd 能夠確保找到全部的相關進程，從而乾淨地中止服務。
　　CGroup 已經出現了好久，它主要用來實現系統資源配額管理。CGroup 提供了相似文件系統的接口，使用方便。當進程建立子進程時，子進程會繼承父進程的 CGroup。所以不管服務如何啓動新的子進程，全部的這些相關進程都會屬於同一個 CGroup，systemd 只須要簡單地遍歷指定的 CGroup 便可正確地找到全部的相關進程，將它們一一中止便可。

  日誌服務
　　systemd 自帶日誌服務 journald，該日誌服務的設計初衷是克服現有的 syslog 服務的缺點。好比：
　　syslog 不安全，消息的內容沒法驗證。每個本地進程均可以聲稱本身是 Apache PID 4711，而 syslog 也就相信並保存到磁盤上。
數據沒有嚴格的格式，很是隨意。自動化的日誌分析器須要分析人類語言字符串來識別消息。一方面此類分析困難低效；此外日誌格式的變化會致使分析代碼須要更新甚至重寫。
　　Systemd Journal 用二進制格式保存全部日誌信息，用戶使用 journalctl 命令來查看日誌信息。無需本身編寫複雜脆弱的字符串分析處理程序。
　　Systemd Journal 的優勢以下：
    簡單性：代碼少，依賴少，抽象開銷最小。
    零維護：日誌是除錯和監控系統的核心功能，所以它本身不能再產生問題。舉例說，自動管理磁盤空間，避免因爲日誌的不斷產生而將磁盤空間耗盡。
    移植性：日誌文件應該在全部類型的 Linux 系統上可用，不管它使用的何種 CPU 或者字節序。
    性能：添加和瀏覽日誌很是快。
    最小資源佔用：日誌數據文件須要較小。
    統一化：各類不一樣的日誌存儲技術應該統一塊兒來，將全部的可記錄事件保存在同一個數據存儲中。因此日誌內容的全局上下文都會被保存而且可供往後查詢。例如一條固件記錄後一般會跟隨一條內核記錄，最終還會有一條用戶態記錄。重要的是當保存到硬盤上時這三者之間的關係不會丟失。Syslog 將不一樣的信息保存到不一樣的文件中，分析的時候很難肯定哪些條目是相關的。
    擴展性：日誌的適用範圍很廣，從嵌入式設備到超級計算機集羣均可以知足需求。
    安全性：日誌文件是能夠驗證的，讓沒法檢測的修改再也不可能。

systemd關鍵特性：
  基於套接字(socket-based)的觸發激活：
　　與服務相關的套接字，從守護進程中剝離出來，目的是爲了更好的分開來進行處理。這麼作有不少好處：好比咱們能夠對服務延遲啓動，直到其相關的套接字可用爲止。好比這麼作能夠容許系統在服務啓動過程以前先建立好套接字，從而使得可以並行啓動該服務的相關服務。
　　systemd爲支持此機制的服務監聽socket，當有客戶端與socket通訊時，由systemd激活服務，應答客戶端的請求；這種機制相似於守護進程

　　基於總線(bus-based)的觸發激活：
　　unit也能夠被D-Bus提供的總線接口激活。當一個與某個單元相關的總線被髮布的時候，該單元即可以開始工做

  基於device的觸發激活機制：
　　當有設備接入時，systemd會自動激活device、mount、automount等unit來識別，掛載接入的設備

  基於path的觸發激活機制：
　　一個unit能夠依據某個肯定的文件系統路徑的活動狀態以及可用性而開始工做。至關於集成了Linux的inotify功能
　　當某個文件路徑變得可用時或路徑出現相應文件時，激活對應服務

兼容性：
  向後兼容sysvinit腳本：
  　兼容CentOS 5的sysV init以及CentOS 6的upstart機制，也就是說能夠繼續將服務管理腳本放入/etc/rc.d/init.d目錄中管理

  systemd與sysV init 以及upstart不兼容之處：
　　一、/etc/rc.d/init.d目錄中的服務管理腳本不能夠用systemctl命令來管理，systemctl命令的參數已經固定
　　二、/etc/rc.d/init.d目錄中的服務管理腳本啓動的服務，與systemd管理啓動的進程之間沒法通訊
　　三、systemd雖然模擬出run level，可是與init、upstart機制的運行級別不徹底一致

核心概念：Unit
  unit表示不一樣類型的systemd對象，經過配置文件進行標識和配置；文件中主要包含了系統服務、監聽socket、保存的系統快照以及其它與init相關的信息；
  系統初始化須要作的事情很是多。須要啓動後臺服務，好比啓動SSHD服務；須要作配置工做，好比掛載文件系統。這個過程當中的每一步都被systemd抽象爲一個配置單元，即 unit。能夠認爲一個服務是一個配置單元；一個掛載點是一個配置單元；一個交換分區的配置是一個配置單元；systemd 將配置單元概括爲如下一些不一樣的類型。然而systemd正在快速發展，新功能不斷增長。因此配置單元類型可能在不久的未來繼續增長。

  systemctl -t help 查看unit類型
演示：
[root@centos7 ~]# systemctl -t help
Available unit types:
service
socket
busname
target
snapshot
device
mount
automount
swap
timer
path
slice
scope

  service ：
　　文件擴展名爲.service, 用於定義系統服務
　　表明一個後臺服務進程，好比mysqld。這是最經常使用的一類。
    
　socket ：
　　文件擴展名爲.socket, 用於標識進程間通訊用的socket文件，也可在系統啓動時，延遲啓動服務，實現按需啓動
　　此類配置單元封裝系統和互聯網中的一個套接字 。當下，systemd支持流式、數據報和連續包的AF_INET、AF_INET六、AF_UNIX socket。每個套接字配置單元都有一個相應的服務配置單元。相應的服務在第一個"鏈接"進入套接字時就會啓動(例如：nscd.socket 在有新鏈接後便啓動 nscd.service)。

  device ：
　　文件擴展名爲.device, 用於定義內核識別的設備
　　此類配置單元封裝一個存在於 Linux 設備樹中的設備。每個使用 udev 規則標記的設備都將會在 systemd 中做爲一個設備配置單元出現。

  mount ：
　　文件擴展名爲.mount, 定義文件系統掛載點
　　此類配置單元封裝文件系統結構層次中的一個掛載點。Systemd 將對這個掛載點進行監控和管理。好比能夠在啓動時自動將其掛載；能夠在某些條件下自動卸載。Systemd 會將/etc/fstab 中的條目都轉換爲掛載點，並在開機時處理。

  automount ：
　　文件擴展名爲.automount，文件系統的自動掛載點
　　此類配置單元封裝系統結構層次中的一個自掛載點。每個自掛載配置單元對應一個掛載配置單元 ，當該自動掛載點被訪問時，systemd 執行掛載點中定義的掛載行爲。

  swap:
　　文件擴展名爲.swap, 用於標識swap設備
　　和掛載配置單元相似，交換配置單元用來管理交換分區。用戶能夠用交換配置單元來定義系統中的交換分區，可讓這些交換分區在啓動時被激活。

  target ：
　　文件擴展名爲.target，用於模擬實現「運行級別」
　　此類配置單元爲其餘配置單元進行邏輯分組。它們自己實際上並不作什麼，只是引用其餘配置單元而已。這樣即可以對配置單元作一個統一的控制。這樣就能夠實現你們都已經很是熟悉的運行級別概念。好比想讓系統進入圖形化模式，須要運行許多服務和配置命令，這些操做都由一個個配置單元表示，將全部這些配置單元組合爲一個目標(target)，就表示須要將這些配置單元所有執行一遍以便進入目標所表明的系統運行狀態。 (例如：multi-user.target 至關於在傳統使用 SysV 的系統中運行級別 5)

  timer：
　　文件擴展名爲.timer
　　定時器配置單元用來定時觸發用戶定義的操做，這類配置單元取代了 atd、crond 等傳統的定時服務。

  snapshot ：
　　文件擴展名爲.snapshot, 管理系統快照
　　與 target 配置單元類似，快照是一組配置單元。它保存了系統當前的運行狀態。

  path：
　　文件擴展名爲.path，用於定義文件系統中的一個文件或目錄使用,經常使用於當文件系統變化時，延遲激活服務，如：spool 目錄
　　定義了能夠被基於路徑的觸發激活所使用的路徑。默認狀況下，當路徑到了指定的狀態(切換到了指定的路徑)，一個同名的.service文件將會啓用。這裏是採用inotify去監控路徑的改變

  slice：
　　文件擴展名爲.slice：與Linux的CGroup相關。其名稱反應了其在cgroup樹的層次。默認狀況下，單元依據其類型的不一樣被放置在必定的slice裏面。

  scope：
　　文件擴展名爲.scope：Scope單元由systemd接收到總線接口的信息而自動生成。這些Scope單元用於管理由外部建立的系統進程(非Systemd 啓動的外部進程)。

配置文件：
　/etc/systemd/system/：
　　存放系統啓動的默認級別及啓動的unit的軟鏈接，優先級最高，相似於/etc/rc.d/rcN.d/S*類的功能
　　Systemd 默認從目錄/etc/systemd/system/讀取配置文件。可是裏面存放的大部分文件都是符號連接指向目錄/usr/lib/systemd/system/
　　systemctl enable命令用於在上面兩個目錄之間創建符號連接關係
　　示例：
　　/etc/systemd/system/vsftpd.service.wants/*：此目錄內的文件爲連接檔，設定相依服務的連結。意思是啓動了vsftpd.service以後，最好再加上這目錄底下建議的服務
　　/etc/systemd/system/vsftpd.service.requires/*：此目錄內的文件爲連接檔，設定相依服務的連結。意思是在啓動vsftpd.service以前，須要事先啓動哪些服務的意思

  /run/systemd/system/：
　　系統執行過程當中所產生系統單元，優先級次之

  /usr/lib/systemd/system/：
　　存放系統上全部的啓動文件，優先級最低；相似於以前的/etc/init.d/

service類型的unit管理
  service類型的unit：
　　啓動：service name start ==> systemctl start name.service
　　中止：service name stop ==> systemctl stop name.service
　　重啓：service name restart ==> systemctl restart name.service
　　狀態：service name status ==> systemctl status name.service
　　顯示遠端主機服務狀態：systemctl -H User@IP status name.service
　　條件式重啓：service name condrestart ==> systemctl try-restart name.service(若是服務是啓動狀態就不操做，若是是中止狀態就啓動它)
　　殺死服務及其子進程：systemctl kill name.service
　　重載服務的配置：sudo systemctl reload name.service
　　重載全部修改過的配置文件：systemctl daemon-reload
　　重載或重啓服務：systemctl reload-or-restart name.service
　　重載或條件式重啓服務：systemctl reload-or-try-restart name.service
　　禁止設定爲開機自啓：systemctl mask name.service
　　取消禁止設定爲開機自啓：systemctl unmask name.service
　　顯示某個 Unit 的全部底層參數：systemctl show name.service
　　顯示某個 Unit 的指定屬性的值：systemctl show -p CPUShares httpd.service
　　設置某個 Unit 的指定屬性：systemctl set-property httpd.service CPUShares=500

  service類型的unit狀態查看：
　　查看某服務是否處於激活的狀態
　　systemctl is-active name.service
　　查看某服務是否處於啓動失敗狀態
　　systemctl is-failed name.service
　　查看全部已經激活的服務
　　systemctl list-units --type service或systemctl list-units -t service
　　查看全部服務(已激活及未激活)：
　　systemctl list-units --type service --all或systemctl list-units -t service -a
　　顯示某個服務是否創建了啓動連接(開機啓動)
　　systemctl is-enabled name.service
    
　　service類型的unit狀態：
　　loaded：Unit配置文件已處理
　　active(running)：一次或屢次持續處理的運行
　　active(exited)：成功完成一次性的配置
　　active(waiting)：運行中，等待一個事件
　　inactive(dead)：不運行
  
  units狀態查看：
　　列出正在運行的Unit：
　　systemctl list-units
　　列出全部Unit，包括沒有找到配置文件的或者啓動失敗的：
　　systemctl list-units --all
　　列出全部沒有運行的Unit：
　　systemctl list-units --all --state=inactive
　　列出全部加載失敗的 Unit：
　　systemctl list-units --failed
　　列出全部正在運行的、類型爲service的Unit：
　　systemctl list-units --type=service

  service類型的unit開機啓動設置：
　　設定某服務開機自啓：
　　chkconfig name on ==> systemctl enable name.service
　　設定某服務開機禁止啓動：
　　chkconfig name off ==> systemctl disable name.service
　　查看全部服務的開機自啓狀態：
　　chkconfig --list ==> systemctl list-unit-files --type service
　　用來列出該服務在哪些運行級別下啓用和禁用
　　chkconfig sshd --list==> ls /etc/systemd/system/*.wants/sshd.service
　　查看服務可否開機自啓：
　　chkconfig --list name ==> systemctl is-enabled name.service
　　查看服務的依賴關係：
　　systemctll ist-dependencies name.service
　　上面命令的輸出結果之中，有些依賴是Target類型，默認不會顯示。若是要顯示Target，就須要使用--all參數。
　　systemctl list-dependencies --all name.service

　　開機啓動狀態：
　　enabled：開機啓動(已創建啓動連接)
　　disabled：開機不啓動(沒創建啓動連接)
　　static：開機不啓動，該配置文件沒有[Install]部分(沒法執行)，只能做爲其餘配置文件的依賴  
　　masked：該配置文件被禁止創建啓動連接

  service類型的unit配置文件：
  文件位置：
　　/etc/systemd/system：系統管理員和用戶使用
　　/usr/lib/systemd/system：發行版打包者使用
  文件說明：
　　以"#"開頭的行被認爲是註釋
　　相關布爾值，一、yes、on、true都是開啓，0、no、off、false都是關閉
　　時間單位默認是秒，要用毫秒(ms)分鐘(m)明確指定單位
　　配置文件的區塊名、字段名都大小寫敏感；每一個區塊內部是等號鏈接的鍵值對，鍵值對與等號兩側不能有空格

  配置文件就是普通的文本文件，能夠用文本編輯器打開。也能夠經過如下命令指定服務的配置文件內容。
　　systemctl cat name.service

  service unit file文件一般由三部分組成：
　　[Unit]：定義與Unit類型無關的通用選項；用於提供unit的描述信息、unit行爲及依賴關係等;
　　[Service]：與特定類型相關的專用選項；此處爲Service類型
　　[Install]：定義由"systemctl enable"以及"systemctl disable"命令在實現服務開機啓用或禁用時用到的一些選項

  [Unit]：區塊一般是配置文件的第一個區塊，用來定義Unit的元數據，以及配置與其餘Unit的關係。主要字段以下：
　　Description：簡短描述
　　Documentation：文檔地址
　　equires：當前Unit依賴的其餘Unit，若是它們沒有運行，當前Unit會啓動失敗(強依賴)
　　Wants：與當前Unit配合的其餘 Unit，若是它們沒有運行，當前Unit不會啓動失敗(弱依賴)
　　BindsTo：與Requires相似，它指定的Unit若是退出，會致使當前Unit中止運行
　　Before：若是該字段指定的Unit也要啓動，那麼必須在當前Unit以後啓動
　　After：若是該字段指定的Unit也要啓動，那麼必須在當前Unit以前啓動
　　Conflicts：這裏指定的Unit不能與當前Unit同時運行
　　Condition...：當前Unit運行必須知足的條件，不然不會運行
　　Assert...：當前Unit運行必須知足的條件，不然會報啓動失敗

  注意：After和Before字段只涉及啓動順序，不涉及依賴關係；設置依賴關係，須要使用Wants字段和Requires字段；Wants字段與Requires字段只涉及依賴關係，與啓動順序無關，默認狀況下是同時啓動的

  [Install]：一般是配置文件的最後一個區塊，用來定義如何啓動，以及是否開機啓動。主要字段以下：
　　WantedBy：它的值是一個或多個Target，當前Unit激活時(enable)符號連接會放入/etc/systemd/system目錄下面以Target名+.wants後綴構成的子目錄中
　　RequiredBy：它的值是一個或多個Target，當前Unit激活時，符號連接會放入/etc/systemd/system目錄下面以Target名+.required後綴構成的子目錄中
　　Alias：當前Unit可用於啓動的別名
　　Also：當前Unit激活(enable)時，會被同時激活的其它Unit

  [Service]：區塊是Service的配置，只有Service類型的Unit纔有這個區塊。主要字段以下：
　　Type：定義啓動時的進程行爲。它有如下幾種值。
　　　　Type=simple：默認值，ExecStart字段啓動的進程爲主進程
　　　　Type=forking：ExecStart字段將以fork()方式啓動(從父進程建立子進程)，此時父進程將會退出，子進程成爲主進程
　　　　Type=oneshot：相似於simple，但只執行一次，Systemd 會等它執行完，才啓動其餘服務
　　　　Type=dbus：相似於simple，但會等待 D-Bus信號後啓動(經過D-Bus啓動)
　　　　Type=notify：相似於simple，當前服務啓動完畢後會發通知信號給Systemd，而後Systemd再啓動其餘服務
　　　　Type=idle：相似於simple，可是要等到其餘任務都執行完，纔會啓動該服務。一種使用場合是爲讓該服務的輸出，不與其餘服務的輸出相混合
　　ExecStart：啓動當前服務的命令
　　ExecStartPre：啓動當前服務以前執行的命令
　　ExecStartPost：啓動當前服務以後執行的命令
　　ExecReload：重啓當前服務時執行的命令
　　ExecStop：中止當前服務時執行的命令
　　ExecStopPost：中止當其服務以後執行的命令
　　RestartSec：自動重啓當前服務間隔的秒數
　　Restart：定義何種狀況Systemd會自動重啓當前服務，可能的值包括always(老是重啓)、on-success、on-failure、on-abnormal、on-abort、on-watchdog
　　TimeoutSec：定義Systemd中止當前服務以前等待的秒數
　　Environment：指定環境變量
　　EnvironmentFile：指定當前服務的環境參數文件。該文件內部的key=value鍵值對，能夠用$key的形式，在當前配置文件中獲取

target類型unit管理：
  啓動計算機的時候，須要啓動大量的Unit。若是每一次啓動，都要一一寫明本次啓動須要哪些Unit，顯然很是不方便。Systemd的解決方案就是 Target。簡單說，Target就是一個Unit 組，包含許多相關的Unit。啓動某個Target的時候，Systemd就會啓動裏面全部的 Unit。從這個意義上說，Target 這個概念相似於"狀態點"，啓動某個 Target 就比如啓動到某種狀態。
  傳統的init啓動模式裏面，有RunLevel的概念，跟Target的做用很相似。不一樣的是RunLevel 是互斥的，不可能多個 RunLevel 同時啓動，可是多個 Target能夠同時啓動。

  target類型unit配置文件：
　　/usr/lib/systemd/system/*.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     重啓

  查看當前系統的全部Target開機啓動狀態
　　systemctl list-unit-files --type target
　　systemctl list-unit-files --type target --all
  查看一個Target包含的全部Unit(依賴關係)
　　systemctl list-dependencies multi-user.target
　　systemctl list-dependencies graphical.target

  運行級別切換：
　　init N ==> systemctl isolate name.target
　　systemctl isolate multi-user.target 切換到級別3
　　systemctl isolate graphical.target 切換到級別5
　注意：
　　一、只有/lib/systemd/system/*.target文件中AllowIsolate=yes才能切換(修改文件需執行systemctl daemon-reload才能生效)
　　二、切換Target時，默認不關閉前一個Target啓動的進程，systemctl isolate命令改變這種行爲，關閉前一個Target裏面全部不屬於後一個 Target 的進程
  查看運行級別(查看全部激活的target)：
　　runlevel，who -r ==> systemctl list-units --type target
  獲取默認運行級別(查看啓動時的默認Target)：
　　/etc/inittab ==> systemctl get-default
  設置默認運行級別(設置啓動時的默認 Target)：
　　/etc/inittab==> systemctl set-default name.target
　　systemctl set-default multi-user.target 修改成3級別
　　systemctl set-default graphical.target 修改成5級別

  target與init進程的主要差異：
　　一、默認的RunLevel(在/etc/inittab文件設置)如今被默認的Target取代，位置是/etc/systemd/system/default.target，一般符號連接到graphical.target(圖形界面)或者multi-user.target(多用戶命令行)
　　二、啓動腳本的位置，之前是/etc/init.d目錄，符號連接到不一樣的RunLevel目錄(好比/etc/rc3.d、/etc/rc5.d等)，如今則存放在/lib/systemd/system和/etc/systemd/system目錄。
　　三、配置文件的位置，之前init進程的配置文件是/etc/inittab，各類服務的配置文件存放在/etc/sysconfig目錄。如今的配置文件主要存放在/lib/systemd目錄，在/etc/systemd目錄裏面的修改能夠覆蓋原始設置。

  target類型的unit配置文件：

systemd系統管理類命令：
  Systemd並非一個命令，而是一組命令，涉及到系統管理的方方面面。systemctl是Systemd 的主命令，用於管理系統。

  切換至緊急救援模式：
　　systemctl rescue
  切換至emergency(緊急)模式：
　　systemctl emergency

  傳統命令init、poweroff、halt、reboot都成爲systemctl的軟連接
  重啓系統：
　　systemctl reboot
  關閉系統，切斷電源：
　　systemctl poweroff
  CPU中止工做：
　　systemctl halt
  掛起系統：睡眠模式(也叫掛起suspend)，把信息保存到內存中，斷電數據丟失，可是恢復時較快
　　systemctl suspend
  讓系統進入休眠狀態：休眠模式把信息寫入到文件中(也就是硬盤中)，斷電數據不丟失，可是恢復時較慢，像從新開機同樣
　　systemctl hibernate
  讓系統進入混合休眠狀態：是指suspend(睡眠模式)和hibernate(休眠模式)同時進行，即把信息保存到內存的同時也寫入到系統主分區的hiberfil. sys文件中
　　systemctl hybrid-sleep

  systemd-analyze命令用於查看啓動耗時。
  查看啓動耗時：
　　systemd-analyze
  查看每一個服務的啓動耗時：
　　systemd-analyze blame
  顯示瀑布狀的啓動過程流：
　　systemd-analyze critical-chain
  顯示指定服務的啓動流：
　　systemd-analyze critical-chain name.service

  hostnamectl命令用於查看當前主機的信息。
  顯示當前主機的信息
　　hostnamectl
  設置主機名。
　　hostnamectl set-hostname New_Hostname

  localectl命令用於查看本地化設置。
  查看本地化設置
　　localectl
  設置本地化參數。
　　localectl set-locale LANG=en_US.utf8
　　localectl set-keymap en_US

  timedatectl命令用於查看當前時區設置。
  查看當前時區設置
　　timedatectl
  顯示全部可用的時區
　　timedatectl list-timezones
  設置當前時區
　　timedatectl set-timezone Asia/Shanghai
　　timedatectl set-time YYYY-MM-DD
　　timedatectl set-time HH:MM:SS

  loginctl命令用於查看當前登陸的用戶。
  列出當前session
　　loginctl list-sessions
  列出當前登陸用戶
　　loginctl list-users
  列出顯示指定用戶的信息
　　loginctl show-user Username

日誌管理
  Systemd統一管理全部Unit的啓動日誌。帶來的好處就是，能夠只用journalctl一個命令，查看全部日誌(內核日誌和應用日誌)。日誌的配置文件是/etc/systemd/journald.conf；journalctl功能強大，用法很是多。

  查看全部日誌(默認狀況下 ，只保存本次啓動的日誌)
　　journalctl
  查看內核日誌(不顯示應用日誌)
　　journalctl -k

  查看系統本次啓動的日誌
　　journalctl -b
　　journalctl -b -0
  查看上一次啓動的日誌(需更改設置)
　　journalctl -b -1

  查看指定時間的日誌
　　journalctl --since="2012-10-30 18:17:16"
　　journalctl --since "20 min ago"
　　journalctl --since yesterday
　　journalctl --since "2015-01-10" --until "2015-01-11 03:00"
　　journalctl --since 09:00 --until "1 hour ago"

  顯示尾部的最新10行日誌
　　journalctl -n
  顯示尾部指定行數的日誌
　　journalctl -n 20
  實時滾動顯示最新日誌
　　journalctl -f

  查看指定服務的日誌
　　journalctl /usr/lib/systemd/systemd
  查看指定進程的日誌
　　journalctl _PID=1
  查看某個路徑的腳本的日誌
　　journalctl /usr/bin/bash
  查看指定用戶的日誌
　　journalctl _UID=33 --since today
  查看某個 Unit 的日誌
　　journalctl -u name.service
　　journalctl -u name.service --since today
  實時滾動顯示某個 Unit 的最新日誌
　　journalctl -u name.service -f
  合併顯示多個 Unit 的日誌
　　journalctl -u name1.service -u name2.service --since today

  查看指定日誌級別的日誌，共有8級
　　journalctl -p err -b
    0: emerg
    1: alert
    2: crit
    3: err
    4: warning
    5: notice
    6: info
    7: debug

  日誌默認分頁輸出，--no-pager改成正常的標準輸出
　　journalctl --no-pager

  以JSON格式(單行)輸出
　　journalctl -b -u name.service -o json
  以JSON格式(多行)輸出，可讀性更好
　　journalctl -b -u name.service -o json-pretty

  顯示日誌佔據的硬盤空間
　　journalctl --disk-usage
  指定日誌文件佔據的最大空間
　　journalctl --vacuum-size=1G
  指定日誌文件保存多久
　　journalctl --vacuum-time=1years

CentOS 7 引導順序
  UEFI或BIOS初始化，運行POST開機自檢
  選擇啓動設備
  引導裝載程序，centos7是grub2
  加載裝載程序的配置文件：/etc/grub.d/ /etc/default/grub /boot/grub2/grub.cfg
  加載initramfs驅動模塊
  加載內核選項
  內核初始化，Centos7使用systemd代替init
  執行initrd.target全部單元，包括掛載/etc/fstab
  從initramfs根文件系統切換到磁盤根目錄
  systemd執行默認target配置，配置文件/etc/systemd/default.target /etc/systemd/system/
  systemd執行sysinit.target初始化系統及basic.target準備操做系統
  systemd啓動multi-user.target下的本機與服務器服務
  systemd執行multi-user.target下的/etc/rc.d/rc.local
  systemd執行multi-user.target下的getty.target及登入服務
  systemd執行graphical須要的服務

一、設置內核參數：
  設置內核參數，隻影響當次啓動；啓動時，在linux16行後添加
　　systemd.unit=desired.target
　　systemd.unit=emergency.target
　　systemd.unit=recure.target
　　recure.target 比emergency 支持更多的功能，例如日誌等

二、啓動排錯：
  文件系統損壞；先嚐試自動修復，失敗則進入emergency shell，提示用戶修復
  在/etc/fstab不存在對應的設備和UUID；等一段時間，如不可用，進入emergency shell
  在/etc/fstab不存在對應掛載點；systemd嘗試建立掛載點，不然提示進入emergency shell
  在/etc/fstab不正確的掛載選項；提示進入emergency shell

三、破解root密碼：
  啓動時任意鍵暫停啓動
  按e鍵進入編輯模式
  將光標移動到linux16開始的行，添加內核參數rd.break
  按ctrl+x啓動
　　mount -o remount,rw /systoot 默認啓動爲只讀掛載，從新掛載爲讀寫
　　chroot /sysroot 切換到真正文件系統的根
　　passwd root 設置root密碼
　　touch /.autorelabel 要從新打標籤，觸發selinux策略

四、修復GRUB2
  主配置文件：/boot/grub2/grub.cfg
  修復配置文件：grub2-mkconfig > /boot/grub2/grub.cfg
  修復grub：
　　grub2-install /dev/sda BIOS環境下
　　grub2-install UEFI環境下