可能是史上最全面易懂的 Systemd 服務管理教程！( 強烈建議收藏 )

2019 年 10 月 10 日
筆記

Systemd 概述

Systemd 簡介

Systemd 是一系列工具的集合，其作用也遠遠不僅是啟動作業系統，它還接管了後台服務、結束、狀態查詢，以及日誌歸檔、設備管理、電源管理、定時任務等許多職責，並支援通過特定事件（如插入特定 USB 設備）和特定埠數據觸發的 On-demand（按需）任務。

Systemd 的後台服務還有一個特殊的身份——它是系統中 PID 值為 1 的進程。

更少的進程

Systemd 提供了服務按需啟動的能力，使得特定的服務只有在真定被請求時才啟動。

允許更多的進程並行啟動

在 SysV-init 時代，將每個服務項目編號依次執行啟動腳本。Ubuntu 的 Upstart 解決了沒有直接依賴的啟動之間的並行啟動。而 Systemd 通過 Socket 快取、DBus 快取和建立臨時掛載點等方法進一步解決了啟動進程之間的依賴，做到了所有系統服務並發啟動。對於用戶自定義的服務，Systemd 允許配置其啟動依賴項目，從而確保服務按必要的順序運行。

使用 CGroup 跟蹤和管理進程的生命周期

在 Systemd 之間的主流應用管理服務都是使用進程樹來跟蹤應用的繼承關係的，而進程的父子關係很容易通過兩次 fork 的方法脫離。

而 Systemd 則提供通過 CGroup 跟蹤進程關係，引補了這個缺漏。通過 CGroup 不僅能夠實現服務之間訪問隔離，限制特定應用程式對系統資源的訪問配額，還能更精確地管理服務的生命周期。

統一管理服務日誌

Systemd 是一系列工具的集合，包括了一個專用的系統日誌管理服務：Journald。這個服務的設計初衷是克服現有 Syslog 服務的日誌內容易偽造和日誌格式不統一等缺點，Journald 用二進位格式保存所有的日誌資訊，因而日誌內容很難被手工偽造。Journald 還提供了一個 journalctl 命令來查看日誌資訊，這樣就使得不同服務輸出的日誌具有相同的排版格式，便於數據的二次處理。

Systemd 架構

Systemd 的 Unit 文件

Systemd 可以管理所有系統資源，不同的資源統稱為 Unit（單位）。

在 Systemd 的生態圈中，Unit 文件統一了過去各種不同系統資源配置格式，例如服務的啟/停、定時任務、設備自動掛載、網路配置、虛擬記憶體配置等。而 Systemd 通過不同的文件後綴來區分這些配置文件。

Systemd 支援的 12 種 Unit 文件類型

.automount：用於控制自動掛載文件系統，相當於 SysV-init 的 autofs 服務
.device：對於 /dev 目錄下的設備，主要用於定義設備之間的依賴關係
.mount：定義系統結構層次中的一個掛載點，可以替代過去的 /etc/fstab 配置文件
.path：用於監控指定目錄或文件的變化，並觸發其它 Unit 運行
.scope：這種 Unit 文件不是用戶創建的，而是 Systemd 運行時產生的，描述一些系統服務的分組資訊
.service：封裝守護進程的啟動、停止、重啟和重載操作，是最常見的一種 Unit 文件
.slice：用於表示一個 CGroup 的樹，通常用戶不會自己創建這樣的 Unit 文件
.snapshot：用於表示一個由 systemctl snapshot 命令創建的 Systemd Units 運行狀態快照
.socket：監控來自於系統或網路的數據消息，用於實現基於數據自動觸發服務啟動
.swap：定義一個用戶做虛擬記憶體的交換分區
.target：用於對 Unit 文件進行邏輯分組，引導其它 Unit 的執行。它替代了 SysV-init 運行級別的作用，並提供更靈活的基於特定設備事件的啟動方式
.timer：用於配置在特定時間觸發的任務，替代了 Crontab 的功能

Unit 文件按照 Systemd 約定，應該被放置指定的三個系統目錄之一中。這三個目錄是有優先順序的，如下所示，越靠上的優先順序越高。因此，在三個目錄中有同名文件的時候，只有優先順序最高的目錄里的那個文件會被使用。

/etc/systemd/system：系統或用戶自定義的配置文件
/run/systemd/system：軟體運行時生成的配置文件
/usr/lib/systemd/system：系統或第三方軟體安裝時添加的配置文件。
- CentOS 7：Unit 文件指向該目錄
- ubuntu 16：被移到了 /lib/systemd/system

Systemd 默認從目錄 /etc/systemd/system/ 讀取配置文件。但是，裡面存放的大部分文件都是符號鏈接，指向目錄 /usr/lib/systemd/system/，真正的配置文件存放在那個目錄。

Unit 和 Target

Unit 是 Systemd 管理系統資源的基本單元，可以認為每個系統資源就是一個 Unit，並使用一個 Unit 文件定義。在 Unit 文件中需要包含相應服務的描述、屬性以及需要運行的命令。

Target 是 Systemd 中用於指定系統資源啟動組的方式，相當於 SysV-init 中的運行級別。

簡單說，Target 就是一個 Unit 組，包含許多相關的 Unit 。啟動某個 Target 的時候，Systemd 就會啟動裡面所有的 Unit。從這個意義上說，Target 這個概念類似於」狀態點」，啟動某個 Target 就好比啟動到某種狀態。

Systemd Service Unit

Unit 文件結構

[Unit]  Description=Hello World  After=docker.service  Requires=docker.service  [Service]  TimeoutStartSec=0  ExecStartPre=-/usr/bin/docker kill busybox1  ExecStartPre=-/usr/bin/docker rm busybox1  ExecStartPre=/usr/bin/docker pull busybox  ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/ sh -c "while true; do echo Hello World; sleep 1; done"  ExecStop="/usr/bin/docker stop busybox1"  ExecStopPost="/usr/bin/docker rm busybox1"  [Install]  WantedBy=multi-user.target

如下所示，Systemd 服務的 Unit 文件可以分為三個配置區段：

Unit 和 Install 段：所有 Unit 文件通用，用於配置服務（或其它系統資源）的描述、依賴和隨系統啟動的方式
Service 段：服務（Service）類型的 Unit 文件（後綴為 .service）特有的，用於定義服務的具體管理和操作方法

Unit 段

Description：描述這個 Unit 文件的資訊
Documentation：指定服務的文檔，可以是一個或多個文檔的 URL 路徑
Requires：依賴的其它 Unit 列表，列在其中的 Unit 模板會在這個服務啟動時的同時被啟動。並且，如果其中任意一個服務啟動失敗，這個服務也會被終止
Wants：與 Requires 相似，但只是在被配置的這個 Unit 啟動時，觸發啟動列出的每個 Unit 模組，而不去考慮這些模板啟動是否成功
After：與 Requires 相似，但是在後面列出的所有模組全部啟動完成以後，才會啟動當前的服務
Before：與 After 相反，在啟動指定的任務一個模組之間，都會首先確證當前服務已經運行
Binds To：與 Requires 相似，失敗時失敗，成功時成功，但是在這些模板中有任意一個出現意外結束或重啟時，這個服務也會跟著終止或重啟
Part Of：一個 Bind To 作用的子集，僅在列出的任務模組失敗或重啟時，終止或重啟當前服務，而不會隨列出模板的啟動而啟動
OnFailure：當這個模板啟動失敗時，就會自動啟動列出的每個模組
Conflicts：與這個模組有衝突的模組，如果列出的模組中有已經在運行的，這個服務就不能啟動，反之亦然

Install 段

這部分配置的目標模組通常是特定運行目標的 .target 文件，用來使得服務在系統啟動時自動運行。這個區段可以包含三種啟動約束：

WantedBy：和 Unit 段的 Wants 作用相似，只有後面列出的不是服務所依賴的模組，而是依賴當前服務的模組。它的值是一個或多個 Target，當前 Unit 激活時（enable）符號鏈接會放入 /etc/systemd/system 目錄下面以 <Target 名> + .wants 後綴構成的子目錄中，如「/etc/systemd/system/multi-user.target.wants/「

# find /etc/systemd/system/* -type d  /etc/systemd/system/default.target.wants  /etc/systemd/system/getty.target.wants  /etc/systemd/system/graphical.target.wants  /etc/systemd/system/multi-user.target.wants  /etc/systemd/system/network-online.target.wants  /etc/systemd/system/paths.target.wants  /etc/systemd/system/shutdown.target.wants  /etc/systemd/system/sockets.target.wants  /etc/systemd/system/sysinit.target.wants  /etc/systemd/system/timers.target.wants

RequiredBy：和 Unit 段的 Wants 作用相似，只有後面列出的不是服務所依賴的模組，而是依賴當前服務的模組。它的值是一個或多個 Target，當前 Unit 激活時，符號鏈接會放入 /etc/systemd/system 目錄下面以 <Target 名> + .required 後綴構成的子目錄中
Also：當前 Unit enable/disable 時，同時 enable/disable 的其他 Unit
Alias：當前 Unit 可用於啟動的別名

SysV-init 運行級別與 Systemd Target 對應的 Unit 文件

通過 systemctl list-units –type=target 命令可以獲取當前正在使用的運行目標

# systemctl list-units --type=target  UNIT                   LOAD   ACTIVE SUB    DESCRIPTION  basic.target           loaded active active Basic System  cryptsetup.target      loaded active active Encrypted Volumes  getty.target           loaded active active Login Prompts  graphical.target       loaded active active Graphical Interface  local-fs-pre.target    loaded active active Local File Systems (Pre)  local-fs.target        loaded active active Local File Systems  multi-user.target      loaded active active Multi-User System  network-online.target  loaded active active Network is Online  network.target         loaded active active Network  nss-user-lookup.target loaded active active User and Group Name Lookups  paths.target           loaded active active Paths  remote-fs-pre.target   loaded active active Remote File Systems (Pre)  remote-fs.target       loaded active active Remote File Systems  slices.target          loaded active active Slices  sockets.target         loaded active active Sockets  sound.target           loaded active active Sound Card  swap.target            loaded active active Swap  sysinit.target         loaded active active System Initialization  time-sync.target       loaded active active System Time Synchronized  timers.target          loaded active active Timers  LOAD   = Reflects whether the unit definition was properly loaded.  ACTIVE = The high-level unit activation state, i.e. generalization of SUB.  SUB    = The low-level unit activation state, values depend on unit type.  20 loaded units listed. Pass --all to see loaded but inactive units, too.  To show all installed unit files use 'systemctl list-unit-files'.

Service 段

用來 Service 的配置，只有 Service 類型的 Unit 才有這個區塊。它的主要欄位分為服務生命周期和服務上下文配置兩個方面。

服務生命周期控制相關

Type：定義啟動時的進程行為，它有以下幾種值：
- Type=simple：默認值，執行ExecStart指定的命令，啟動主進程
- Type=forking：以 fork 方式從父進程創建子進程，創建後父進程會立即退出
- Type=oneshot：一次性進程，Systemd 會等當前服務退出，再繼續往下執行
- Type=dbus：當前服務通過D-Bus啟動
- Type=notify：當前服務啟動完畢，會通知Systemd，再繼續往下執行
- Type=idle：若有其他任務執行完畢，當前服務才會運行
RemainAfterExit：值為 true 或 false（默認）。當配置為 true 時，Systemd 只會負責啟動服務進程，之後即便服務進程退出了，Systemd 也仍然會認為這個服務還在運行中。這個配置主要是提供給一些並非常駐記憶體，而是啟動註冊後立即退出，然後等待消息按需啟動的特殊類型服務使用的。
ExecStart：啟動當前服務的命令
ExecStartPre：啟動當前服務之前執行的命令
ExecStartPos：啟動當前服務之後執行的命令
ExecReload：重啟當前服務時執行的命令
ExecStop：停止當前服務時執行的命令
ExecStopPost：停止當其服務之後執行的命令
RestartSec：自動重啟當前服務間隔的秒數
Restart：定義何種情況 Systemd 會自動重啟當前服務，可能的值包括 always（總是重啟）、on-success、on-failure、on-abnormal、on-abort、on-watchdog
TimeoutStartSec：啟動服務時等待的秒數，這一配置對於使用 Docker 容器而言顯得尤為重要，因其第一次運行時可能需要下載鏡像，嚴重延時會容易被 Systemd 誤判為啟動失敗殺死。通常，對於這種服務，將此值指定為 0，從而關閉超時檢測
TimeoutStopSec：停止服務時的等待秒數，如果超過這個時間仍然沒有停止，Systemd 會使用 SIGKILL 訊號強行殺死服務的進程

服務上下文配置相關

Environment：為服務指定環境變數
EnvironmentFile：指定載入一個包含服務所需的環境變數的列表的文件，文件中的每一行都是一個環境變數的定義
Nice：服務的進程優先順序，值越小優先順序越高，默認為 0。其中 -20 為最高優先順序，19 為最低優先順序
WorkingDirectory：指定服務的工作目錄
RootDirectory：指定服務進程的根目錄（/ 目錄）。如果配置了這個參數，服務將無法訪問指定目錄以外的任何文件
User：指定運行服務的用戶
Group：指定運行服務的用戶組
MountFlags：服務的 Mount Namespace 配置，會影響進程上下文中掛載點的資訊，即服務是否會繼承主機上已有掛載點，以及如果服務運行執行了掛載或卸載設備的操作，是否會真實地在主機上產生效果。可選值為 shared、slaved 或 private
- shared：服務與主機共用一個 Mount Namespace，繼承主機掛載點，且服務掛載或卸載設備會真實地反映到主機上
- slave：服務使用獨立的 Mount Namespace，它會繼承主機掛載點，但服務對掛載點的操作只有在自己的 Namespace 內生效，不會反映到主機上
- private：服務使用獨立的 Mount Namespace，它在啟動時沒有任何任何掛載點，服務對掛載點的操作也不會反映到主機上
LimitCPU / LimitSTACK / LimitNOFILE / LimitNPROC 等：限制特定服務的系統資源量，例如 CPU、程式堆棧、文件句柄數量、子進程數量等

注意：如果在 ExecStart、ExecStop 等屬性中使用了 Linux 命令，則必須要寫出完整的絕對路徑。對於 ExecStartPre 和 ExecStartPost 輔助命令，若前面有個「-」符號，表示忽略這些命令的出錯。因為有些「輔助」命令本來就不一定成功，比如嘗試清空一個文件，但文件可能不存在。

Unit 文件佔位符和模板

Unit 文件佔位符

在 Unit 文件中，有時會需要使用到一些與運行環境有關的資訊，例如節點 ID、運行服務的用戶等。這些資訊可以使用佔位符來表示，然後在實際運行被動態地替換實際的值。

%n：完整的 Unit 文件名字，包括 .service 後綴名
%p：Unit 模板文件名中 @ 符號之前的部分，不包括 @ 符號
%i：Unit 模板文件名中 @ 符號之後的部分，不包括 @ 符號和 .service 後綴名
%t：存放系統運行文件的目錄，通常是「run」
%u：運行服務的用戶，如果 Unit 文件中沒有指定，則默認為 root
%U：運行服務的用戶 ID
%h：運行服務的用戶 Home 目錄，即 %{HOME} 環境變數的值
%s：運行服務的用戶默認 Shell 類型，即 %{SHELL} 環境變數的值
%m：實際運行節點的 Machine ID，對於運行位置每個的服務比較有用
%b：Boot ID，這是一個隨機數，每個節點各不相同，並且每次節點重啟時都會改變
%H：實際運行節點的主機名
%v：內核版本，即「uname -r」命令輸出的內容
%%：在 Unit 模板文件中表示一個普通的百分號

Unit 模板

在現實中，往往有一些應用需要被複制多份運行。例如，用於同一個負載均衡器分流的多個服務實例，或者為每個 SSH 連接建立一個獨立的 sshd 服務進程。

Unit 模板文件的寫法與普通的服務 Unit 文件基本相同，不過 Unit 模板的文件名是以 @ 符號結尾的。通過模板啟動服務實例時，需要在其文件名的 @ 字元後面附加一個參數字元串。

示例：[email protected]

[email protected] 模板

[Unit]  Description=My Advanced Service Template  After=etcd.service docker.service  [Service]  TimeoutStartSec=0  ExecStartPre=-/usr/bin/docker kill apache%i  ExecStartPre=-/usr/bin/docker rm apache%i  ExecStartPre=/usr/bin/docker pull coreos/apache  ExecStart=/usr/bin/docker run --name apache%i -p %i:80 coreos/apache /usr/sbin/apache2ctl -D FOREGROUND  ExecStartPost=/usr/bin/etcdctl set /domains/example.com/%H:%i running  ExecStop=/usr/bin/docker stop apache1  ExecStopPost=/usr/bin/docker rm apache1  ExecStopPost=/usr/bin/etcdctl rm /domains/example.com/%H:%i  [Install]  WantedBy=multi-user.target

啟動 Unit 模板的服務實例

在服務啟動時需要在 @ 後面放置一個用於區分服務實例的附加字元參數，通常這個參數用於監控的埠號或控制台 TTY 編譯號。

# systemctl start [email protected]

Systemd 在運行服務時，總是會先嘗試找到一個完整匹配的 Unit 文件，如果沒有找到，才會嘗試選擇匹配模板。例如上面的命令，System 首先會在約定的目錄下尋找名為 [email protected] 的文件，如果沒有找到，而文件名中包含 @ 字元，它就會嘗試去掉後綴參數匹配模板文件。對於 [email protected]，systemd 會找到 [email protected] 模板文件，並通過這個模板文件將服務實例化。

Systemd 的資源管理

Systemctl 命令

# systemctl --help  systemctl [OPTIONS...] {COMMAND} ...  Query or send control commands to the systemd manager.    -h --help           Show this help       --version        Show package version       --system         Connect to system manager    -H --host=[USER@]HOST                        Operate on remote host    -M --machine=CONTAINER                        Operate on local container    -t --type=TYPE      List units of a particular type       --state=STATE    List units with particular LOAD or SUB or ACTIVE state    -p --property=NAME  Show only properties by this name    -a --all            Show all loaded units/properties, including dead/empty                        ones. To list all units installed on the system, use                        the 'list-unit-files' command instead.    -l --full           Don't ellipsize unit names on output    -r --recursive      Show unit list of host and local containers       --reverse        Show reverse dependencies with 'list-dependencies'       --job-mode=MODE  Specify how to deal with already queued jobs, when                        queueing a new job       --show-types     When showing sockets, explicitly show their type    -i --ignore-inhibitors                        When shutting down or sleeping, ignore inhibitors       --kill-who=WHO   Who to send signal to    -s --signal=SIGNAL  Which signal to send       --now            Start or stop unit in addition to enabling or disabling it    -q --quiet          Suppress output       --no-block       Do not wait until operation finished       --no-wall        Don't send wall message before halt/power-off/reboot       --no-reload      Don't reload daemon after en-/dis-abling unit files       --no-legend      Do not print a legend (column headers and hints)       --no-pager       Do not pipe output into a pager       --no-ask-password                        Do not ask for system passwords       --global         Enable/disable unit files globally       --runtime        Enable unit files only temporarily until next reboot    -f --force          When enabling unit files, override existing symlinks                        When shutting down, execute action immediately       --preset-mode=   Apply only enable, only disable, or all presets       --root=PATH      Enable unit files in the specified root directory    -n --lines=INTEGER  Number of journal entries to show    -o --output=STRING  Change journal output mode (short, short-iso,                                short-precise, short-monotonic, verbose,                                export, json, json-pretty, json-sse, cat)       --plain          Print unit dependencies as a list instead of a tree  Unit Commands:    list-units [PATTERN...]         List loaded units    list-sockets [PATTERN...]       List loaded sockets ordered by address    list-timers [PATTERN...]        List loaded timers ordered by next elapse    start NAME...                   Start (activate) one or more units    stop NAME...                    Stop (deactivate) one or more units    reload NAME...                  Reload one or more units    restart NAME...                 Start or restart one or more units    try-restart NAME...             Restart one or more units if active    reload-or-restart NAME...       Reload one or more units if possible,                                    otherwise start or restart    reload-or-try-restart NAME...   Reload one or more units if possible,                                    otherwise restart if active    isolate NAME                    Start one unit and stop all others    kill NAME...                    Send signal to processes of a unit    is-active PATTERN...            Check whether units are active    is-failed PATTERN...            Check whether units are failed    status [PATTERN...|PID...]      Show runtime status of one or more units    show [PATTERN...|JOB...]        Show properties of one or more                                    units/jobs or the manager    cat PATTERN...                  Show files and drop-ins of one or more units    set-property NAME ASSIGNMENT... Sets one or more properties of a unit    help PATTERN...|PID...          Show manual for one or more units    reset-failed [PATTERN...]       Reset failed state for all, one, or more                                    units    list-dependencies [NAME]        Recursively show units which are required                                    or wanted by this unit or by which this                                    unit is required or wanted  Unit File Commands:    list-unit-files [PATTERN...]    List installed unit files    enable NAME...                  Enable one or more unit files    disable NAME...                 Disable one or more unit files    reenable NAME...                Reenable one or more unit files    preset NAME...                  Enable/disable one or more unit files                                    based on preset configuration    preset-all                      Enable/disable all unit files based on                                    preset configuration    is-enabled NAME...              Check whether unit files are enabled    mask NAME...                    Mask one or more units    unmask NAME...                  Unmask one or more units    link PATH...                    Link one or more units files into                                    the search path    add-wants TARGET NAME...        Add 'Wants' dependency for the target                                    on specified one or more units    add-requires TARGET NAME...     Add 'Requires' dependency for the target                                    on specified one or more units    edit NAME...                    Edit one or more unit files    get-default                     Get the name of the default target    set-default NAME                Set the default target  Machine Commands:    list-machines [PATTERN...]      List local containers and host  Job Commands:    list-jobs [PATTERN...]          List jobs    cancel [JOB...]                 Cancel all, one, or more jobs  Snapshot Commands:    snapshot [NAME]                 Create a snapshot    delete NAME...                  Remove one or more snapshots  Environment Commands:    show-environment                Dump environment    set-environment NAME=VALUE...   Set one or more environment variables    unset-environment NAME...       Unset one or more environment variables    import-environment [NAME...]    Import all or some environment variables  Manager Lifecycle Commands:    daemon-reload                   Reload systemd manager configuration    daemon-reexec                   Reexecute systemd manager  System Commands:    is-system-running               Check whether system is fully running    default                         Enter system default mode    rescue                          Enter system rescue mode    emergency                       Enter system emergency mode    halt                            Shut down and halt the system    poweroff                        Shut down and power-off the system    reboot [ARG]                    Shut down and reboot the system    kexec                           Shut down and reboot the system with kexec    exit                            Request user instance exit    switch-root ROOT [INIT]         Change to a different root file system    suspend                         Suspend the system    hibernate                       Hibernate the system    hybrid-sleep                    Hibernate and suspend the system

Unit 管理

查看當前系統的所有 Unit

# 列出正在運行的 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    # 查看 Unit 配置文件的內容  $ systemctl cat docker.service

查看 Unit 的狀態

enabled：已建立啟動鏈接
disabled：沒建立啟動鏈接
static：該配置文件沒有 [Install] 部分（無法執行），只能作為其他配置文件的依賴
masked：該配置文件被禁止建立啟動鏈接

# 顯示系統狀態  $ systemctl status    # 顯示單個 Unit 的狀態  $ ystemctl status bluetooth.service    # 顯示遠程主機的某個 Unit 的狀態  $ systemctl -H [email protected] status httpd.service

Unit 的管理

# 立即啟動一個服務  $ 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 的依賴關係

# 列出一個 Unit 的所有依賴，默認不會列出 target 類型  $ systemctl list-dependencies nginx.service    # 列出一個 Unit 的所有依賴，包括 target 類型  $ systemctl list-dependencies --all nginx.service

服務的生命周期

當一個新的 Unit 文件被放入 /etc/systemd/system/ 或 /usr/lib/systemd/system/ 目錄中時，它是不會被自識識別的。

服務的激活

systemctl enable：在 /etc/systemd/system/ 建立服務的符號鏈接，指向 /usr/lib/systemd/system/ 中
systemctl start：依次啟動定義在 Unit 文件中的 ExecStartPre、ExecStart 和 ExecStartPost 命令

服務的啟動和停止

systemctl start：依次啟動定義在 Unit 文件中的 ExecStartPre、ExecStart 和 ExecStartPost 命令
systemctl stop：依次停止定義在 Unit 文件中的 ExecStopPre、ExecStop 和 ExecStopPost 命令
systemctl restart：重啟服務
systemctl kill：立即殺死服務

服務的開機啟動和取消

systemctl enable：除了激活服務以外，也可以置服務為開機啟動
systemctl disable：取消服務的開機啟動

服務的修改和移除

systemctl daemon-reload：Systemd 會將 Unit 文件的內容寫到快取中，因此當 Unit 文件被更新時，需要告訴 Systemd 重新讀取所有的 Unit 文件
systemctl reset-failed：移除標記為丟失的 Unit 文件。在刪除 Unit 文件後，由於快取的關係，即使通過 daemon-reload 更新了快取，在 list-units 中依然會顯示標記為 not-found 的 Unit。

Target 管理

Target 就是一個 Unit 組，包含許多相關的 Unit 。啟動某個 Target 的時候，Systemd 就會啟動裡面所有的 Unit。

在傳統的 SysV-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 與 SysV-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 目錄裡面的修改可以覆蓋原始設置。

日誌管理

Systemd 通過其標準日誌服務 Journald 提供的配套程式 journalctl 將其管理的所有後台進程列印到 std:out（即控制台）的輸出重定向到了日誌文件。

Systemd 的日誌文件是二進位格式的，必須使用 Journald 提供的 journalctl 來查看，默認不帶任何參數時會輸出系統和所有後台進程的混合日誌。

默認日誌最大限制為所在文件系統容量的 10%，可以修改 /etc/systemd/journald.conf 中的 SystemMaxUse 來指定該最大限制。

# 查看所有日誌（默認情況下 ，只保存本次啟動的日誌）  $ sudo journalctl    # 查看內核日誌（不顯示應用日誌）：--dmesg 或 -k  $ sudo journalctl -k    # 查看系統本次啟動的日誌（其中包括了內核日誌和各類系統服務的控制台輸出）：--system 或 -b  $ sudo journalctl -b  $ sudo journalctl -b -0    # 查看上一次啟動的日誌（需更改設置）  $ sudo journalctl -b -1    # 查看指定服務的日誌：--unit 或 -u  $ sudo journalctl -u docker.servcie    # 查看指定服務的日誌  $ sudo journalctl /usr/lib/systemd/systemd    # 實時滾動顯示最新日誌  $ sudo journalctl -f    # 查看指定時間的日誌  $ 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 行日誌：--lines 或 -n  $ sudo journalctl -n    # 顯示尾部指定行數的日誌  $ sudo journalctl -n 20    # 將最新的日誌顯示在前面  $ sudo journalctl -r -u docker.service    # 改變輸出的格式：--output 或 -o  $ sudo journalctl -r -u docker.service -o json-pretty    # 查看指定進程的日誌  $ 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

Systemd 工具集

systemctl：用於檢查和控制各種系統服務和資源的狀態
bootctl：用於查看和管理系統啟動分區
hostnamectl：用於查看和修改系統的主機名和主機資訊
journalctl：用於查看系統日誌和各類應用服務日誌
localectl：用於查看和管理系統的地區資訊
loginctl：用於管理系統已登錄用戶和 Session 的資訊
machinectl：用於操作 Systemd 容器
timedatectl：用於查看和管理系統的時間和時區資訊
systemd-analyze 顯示此次系統啟動時運行每個服務所消耗的時間，可以用於分析系統啟動過程中的性能瓶頸
systemd-ask-password：輔助性工具，用星號屏蔽用戶的任意輸入，然後返回實際輸入的內容
systemd-cat：用於將其他命令的輸出重定向到系統日誌
systemd-cgls：遞歸地顯示指定 CGroup 的繼承鏈
systemd-cgtop：顯示系統當前最耗資源的 CGroup 單元
systemd-escape：輔助性工具，用於去除指定字元串中不能作為 Unit 文件名的字元
systemd-hwdb：Systemd 的內部工具，用於更新硬體資料庫
systemd-delta：對比當前系統配置與默認系統配置的差異
systemd-detect-virt：顯示主機的虛擬化類型
systemd-inhibit：用於強制延遲或禁止系統的關閉、睡眠和待機事件
systemd-machine-id-setup：Systemd 的內部工具，用於給 Systemd 容器生成 ID
systemd-notify：Systemd 的內部工具，用於通知服務的狀態變化
systemd-nspawn：用於創建 Systemd 容器
systemd-path：Systemd 的內部工具，用於顯示系統上下文中的各種路徑配置
systemd-run：用於將任意指定的命令包裝成一個臨時的後台服務運行
systemd-stdio- bridge：Systemd 的內部工具，用於將程式的標準輸入輸出重定向到系統匯流排
systemd-tmpfiles：Systemd 的內部工具，用於創建和管理臨時文件目錄
systemd-tty-ask-password-agent：用於響應後台服務進程發出的輸入密碼請求

systemctl

# 重啟系統  $ sudo systemctl reboot    # 關閉系統，切斷電源  $ sudo systemctl poweroff    # CPU停止工作  $ sudo systemctl halt    # 暫停系統  $ sudo systemctl suspend    # 讓系統進入冬眠狀態  $ sudo systemctl hibernate    # 讓系統進入互動式休眠狀態  $ sudo systemctl hybrid-sleep    # 啟動進入救援狀態（單用戶狀態）  $ sudo systemctl rescue

systemd-analyze

# 查看啟動耗時  $ systemd-analyze    # 查看每個服務的啟動耗時  $ systemd-analyze blame    # 顯示瀑布狀的啟動過程流  $ systemd-analyze critical-chain    # 顯示指定服務的啟動流  $ systemd-analyze critical-chain atd.service

hostnamectl

# 顯示當前主機的資訊  $ hostnamectl    # 設置主機名。  $ sudo hostnamectl set-hostname rhel7

timedatectl

# 查看當前時區設置  $ timedatectl    # 顯示所有可用的時區  $ timedatectl list-timezones    # 設置當前時區  $ sudo timedatectl set-timezone America/New_York  $ sudo timedatectl set-time YYYY-MM-DD  $ sudo timedatectl set-time HH:MM:SS

loginctl

# 列出當前 session  $ loginctl list-sessions    # 列出當前登錄用戶  $ loginctl list-users    # 列出顯示指定用戶的資訊  $ loginctl show-user ruanyf

systemd-ask-password

$ PASSWORD=$(systemd-ask-password "Input Your Passowrd:")

systemd-run

systemd-run 可以將一個指定的操作變成後台運行的服務。它的效果似乎與直接在命令後加上表示後台運行的 & 符號很相似。然而，它讓命令成為服務還意味著，它的生命周期將由 Systemd 控制。具體來說，包括以下好處：

服務的生命擊期由 Systemd 接管，不會隨著啟動它的控制台關閉而結束
可以通過 systemctl 工具管理服務的狀態
可以通過 journalctl 工具查看和管理服務的日誌資訊
可以通過 Systemd 提供的方法限制服務的 CPU、記憶體、磁碟 IO 等系統資源的使用情況。

來源：Mallux Blog 原文：https://tinyurl.com/yyp6jbta 題圖：來自Google圖片搜索 版權：本文版權歸原作者所有 投稿：歡迎投稿，郵箱: [email protected]