Init

Upstart 和 systemd 的優缺點是什麼?

  • March 6, 2021

看來systemd是目前最熱門的新init系統,就像幾年前的Upstart一樣。每個的優點/缺點是什麼?另外,每個與其他初始化系統相比如何?

2016 更新

這裡的大多數答案都是五年前的,所以是時候進行一些更新了。

Ubuntu 過去預設使用 upstart,但去年他們放棄了它,轉而使用 systemd - 請參閱:

因此,Ubuntu wiki 上有一篇很好的文章Systemd for Upstart Users - upstart 和 systemd 之間的非常詳細的比較以及從 upstart 到 systemd 的轉換指南。

(請注意,根據 Ubuntu wiki,預設情況下,您仍然可以通過安裝upstart-sysv和執行在目前版本的 Ubuntu 上執行 upstart,sudo update-initramfs -u但考慮到 systemd 項目的範圍,我不知道它在實踐中是如何工作的,或者 systemd 是否是可以解除安裝。)

下面的命令和腳本部分中的大部分資訊都改編自該文章中使用的一些範例(就像 Stack Exchange 使用者在Creative Commons Attribution-ShareAlike 3.0 License下的貢獻一樣方便地獲得許可)。

這裡是常用命令和簡單腳本的快速比較,詳細解釋見下文。如問題中所述,此答案是將基於 Upstart 的系統的舊行為與基於 systemd 的系統的新行為進行比較,但請注意,標記為“Upstart”的命令不一定是特定於 Upstart 的 - 它們通常是對於每個非系統化的 Linux 和 Unix 系統都是通用的。

命令

執行蘇:

  • 暴發戶: su
  • 系統: machinectl shell

(參見下面的“su 命令替換”部分)

執行畫面:

  • 暴發戶: screen
  • 系統: systemd-run --user --scope screen

(請參閱下面的“意外終止後台程序”部分)

執行 tmux:

  • 暴發戶: tmux
  • 系統: systemd-run --user --scope tmux

(請參閱下面的“意外終止後台程序”部分)

開始工作 foo:

  • 暴發戶: start foo
  • 系統: systemctl start foo

停止工作 foo:

  • 暴發戶: stop foo
  • 系統: systemctl stop foo

重新啟動作業 foo:

  • 暴發戶: restart foo
  • 系統: systemctl restart foo

列出工作:

  • 暴發戶: initctl list
  • 系統: systemctl status

檢查作業 foo 的配置:

  • 暴發戶: init-checkconf /etc/init/foo.conf
  • 系統: systemd-analyze verify /lib/systemd/system/foo.service

列出作業的環境變數:

  • 暴發戶: initctl list-env
  • 系統: systemctl show-environment

設置作業的環境變數:

  • 暴發戶: initctl set-env foo=bar
  • 系統: systemctl set-environment foo=bar

刪除作業的環境變數:

  • 暴發戶: initctl unset-env foo
  • 系統: systemctl unset-environment foo

日誌

在 upstart 中,日誌是 /var/log/upstart 目錄中的普通文本文件,因此您可以照常處理它們:

cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log

在 systemd 中,日誌以內部二進制格式(而不是文本文件)儲存,因此您需要使用journalctl命令來訪問它們:

sudo journalctl -u foo
sudo journalctl -u foo -f

腳本

用以下方式編寫的範例暴發戶腳本/etc/init/foo.conf

description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir

用以下方式編寫的範例systemd 腳本/lib/systemd/system/foo.service

[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target

su 命令替換

supull request #1022 中將命令替換合併到 systemd 中:

因為,根據 Lennart Poettering 的說法,“su 確實是一個破碎的概念”

他解釋說“你可以像以前一樣使用 su 和 sudo,但不要指望它會完全起作用

現在實現類似su行為的官方方法是:

machinectl shell

Lennart Poettering在對問題 #825 的討論中進一步 解釋了這一點:

“嗯,這件事已經討論了很長時間,但問題是甦應該做什麼還很不清楚。

$$ … $$ 長話短說: su 真的是一個破碎的概念。它會給你一種外殼,可以使用它,但它不是一個完整的登錄,不應該被誤認為是一個。” - Lennart Poettering

也可以看看:

意外殺死後台程序

類似的命令:

不再按預期工作。例如,nohup是一個 POSIX 命令,用於確保在您從會話中註銷後程序繼續執行。它不再適用於 systemd。此外,需要以特殊方式呼叫類似screentmux需要的程序,否則與它們一起執行的程序將被殺死(而沒有殺死這些程序通常是首先執行 screen 或 tmux 的主要原因)。

這不是一個錯誤,這是一個深思熟慮的決定,因此將來不太可能修復。這就是 Lennart Poettering關於這個問題的說法:

在我看來,UNIX 實際上很奇怪,它預設讓任意使用者程式碼在註銷後不受限制地保留。許多作業系統人員已經討論了很長時間,這應該是可能的,但肯定不是預設設置,但到目前為止沒有人敢於翻轉開關以將其從預設設置變為選項。註銷後不清理使用者會話不僅醜陋且有些駭人聽聞,而且還是一個安全問題。 systemd 230 現在終於打開了開關,最後預設情況下在使用者註銷時正確清理所有內容。

有關更多資訊,請參閱:

高水平的創業理念

在某種程度上,systemd 是向後工作的——在新貴的工作中,他們會盡快開始,而在 systemd 的工作中,他們會在必須的時候開始。歸根結底,兩個系統可以以幾乎相同的順序啟動相同的工作,但是您可以從相反的方向考慮它。

以下是Systemd for Upstart 使用者的解釋:

Upstart啟動程序(作業)的模型是“基於貪婪事件的”,即所有發生啟動事件的可用作業都盡可能早地啟動。在啟動過程中,upstart 將一些初始事件(如啟動或 rcS)合成為“樹根”,早期服務在這些事件上啟動,而後來的服務在前者執行時啟動。新作業只需將其配置文件安裝到 /etc/init/ 即可啟動。

systemd啟動程序(單元)的模型是“基於惰性依賴的”,即一個單元只有在其他啟動單元依賴於它時才會啟動。在引導期間,systemd 啟動一個“根單元”(default.target,可以在 grub 中覆蓋),然後傳遞擴展並啟動其依賴項。一個新的單元需要添加自己作為引導序列單元(通常是 multi-user.target)的依賴項才能啟動。

在發行版中的使用

現在根據維基百科的一些最新數據:

預設使用 upstart 的發行版:

預設使用 systemd 的發行版:

(有關最新資訊,請參閱維基百科)

既不使用 Upstart 也不使用 systemd 的發行版:

爭議

過去,有人提議使用 Debian 的一個分支來避免 systemd。創建了Devuan GNU+Linux - 一個沒有 systemd 的 Debian 分支(感謝fpmurphy1在評論中指出)。

有關此爭議的更多資訊,請參閱:

正如你們中的許多人可能已經知道的那樣,Ian Jackson 推動的 Init GR Debian 投票對於保護 Debian 的遺產及其使用者免受 systemd 雪崩的影響沒有用處。

這種情況預示著系統依賴關係的鎖定,這實際上威脅到開發自由,並對 Debian 及其上游和下游產生嚴重後果。

CTTE 設法交換了一個依賴項,並為我們贏得了通過 sysvinit 微妙地安裝 systemd 的時間,但即使是這個過程也令人筋疲力盡並且充滿了戲劇性。最終,一周前,伊恩·傑克遜辭職了。

$$ … $$

我立即從技術委員會辭職。

雖然同意我的 30-40% 的項目的觀點應該繼續在 TC 上得到代表是很重要的,但在這一點上,我自己顯然是一個太有爭議的人物。我應該靠邊站,盡量減少有關項目治理的對話的個性化程度。

$$ … $$

Devuan 的誕生源於關於使用 Debian 的預設初始化系統的決定的爭議。Debian 在 systemd 上的官方立場充滿了其他人已經揭穿的聲明。感興趣的讀者可以在The systemd 的爭議中繼續討論這個熱門話題。但是,我們鼓勵您保持頭腦冷靜,聲音文明。在 Devuan,我們對錯誤程式比回顧更感興趣。

$$ … $$

創建了一些專門針對 systemd 爭議的網站和文章:

Hacker News上有很多有趣的討論:

在其他發行版中也可以觀察到類似的趨勢:

哲學

upstart遵循 DOTADIW 的 Unix 哲學——“做一件事,把它做好”。它是傳統初始化守護程序的替代品。除了啟動和停止服務之外,它不做任何事情。其他任務被委託給其他專門的子系統。

systemd做的遠不止這些。除了啟動和停止服務之外,它還管理密碼、登錄名、終端、電源管理、出廠重置、日誌處理、文件系統掛載點、網路等等 - 請參閱NEWS文件了解一些功能。

擴張計劃

根據2014 年 Lennart Poettering 在 GNOME.asia 上的A Perspective for systemd 已取得的成就和未來的發展,以下是 systemd 的主要目標、已經涵蓋的領域和仍在進行中的領域:

系統目標:

我們的目標

  • 將 Linux 從一堆比特變成具有競爭力的通用作業系統。
  • 建構網際網路的下一代作業系統 統一發行版之間毫無意義的差異
  • 將創新帶回核心作業系統
  • 桌面、伺服器、容器、嵌入式、移動、雲、集群、. . . 這些區域比你想像的更接近
  • 無需監督即可降低管理員複雜性和可靠性
  • 一切自省
  • 自動發現、即插即用是關鍵
  • 我們修理壞了的東西,從不把膠帶粘在上面

已經涵蓋的領域:

我們已經涵蓋的內容:

初始化系統、日誌記錄、登錄管理、設備管理、臨時和易失文件管理、二進制格式註冊、背光保存/恢復、rfkill 保存/恢復、引導圖、預讀、加密儲存設置、EFI/GPT 分區發現、虛擬機/容器註冊、最小容器管理、主機名管理、語言環境管理、時間管理、隨機種子管理、sysctl 變數管理、控制台管理、. . .

工作正在進行中:

我們正在做的事情:

  • 網路管理
  • 系統聯網
  • 本地 DNS 記憶體、mDNS 響應器、LLMNR 響應器、DNSSEC 驗證
  • 核心中的 IPC
  • kdbus, sd匯流排
  • 與 NTP 時間同步
  • 系統時間同步
  • 與容器的更多集成
  • 服務沙盒化
  • 應用沙盒化
  • 作業系統圖像格式
  • 容器鏡像格式
  • 應用圖像格式
  • 具有自動發現功能的 GPT
  • 無狀態系統、可實例化系統、恢復出廠設置
  • /usr 是作業系統
  • /etc 是(可選)配置
  • /var 是(可選的)狀態
  • 原子節點初始化和更新
  • 與雲集成
  • 跨節點服務管理
  • 可驗證的作業系統映像
  • 一直到韌體
  • 引導載入

本答案的範圍

正如fpmurphy1在評論中指出的那樣,“應該指出,systemd 多年來的工作範圍已經遠遠超出了系統啟動的範圍。”

我試圖在此處包含大部分相關資訊。在這裡,我將比較 Upstart 和 systemd 在用作 init 系統時的常見功能,如問題中所問,我只提到 systemd 超出 init 系統範圍的功能,因為這些功能無法與 Startup 進行比較,但它們的存在很重要了解這兩個項目之間的區別。應檢查相關文件以獲取更多資訊。

更多資訊

更多資訊可以在以下位置找到:

附加功能

LinOxide團隊創建了一個Systemd vs SysV Init Linux Cheatsheet

引用自:https://unix.stackexchange.com/questions/5877