保存nginx.conf文件，輸入cd ..，回到/usr/local/nginx/sbin目錄下輸入./nginx啟動(dòng)nginx服務(wù)。輸入ps –ef |grep nginx查看運(yùn)行的進(jìn)程。

運(yùn)行nginx：./nginx

重啟nginx：./nginx -s reload

停止nginx：./nginx -s stop

輸入netstat –ntlp | grep nginx查看nginx的通信端口。

輸入wget htt:\\10.190.130.78:8007就測(cè)試到配置是否成功。

2.6.在Firewall啟動(dòng)狀態(tài)下運(yùn)行Nginx

在Firewall啟動(dòng)的情況下，其他客戶端無法訪問到htt:\\10.190.130.78:8007。

輸入netstat -ntlp | grep nginx查看nginx的占用端口

在其他客戶端中輸入wget http://10.190.130.78:8007就可以訪問成功。

3.設(shè)置自定義開機(jī)系統(tǒng)服務(wù)

CentOS 7 使用systemd替換了SysV。Systemd目的是要取代Unix時(shí)代以來一直在使用的init系統(tǒng)，兼容SysV和LSB的啟動(dòng)腳本，而且夠在進(jìn)程啟動(dòng)過程中

更有效地引導(dǎo)加載服務(wù)。

systemd的特性有：

支持并行化任務(wù)

同時(shí)采用socket式與D-Bus總線式激活服務(wù)；

按需啟動(dòng)守護(hù)進(jìn)程（daemon）；

利用 Linux 的 cgroups 監(jiān)視進(jìn)程；

支持快照和系統(tǒng)恢復(fù)；

維護(hù)掛載點(diǎn)和自動(dòng)掛載點(diǎn)；

各服務(wù)間基于依賴關(guān)系進(jìn)行精密控制。

 

檢視和控制systemd的主要命令是systemctl。該命令可用于查看系統(tǒng)狀態(tài)和管理系統(tǒng)及服務(wù)。詳見man 1 systemctl。

輸入vim /usr/lib/systemd/system/nginx.service進(jìn)入文件編輯。

將以下內(nèi)容拷貝到nginx.service文件中，然后保存。

[Unit]

Description=nginx servicedaemon

After=network.target

[Service]

Type=forking

PIDFile=/usr/local/nginx/logs/nginx.pid  #nginx安裝路徑下的nginx.pid文件

ExecStart=/usr/local/nginx/sbin/nginx

ExecReload=/usr/local/nginx/sbin/nginx-s reload

ExecStop=/usr/local/nginx/sbin/nginx-s stop

PrivateTep=true

[Install]

WantedBy=multi-user.target

保存文件后，啟動(dòng)nginx服務(wù)器會(huì)出現(xiàn)錯(cuò)誤。必須要輸入systemctl daemon-reload，重載后臺(tái)服務(wù)。

輸入systemctl daemon-reload，重載后臺(tái)服務(wù)?？梢允褂胹ystemctl命令對(duì)nginx進(jìn)行操作

如果需要更詳細(xì)的配置，請(qǐng)參考：

https://www./software/systemd/man/systemd.service.html

使用單元

一個(gè)單元配置文件可以描述如下內(nèi)容之一：系統(tǒng)服務(wù)（.service）、掛載點(diǎn)（.mount）、sockets（.sockets）、系統(tǒng)設(shè)備（.device）、交換分區(qū)（.swap）、文件路徑（.path）、啟動(dòng)目標(biāo)（.target）、由 systemd 管理的計(jì)時(shí)器（.timer）。詳情參閱 man 5 systemd.unit。

使用 systemctl 控制單元時(shí)，通常需要使用單元文件的全名，包括擴(kuò)展名（例如 sshd.service）。但是有些單元可以在systemctl中使用簡(jiǎn)寫方式。

如果無擴(kuò)展名，systemctl 默認(rèn)把擴(kuò)展名當(dāng)作 .service。例如 netcfg 和 netcfg.service 是等價(jià)的。

掛載點(diǎn)會(huì)自動(dòng)轉(zhuǎn)化為相應(yīng)的 .mount 單元。例如 /home 等價(jià)于 home.mount。

設(shè)備會(huì)自動(dòng)轉(zhuǎn)化為相應(yīng)的 .device 單元，所以 /dev/sda2 等價(jià)于 dev-sda2.device。

注: 有一些單元的名稱包含一個(gè) @ 標(biāo)記， (e.g. name@string.service): 這意味著它是模板單元name@.service 的一個(gè)實(shí)例。 string 被稱作實(shí)例標(biāo)識(shí)符, 在 systemctl 調(diào)用模板單元時(shí)，會(huì)將其當(dāng)作一個(gè)參數(shù)傳給模板單元，模板單元會(huì)使用這個(gè)傳入的參數(shù)代替模板中的 %I 指示符。在實(shí)例化之前，systemd 會(huì)先檢查 name@string.suffix 文件是否存在（如果存在，應(yīng)該就是直接使用這個(gè)文件，而不是模板實(shí)例化了）。大多數(shù)情況下，包換 @ 標(biāo)記都意味著這個(gè)文件是模板。如果一個(gè)模板單元沒有實(shí)例化就調(diào)用，該調(diào)用會(huì)返回失敗，因?yàn)槟０鍐卧械? %I 指示符沒有被替換。

例如：systemctl start <單元>

編寫單元文件

systemd單元文件的語法來源于 XDG桌面入口配置文件.desktop文件，最初的源頭則是MicrosoftWindows的.ini文件。單元文件可以從兩個(gè)地方加載，優(yōu)先級(jí)從低到高分別是：

/usr/lib/systemd/system/: 軟件包安裝的單元

/etc/systemd/system/: 系統(tǒng)管理員安裝的單元

注意: 當(dāng)systemd運(yùn)行在用戶模式下時(shí)，使用的加載路徑是完全不同的。

處理依賴關(guān)系

使用systemd時(shí)，可通過正確編寫單元配置文件來解決其依賴關(guān)系。典型的情況是，單元A要求單元B在A啟動(dòng)之前運(yùn)行。在此情況下，向單元A配置文件中的 [Unit] 段添加 Requires=B 和 After=B 即可。若此依賴關(guān)系是可選的，可添加 Wants=B 和 After=B。請(qǐng)注意 Wants= 和 Requires= 并不意味著 After=，即如果 After= 選項(xiàng)沒有制定，這兩個(gè)單元將被并行啟動(dòng)。

依賴關(guān)系通常被用在服務(wù)（service）而不是目標(biāo)（target）上。例如， network.target 一般會(huì)被某個(gè)配置網(wǎng)絡(luò)接口的服務(wù)引入，所以，將自定義的單元排在該服務(wù)之后即可，因?yàn)?network.target 已經(jīng)啟動(dòng)。

服務(wù)類型

編寫自定義的 service 文件時(shí)，可以選擇幾種不同的服務(wù)啟動(dòng)方式。啟動(dòng)方式可通過配置文件 [Service] 段中的 Type= 參數(shù)進(jìn)行設(shè)置。

Type=simple（默認(rèn)值）：systemd認(rèn)為該服務(wù)將立即啟動(dòng)。服務(wù)進(jìn)程不會(huì)fork。如果該服務(wù)要啟動(dòng)其他服務(wù)，不要使用此類型啟動(dòng)，除非該服務(wù)是socket激活型。

Type=forking：systemd認(rèn)為當(dāng)該服務(wù)進(jìn)程fork，且父進(jìn)程退出后服務(wù)啟動(dòng)成功。對(duì)于常規(guī)的守護(hù)進(jìn)程（daemon），除非你確定此啟動(dòng)方式無法滿足需求，使用此類型啟動(dòng)即可。使用此啟動(dòng)類型應(yīng)同時(shí)指定 PIDFile=，以便systemd能夠跟蹤服務(wù)的主進(jìn)程。

Type=oneshot：這一選項(xiàng)適用于只執(zhí)行一項(xiàng)任務(wù)、隨后立即退出的服務(wù)?？赡苄枰瑫r(shí)設(shè)置 RemainAfterExit=yes 使得 systemd 在服務(wù)進(jìn)程退出之后仍然認(rèn)為服務(wù)處于激活狀態(tài)。

Type=notify：與 Type=simple 相同，但約定服務(wù)會(huì)在就緒后向 systemd 發(fā)送一個(gè)信號(hào)。這一通知的實(shí)現(xiàn)由 libsystemd-daemon.so 提供。

Type=dbus：若以此方式啟動(dòng)，當(dāng)指定的 BusName出現(xiàn)在DBus系統(tǒng)總線上時(shí)，systemd認(rèn)為服務(wù)就緒。

Type=idle: systemd會(huì)等待所有任務(wù)(Jobs)處理完成后，才開始執(zhí)行idle類型的單元。除此之外，其他行為和Type=simple 類似。

type的更多解釋可以參考systemd.service(5)。

3.1.設(shè)置開機(jī)服務(wù)

輸入systemctl start nginx啟動(dòng)nginx服務(wù)，在輸入systemctl enable nginx 設(shè)置nginx服務(wù)為開機(jī)啟動(dòng)服務(wù)，最后，輸入systemctl status nginx查看nginx的運(yùn)行狀態(tài)。

3.2.停止開機(jī)服務(wù)

輸入systemctl disable nginx停止開機(jī)啟動(dòng)nginx服務(wù)，輸入systemctlstop nginx停止nginx服務(wù)，輸入systemctl status nginx查看nginx的運(yùn)行狀態(tài)。

4.負(fù)載均衡策略

在nginx中支持的負(fù)載均衡策略如下：

輪詢加權(quán)策略（Round-Robin）：在輪詢模策略中，要求應(yīng)用服務(wù)器是分布式的

最少連接策略（Least-Connected）：下一個(gè)請(qǐng)求是分配給最少的活動(dòng)連接數(shù)服務(wù)器。

IP哈希策略（IP-Hash）：一個(gè)哈希函數(shù)用來決定那個(gè)服務(wù)器被選擇作為下一個(gè)請(qǐng)求處理的服務(wù)器（基于客戶端的IP地址）。

4.1.輪詢策略

http {

   upstream myapp1 {           #服務(wù)器組，組名：myapp1

       server srv1.example.com;  #web應(yīng)用服務(wù)器1

       server srv2.example.com;  #web應(yīng)用服務(wù)器2

       server srv3.example.com;  #web應(yīng)用服務(wù)器3

    }

 

   server {

       listen 80;

 

       location / {

           proxy_pass http://myapp1;          #客戶端訪問的URL

       }

    }

}

以上是最簡(jiǎn)單的Nginx負(fù)載均衡配置。在upstream myapp1中有3個(gè)應(yīng)用服務(wù)器實(shí)例，當(dāng)負(fù)載均衡中沒有指定配置負(fù)載策略時(shí)，默認(rèn)是使用輪詢權(quán)重策略。所有請(qǐng)求都是代理給服務(wù)器組myapp1，Nginx應(yīng)用http負(fù)載均衡到分布式請(qǐng)求中。

在Nginx反向代理負(fù)載均衡的擴(kuò)展包括：http，https，F(xiàn)astCGI，uwsgi，SCGI和緩存。

配置負(fù)載均衡

配置https負(fù)載均衡代替http，只使用“https”作為協(xié)議就可以了。

當(dāng)設(shè)置負(fù)載均衡為FastCGI，uwsgi，SCGI，或緩存，指令分別使用fastcgi_pass，uwsgi_pass，scgi_pass，和memcached_pass。

如果可以把加權(quán)輪詢算法分為先深搜索和先廣搜索，那么nginx采用的是先深搜索算法，即將首先將請(qǐng)求都分給高權(quán)重的機(jī)器，直到該機(jī)器的權(quán)值降到了比其他機(jī)器低，才開始將請(qǐng)求分給下一個(gè)高權(quán)重的機(jī)器；第二，當(dāng)所有后端機(jī)器都down掉時(shí)，nginx會(huì)立即將所有機(jī)器的標(biāo)志位清成初始狀態(tài)，以避免造成所有的機(jī)器都處在timeout的狀態(tài)，從而導(dǎo)致整個(gè)前端被夯住。

4.2.最少連接策略

upstream myapp1 {                     #服務(wù)器組，組名：myapp1

       least_conn;                  #least_conn;最少連接策略

       server srv1.example.com;       #web應(yīng)用服務(wù)器1

       server srv2.example.com;       #web應(yīng)用服務(wù)器2

       server srv3.example.com;       #web應(yīng)用服務(wù)器3

}

最少連接允許控制加載應(yīng)用實(shí)例，更多適合在一些花費(fèi)比較長(zhǎng)時(shí)間去完成請(qǐng)求的一個(gè)場(chǎng)景中。

用最少連接負(fù)載均衡，Nginx會(huì)盡量不要求過載繁忙的應(yīng)用服務(wù)器去執(zhí)行請(qǐng)求，分配新的請(qǐng)求給一個(gè)不太忙碌的服務(wù)器代替執(zhí)行。

最少連接負(fù)載均衡在Nginx中被激活時(shí)，least_conn指令被用來作為服務(wù)器群組配置的一個(gè)部分。

4.3.IP哈希策略

配置IP哈希負(fù)載均衡，只需要添加ip_hash指令指向服務(wù)器(uptream) 組配置：

upstream myapp1 {

   ip_hash;

   server srv1.example.com;

   server srv2.example.com;

   server srv3.example.com;

}

每個(gè)客戶端請(qǐng)求都有可能發(fā)送到不同的服務(wù)器，不能保證同一個(gè)客戶端總是指向同一個(gè)服務(wù)器。如果一個(gè)客戶端必須要跟服務(wù)器的會(huì)話關(guān)聯(lián)在一起的時(shí)候，可以使用IP哈希負(fù)載均衡緩存策略。

通過獲取客戶端額IP地址，經(jīng)過哈希函數(shù)的計(jì)算得到一個(gè)值，利用該值對(duì)服務(wù)器的列表大小進(jìn)行取模運(yùn)算，得到的值就是處理客戶端請(qǐng)求的服務(wù)器序號(hào)。采用IP哈希負(fù)載均衡策略，的優(yōu)點(diǎn)是，同一個(gè)客戶端的IP地址，每次發(fā)送的請(qǐng)求都是指向同一臺(tái)服務(wù)器進(jìn)行處理。這種方式確保來自同一個(gè)客戶端請(qǐng)求總是指向同一個(gè)服務(wù)器除非這個(gè)服務(wù)是無效的。

舉例子說明：

例如一個(gè)系統(tǒng)的會(huì)話存儲(chǔ)用戶信息，每次將請(qǐng)求發(fā)送到服務(wù)器，服務(wù)器都會(huì)從會(huì)話中獲取數(shù)據(jù)。但在負(fù)載均衡環(huán)境中，每次客戶端的每次請(qǐng)求都可能由不同的服務(wù)器處理，所以可能出現(xiàn)無法獲取的到客戶端的會(huì)話數(shù)據(jù)（由于會(huì)話數(shù)據(jù)是保存在服務(wù)器的內(nèi)存中）。

4.4.權(quán)重策略

使用服務(wù)器權(quán)重策略，它也有可能影響到Nginx負(fù)載均衡算法。

在上面的例子中，服務(wù)器權(quán)重沒有配置，意味著所有指定的服務(wù)器都被視為同等資格的一個(gè)特定負(fù)載均衡策略。尤其是輪詢策略，它也意味著差不多平等地分配請(qǐng)求給服務(wù)器，并且快速平均地處理請(qǐng)求。

 

當(dāng)權(quán)重參數(shù)被指定在一個(gè)服務(wù)器時(shí)，權(quán)重作為負(fù)載均衡決策的部分。

upstream myapp1 {

       server srv1.example.com weight=3;

       server srv2.example.com;

       server srv3.example.com;

}

在這個(gè)配置中，每5個(gè)請(qǐng)求都分配給應(yīng)用服務(wù)器實(shí)例如下：

3個(gè)請(qǐng)求將分配到serv1中，1個(gè)請(qǐng)求分配給srv2中，而另外1個(gè)請(qǐng)求則分配個(gè)srv3中。

在最近的Nginx版本中，它同樣可以與最少連接和IP哈希策略一樣去使用權(quán)重策略。

4.5.總結(jié)

輪詢策略：

優(yōu)點(diǎn)：如果希望每個(gè)服務(wù)器都能平均處理客戶端請(qǐng)求可使用輪詢策略。

缺點(diǎn)：不支持會(huì)話管理，另外，假設(shè)有5個(gè)客戶端請(qǐng)求，有2臺(tái)服務(wù)器處理請(qǐng)求，某一臺(tái)服務(wù)器處理請(qǐng)求時(shí)消耗資源比較大，每次都接到消耗資源比較大的請(qǐng)求，那么該服務(wù)器處理能力就會(huì)下降。

 

IP哈希策略：

缺點(diǎn)：使用該策略，服務(wù)器可能不會(huì)平均處理每個(gè)請(qǐng)求。假設(shè)有5個(gè)客戶端請(qǐng)求，那么通過計(jì)算出哈希值后，可能都是由一臺(tái)服務(wù)器處理。其它的服務(wù)器可能沒有請(qǐng)求需要處理。

優(yōu)點(diǎn)：支持會(huì)話管理，如果系統(tǒng)中使用會(huì)話處理數(shù)據(jù)，該策略比較適合。

 

最少連接策略：

優(yōu)點(diǎn)：系統(tǒng)把新連接分配給當(dāng)前連接數(shù)目最少的服務(wù)器。該算法在各個(gè)服務(wù)器運(yùn)算能力基本相似的環(huán)境中非常有效。此負(fù)載均衡策略適合請(qǐng)求處理時(shí)間長(zhǎng)短不一造成服務(wù)器過載的情況。

缺點(diǎn)：雖然某個(gè)服務(wù)器的連接數(shù)較少，但處理請(qǐng)求時(shí)間較長(zhǎng)，這時(shí)候再接受請(qǐng)求處理，可能影響到時(shí)間效率的問題。

 

權(quán)重策略：

優(yōu)點(diǎn)：如果服務(wù)器的硬件等級(jí)差別比較大，那么配置高的服務(wù)器可分配較高權(quán)重，以便處理更多的請(qǐng)求。而配置低的服務(wù)器可接受少量請(qǐng)求。

缺點(diǎn)：如果服務(wù)器的硬件等級(jí)一樣不太適合使用該策略。

5.健康檢查

在Nginx反向代理中實(shí)現(xiàn)主動(dòng)或被動(dòng)健康檢查，如果指定的響應(yīng)服務(wù)器出現(xiàn)錯(cuò)誤，Nginx將標(biāo)記該服務(wù)器為失敗，將盡量去避免為后續(xù)的請(qǐng)求選擇該服務(wù)器。

設(shè)置發(fā)生在超時(shí)失敗期間連續(xù)不成功的服務(wù)器通信的max_fails指令。默認(rèn)max_fails設(shè)置是1，當(dāng)設(shè)置為0次時(shí)，這臺(tái)服務(wù)器的檢查檢查不啟用。Fail_timeout參數(shù)定義服務(wù)器多長(zhǎng)時(shí)間將被標(biāo)記為失敗。在服務(wù)器fail_timeout期間，Nginx不會(huì)馬上將該服務(wù)器標(biāo)記為失敗的服務(wù)器，而是模擬想客戶端請(qǐng)求去偵查服務(wù)器，如果偵查成功，該服務(wù)器標(biāo)記為在線服務(wù)器。

關(guān)于健康檢查的的插件需要花錢購(gòu)買，更多的信息請(qǐng)參考：

https://www./products/application-health-checks/

https://www./resources/admin-guide/installing-nginx-plus/

6.附錄

6.1.systemctl命令指南

Systemctl是一個(gè)systemd工具，主要負(fù)責(zé)控制systemd系統(tǒng)和服務(wù)管理器。

Systemd是一個(gè)系統(tǒng)管理守護(hù)進(jìn)程、工具和庫(kù)的集合，用于取代System V初始進(jìn)程。Systemd的功能是用于集中管理和配置類UNIX系統(tǒng)。

在Linux生態(tài)系統(tǒng)中，Systemd被部署到了大多數(shù)的標(biāo)準(zhǔn)Linux發(fā)行版中，只有為數(shù)不多的幾個(gè)發(fā)行版尚未部署。Systemd通常是所有其它守護(hù)進(jìn)程的父進(jìn)程，

但并非總是如此。使用Systemctl管理Linux服務(wù)

6.1.1.Systemd初體驗(yàn)和Systemctl基礎(chǔ)

6.1.1.1.1.檢查systemd安裝版本

1. 首先檢查你的系統(tǒng)中是否安裝有systemd并確定當(dāng)前安裝的版本

# systemd –version

6.1.1.1.2.檢查systemd和systemctl的二進(jìn)制文件和庫(kù)文件的安裝位置

# whereis system

# whereis systemctl

6.1.1.1.3檢查systemd是否運(yùn)行

# ps -eaf | grep system

6.1.1.4.分析systemd啟動(dòng)進(jìn)程

# systemd-analyze

6.1.1.5.分析啟動(dòng)時(shí)各個(gè)進(jìn)程花費(fèi)的時(shí)間

#systemd-analyze blame

6.1.1.6.分析啟動(dòng)時(shí)的關(guān)鍵鏈

# systemd-analyze critical-chain

重要：Systemctl接受服務(wù)（.service），掛載點(diǎn)（.mount），套接口（.socket）和設(shè)備（.device）作為單元。

Systemctl是一個(gè)systemd工具，主要負(fù)責(zé)控制systemd系統(tǒng)和服務(wù)管理器。

Systemd是一個(gè)系統(tǒng)管理守護(hù)進(jìn)程、工具和庫(kù)的集合，用于取代System V初始進(jìn)程。Systemd的功能是用于集中管理和配置類UNIX系統(tǒng)。

在Linux生態(tài)系統(tǒng)中，Systemd被部署到了大多數(shù)的標(biāo)準(zhǔn)Linux發(fā)行版中，只有為數(shù)不多的幾個(gè)發(fā)行版尚未部署。Systemd通常是所有其它守護(hù)進(jìn)程的父進(jìn)程，

但并非總是如此。

使用Systemctl管理Linux服務(wù)

本文旨在闡明在運(yùn)行systemd的系統(tǒng)上“如何控制系統(tǒng)和服務(wù)”。

Systemd初體驗(yàn)和Systemctl基礎(chǔ)

1. 首先檢查你的系統(tǒng)中是否安裝有systemd并確定當(dāng)前安裝的版本

# systemd--version
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP-APPARMOR

上例中很清楚地表明，我們安裝了215版本的systemd。

2. 檢查systemd和systemctl的二進(jìn)制文件和庫(kù)文件的安裝位置

# whereissystemd
systemd:/usr/lib/systemd /etc/systemd /usr/share/systemd/usr/share/man/man1/systemd.1.gz
# whereis systemctl
systemctl:/usr/bin/systemctl /usr/share/man/man1/systemctl.1.gz

3. 檢查systemd是否運(yùn)行

# ps -eaf | grep[s]ystemd
root 10016:27?00:00:00/usr/lib/systemd/systemd --switched-root --system--deserialize 23
root 4441016:27?00:00:00/usr/lib/systemd/systemd-journald
root 4691016:27?00:00:00/usr/lib/systemd/systemd-udevd
root 5551016:27?00:00:00/usr/lib/systemd/systemd-logind
dbus 5561016:27?00:00:00/bin/dbus-daemon --system --address=systemd:--nofork--nopidfile --systemd-activation

注意：systemd是作為父進(jìn)程（PID=1）運(yùn)行的。在上面帶（-e）參數(shù)的ps命令輸出中，選擇所有進(jìn)程，（-a）選擇除會(huì)話前導(dǎo)外的所有進(jìn)程，并使用（-f）參數(shù)輸出完整格式列表（即 -eaf）。

也請(qǐng)注意上例中后隨的方括號(hào)和例子中剩余部分。方括號(hào)表達(dá)式是grep的字符類表達(dá)式的一部分。

4. 分析systemd啟動(dòng)進(jìn)程

#systemd-analyze
Startup finished in487ms(kernel)+2.776s(initrd)+20.229s(userspace)=23.493s

5. 分析啟動(dòng)時(shí)各個(gè)進(jìn)程花費(fèi)的時(shí)間

#systemd-analyze blame
8.565s mariadb.service
7.991s webmin.service
6.095s postfix.service
4.311s httpd.service
3.926s firewalld.service
3.780s kdump.service
3.238s tuned.service
1.712s network.service
1.394s lvm2-monitor.service
1.126s systemd-logind.service
....

6. 分析啟動(dòng)時(shí)的關(guān)鍵鏈

#systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@"character.
The time the unit takes to start is printed after the "+" character.
multi-user.target @20.222s
└─mariadb.service @11.657s+8.565s
└─network.target @11.168s
└─network.service @9.456s+1.712s
└─NetworkManager.service @8.858s+596ms
└─firewalld.service @4.931s+3.926s
└─basic.target @4.916s
└─sockets.target @4.916s
└─dbus.socket @4.916s
└─sysinit.target @4.905s
└─systemd-update-utmp.service @4.864s+39ms
└─auditd.service @4.563s+301ms
└─systemd-tmpfiles-setup.service @4.485s+69ms
└─rhel-import-state.service @4.342s+142ms
└─local-fs.target @4.324s
└─boot.mount @4.286s+31ms
└─systemd-fsck@dev-disk-by\x2duuid-79f594ad\x2da332\x2d4730\x2dbb5f\x2d85d19608096
└─dev-disk-by\x2duuid-79f594ad\x2da332\x2d4730\x2dbb5f\x2d85d196080964.device@4

重要：Systemctl接受服務(wù)（.service），掛載點(diǎn)（.mount），套接口（.socket）和設(shè)備（.device）作為單元。

6.1.1.7.列出所有可用單元

# systemctl list-unit-files

6.1.1.8.列出所有運(yùn)行中單元

# systemctl list-units

6.1.1.9.列出所有失敗單元

# systemctl –failed

6.1.1.10.檢查某個(gè)單元是否啟用

# systemctl is-enabled nginx.service 

6.1.1.11.檢查某個(gè)單元或服務(wù)是否運(yùn)行

# systemctl status nginx.service