CentOS 6和之前版本采用SysVinit的系統啟動進程管理體系，一般用戶都可通過在/etc/inittab文件的配置，來個性化自己的系統啟動序列。但也經常會由於特殊環境的硬件等關系問題，造成其串行的啟動進程控制流，因為可能任務的阻塞而影響啟動過程。
CentOS 7開始使用SystemD,所以我們必須要了解SystemD.
詳細介紹請參閱: RedHat 產品文檔
使用systemd管理服務: Chapter 6. Managing Services with systemd
一、 SystemD起源
SystemD是Linux下的一種init軟件，由Lennart Poettering帶頭開發，並在LGPL 2.1及其後續版本許可證下開源發布。Lennart是redhat員工，但SystemD不是redhat項目。其開發目標是提供更優秀的框架以表示系統服務間的依賴關系，並依此實現系統初始化時服務的並行啟動，同時達到降低Shell的系統開銷的效果，最終代替現在常用的System V與BSD風格init程序。
SystemD這一名字源於Unix中的一個慣例：在Unix中常以“d”作為系統守護進程（英語：daemon，亦稱後台進程）的後綴標識。除此以外，SystemD亦是借代英文術語D體系，而這一術語即是用於描述一個人具有快速地適應環境並解決困難的能力。
SystemD被設計用來改進SysVinit的缺點，與Ubuntu的upstart形成技術競爭。SystemD的很多概念來源於蘋果的launchd。目標是盡可能啟動更少進程；盡可能將更多進程並行啟動（這是性能優於SysVinit的理念基礎）。SystemD盡可能減少對Shell腳本的依賴。傳統SysVinit使用inittab來決定運行哪些Shell腳本，大量使用Shell腳本被認為是效率低下無法並行的原因。SystemD使用了Linux專屬技術，不再顧及POSIX兼容，只要能滿足社會變革的需要，突破一些可能過時的技術約束，這也是當今創信理念的需要，相信市場會給出評判。
與多數發行版使用的System V風格init相比，SystemD采用了以下新技術：
● 采用Socket激活式與總線激活式服務，以提高相互依賴的各服務的並行運行性能；
● 用cgroups代替PID來追蹤進程，因此即使是兩次fork之後生成的守護進程也不會脫離systemd的控制。
從設計構思上說，由於SystemD使用了cgroup與fanotify等組件以實現其特性，所以只適用於Linux。有鑒於此，基於kFreeBSD分支的軟件源無法納入SystemD。
Linux 引導方式systemd upstart sysV http://www.linuxidc.com/Linux/2014-01/95555.htm
為什麼systemd會被如此迅速的采用？ http://www.linuxidc.com/Linux/2014-08/105789.htm
systemd 與 sysVinit 彩版對照表 http://www.linuxidc.com/Linux/2014-09/106455.htm
Linux Systemd——在RHEL/CentOS 7中啟動/停止/重啟服務 http://www.linuxidc.com/Linux/2014-08/105975.htm
太有用了！用systemd命令來管理Linux系統！ http://www.linuxidc.com/Linux/2014-09/106490.htm
二、 SystemD 的工具
用SystemD初始化工具（init tool）來啟動系統。SystemD 含了自己的配置和診斷工具，在使用它處理系統啟動問題時用到的技巧不同於SysVinit。
SystemD初始化工具雖面世不久，卻已成為一些發行版中默認使用的初始化工具；一些其他的發行版把它包含進來，作為upstart和SysVinit的替代品。由於它與upstart和SysVinit的兼容特性，在使用這兩個初始化工具的發行版裡面熟悉的命令與技巧也適用於SystemD。但是，為了能夠真正利用好這個新的初始化系統的功能，系統管理員也需要了解SystemD的工具與參數。
給SystemD傳達命令的主要工具是systemctl，它是一個命令行程序。該工具在改變配置文件或重新啟動後台程序時需要root權限，但即使是非root用戶也能下達一些診斷的命令。如果在啟動該命令時不加任何參數，會看到一個系統啟動時執行任務的“單位（unit）”列表，包括掛載及檢測磁盤、啟動後台服務及配置硬件。
服務（service）單位是最重要的一類單位之一，因它管理著後台服務，而在使用SysVinit的發行版裡則一般使用初始化腳本來啟動這些服務。
掛載（mount）與自動掛載（automount）單位用來掛載文件系統。
套接字（socket）單位用來創建套接字，並在訪問套接字後，立即利用依賴關系間接地啟動另一單位。
可使用參數讓systemctl只列出某個類型的單位，如所有的服務單位：
systemctl –type=service
SystemD自動將其輸出結果遞交給less顯示,列表中:
第一欄是單位的名字;
第二欄則表示該單位的定義是否已由SystemD正確加載。
第三欄則為該單位是否正在運行。如果使用了-a參數，那麼該程序將僅顯示非正在運行的單位，即已安裝但並未在啟動時使用的單位，同時也包含引導系統未能正常加載的單位文件。
第四欄則給出了當前狀態：“exited”表示該進程已經無任何錯誤地完成，這種情況適用於,諸如進程在啟動後並不在後台繼續運行的情況，例如，在系統啟動時由於考慮到兼容性因素執行在SysVinit裡面常用的/etc/rc.d/rc.local文件的服務單位。“Running”表示正在後台運行的服務，如cron、dbus、sshd和udev。
第五欄是對該單位的描述。標有“LSB”或“SYSV”的單位已由systemd自動創建以管理傳統啟動腳本。
不能啟動或啟動後崩潰的服務在第四欄中用紅色標為“failed”。可用如下命令來察看該服務是何時崩潰的以及在服務程序結束後提供了什麼錯誤代碼：
systemctl status ntpd.service
systemctl會列出包含文本終端的登錄進程（agetty）的服務型單位。因為SystemD不同於Sysvinit，它會像管理普通的後台服務一樣以服務單位的形式對這些進程進行管理。
1. SystemD服務管理
systemctl is-enabled .service #查詢服務是否開機啟動
sudo systemctl enable .service #開機運行服務
sudo systemctl disable .service #取消開機運行
sudo systemctl start .service #啟動服務
sudo systemctl stop .service #停止服務
sudo systemctl restart .service #重啟服務
sudo systemctl reload .service #重新加載服務配置文件
systemctl status .service #查詢服務運行狀態
systemctl –failed #顯示啟動失敗的服務
2. 開機模塊加載
/etc/modules-load.d/.conf，相當於原rc.conf中的MODULES變量
模塊黑名單仍在/etc/modprobe.d/下，如blacklist.conf:
3. Locale
/etc/locale.conf，相當於原rc.conf中的LOCALE
4. 日志服務
systemd自帶日志服務，參考systemd Journal
可以刪除syslog-ng了
5. 主機名
/etc/hostname，相當於原來rc.conf中的HOSTNAME變量
6. 網絡
還是用NetworkManager工具
更多詳情見請繼續閱讀下一頁的精彩內容： http://www.linuxidc.com/Linux/2014-11/109232p2.htm
