一、概述

1.1 背景介紹

systemctl start xxx敲了無(wú)數(shù)遍，但真要從零寫(xiě)一個(gè) Service 文件丟到生產(chǎn)環(huán)境跑，很多人就開(kāi)始心虛了。網(wǎng)上抄一段配置，Type=simple還是forking搞不清楚，Restart=always往上一貼就覺(jué)得萬(wàn)事大吉，結(jié)果進(jìn)程掛了不重啟、OOM 了沒(méi)人管、日志把磁盤(pán)寫(xiě)爆了才發(fā)現(xiàn) journald 根本沒(méi)配輪轉(zhuǎn)。

Systemd 從 2010 年誕生到現(xiàn)在，已經(jīng)不只是一個(gè) init 系統(tǒng)了。它是 Linux 世界的 PID 1，是服務(wù)管理器、日志系統(tǒng)、定時(shí)任務(wù)調(diào)度器、設(shè)備管理器、網(wǎng)絡(luò)配置工具的集合體。2026 年的主流發(fā)行版（Ubuntu 24.04/RHEL 9/Debian 12）全部默認(rèn)使用 systemd 256+，cgroup v2 也已經(jīng)是標(biāo)配。不管你是跑 Java 微服務(wù)、Go 二進(jìn)制、Python 腳本還是 Nginx，最終都要落到一個(gè).service文件上。

這篇文章的目標(biāo)很明確：從 systemd 的架構(gòu)講起，把 Unit 文件的每個(gè) Section、每個(gè)關(guān)鍵指令都講透，最后給出一個(gè)經(jīng)過(guò)生產(chǎn)驗(yàn)證的完整 Service 配置模板?？赐曛螅銘?yīng)該能獨(dú)立編寫(xiě)一個(gè)帶資源限制、安全加固、健康檢查、日志管理的生產(chǎn)級(jí) Service 文件。

1.2 技術(shù)特點(diǎn)

體系化：從架構(gòu)到配置到實(shí)戰(zhàn)，一條線(xiàn)串起來(lái)，不是零散的參數(shù)羅列

生產(chǎn)導(dǎo)向：每個(gè)配置項(xiàng)都說(shuō)明"為什么要這么配"，而不只是"可以這么配"

安全優(yōu)先：覆蓋 ProtectSystem、PrivateTmp、NoNewPrivileges 等安全加固指令

現(xiàn)代技術(shù)棧：基于 systemd 256+、cgroup v2、journald 的 2026 年最佳實(shí)踐

1.3 適用場(chǎng)景

場(chǎng)景一：需要將自研服務(wù)部署到 Linux 服務(wù)器，編寫(xiě)規(guī)范的 Service 文件

場(chǎng)景二：現(xiàn)有 Service 配置過(guò)于簡(jiǎn)陋，需要補(bǔ)充資源限制和安全加固

場(chǎng)景三：想用 systemd timer 替代 cron，實(shí)現(xiàn)更可靠的定時(shí)任務(wù)管理

場(chǎng)景四：需要理解 systemd 的依賴(lài)管理機(jī)制，解決服務(wù)啟動(dòng)順序問(wèn)題

1.4 環(huán)境要求

二、Systemd 架構(gòu)和核心概念

2.1 Systemd 不只是 init

很多人對(duì) systemd 的認(rèn)知停留在"啟動(dòng)服務(wù)的工具"，這個(gè)理解太窄了。Systemd 是一整套系統(tǒng)管理框架，PID 1 進(jìn)程（/usr/lib/systemd/systemd）是它的核心，但遠(yuǎn)不是全部。

            +------------------+
            |  PID 1 (systemd) |
            +--------+---------+
                |
     +----------+-----------+-----------+----------+
     |     |      |      |     |
  +---------+ +--------+ +--------+ +--------+ +--------+
  | journald| | logind | | udevd | | networkd| | resolved|
  +---------+ +--------+ +--------+ +--------+ +--------+
   日志管理  會(huì)話(huà)管理  設(shè)備管理  網(wǎng)絡(luò)管理  DNS解析

  +----------+----------+----------+
  | systemd-tmpfiles  | systemd-sysctl | systemd-modules-load |
  +----------+----------+----------+
   臨時(shí)文件管理     內(nèi)核參數(shù)      內(nèi)核模塊加載

PID 1 負(fù)責(zé)的核心工作：解析 Unit 文件、管理依賴(lài)關(guān)系、啟動(dòng)/停止/監(jiān)控服務(wù)進(jìn)程、處理 cgroup 資源分配。其他組件各司其職，通過(guò) D-Bus 與 PID 1 通信。

2.2 三個(gè)核心概念：Unit、Target、Slice

2.2.1 Unit（單元）

Unit 是 systemd 管理的基本對(duì)象。一個(gè) Unit 對(duì)應(yīng)一個(gè)配置文件，文件后綴決定了 Unit 的類(lèi)型：

日常打交道最多的就是前三個(gè)：Service、Socket、Timer。

2.2.2 Target（目標(biāo)）

Target 是一組 Unit 的邏輯集合，類(lèi)似于 SysVinit 時(shí)代的 runlevel，但更靈活。Target 本身不做任何事情，它只是把一堆 Unit 聚合在一起，表示"系統(tǒng)到達(dá)了某個(gè)狀態(tài)"。

# 查看當(dāng)前活躍的 target
systemctl list-units --type=target --state=active

# 常見(jiàn) target 對(duì)應(yīng)關(guān)系
# multi-user.target ≈ runlevel 3（多用戶(hù)命令行）
# graphical.target  ≈ runlevel 5（圖形界面）
# rescue.target   ≈ runlevel 1（單用戶(hù)模式）

服務(wù)啟動(dòng)順序的核心就是圍繞 target 來(lái)編排的。比如大多數(shù)網(wǎng)絡(luò)服務(wù)都聲明After=network-online.target，意思是"等網(wǎng)絡(luò)就緒了再啟動(dòng)我"。

2.2.3 Slice（切片）

Slice 是 cgroup 的 systemd 抽象層，用于對(duì)一組服務(wù)進(jìn)行資源分配。默認(rèn)的 slice 層級(jí)結(jié)構(gòu)：

-.slice (根 slice)
├── system.slice  # 系統(tǒng)服務(wù)（nginx、mysql 等）
├── user.slice   # 用戶(hù)會(huì)話(huà)
│  ├── user-1000.slice
│  └── user-1001.slice
└── machine.slice # 虛擬機(jī)和容器

可以自定義 slice 來(lái)實(shí)現(xiàn)資源隔離。比如把所有業(yè)務(wù)服務(wù)放到同一個(gè) slice 里，統(tǒng)一限制 CPU 和內(nèi)存上限，防止業(yè)務(wù)進(jìn)程把系統(tǒng)服務(wù)擠死。

2.3 Unit 文件的存放位置

Unit 文件有三個(gè)存放位置，優(yōu)先級(jí)從高到低：

實(shí)際操作原則：永遠(yuǎn)不要直接修改/usr/lib/systemd/system/下的文件，包管理器更新時(shí)會(huì)覆蓋掉。自定義配置放/etc/systemd/system/，覆蓋默認(rèn)配置用systemctl edit創(chuàng)建 drop-in 文件。

# 用 drop-in 方式覆蓋某個(gè)參數(shù)，不動(dòng)原始文件
# 會(huì)創(chuàng)建 /etc/systemd/system/nginx.service.d/override.conf
sudo systemctl edit nginx.service

# 查看某個(gè) unit 的最終生效配置（合并所有 drop-in）
systemctl cat nginx.service

2.4 Unit 文件結(jié)構(gòu)：三個(gè) Section

一個(gè)標(biāo)準(zhǔn)的.service文件由三個(gè) Section 組成：

[Unit]
# 描述信息和依賴(lài)關(guān)系
Description=My Application Service
Documentation=https://docs.example.com
After=network-online.target postgresql.service
Wants=network-online.target
Requires=postgresql.service

[Service]
# 服務(wù)運(yùn)行參數(shù)
Type=notify
ExecStart=/usr/local/bin/myapp --config /etc/myapp/config.yaml
Restart=on-failure
RestartSec=5s
User=myapp
Group=myapp

[Install]
# 安裝信息（enable/disable 時(shí)使用）
WantedBy=multi-user.target

[Unit] Section：定義 Unit 的元信息和依賴(lài)關(guān)系。Description是給人看的，After/Before控制啟動(dòng)順序，Requires/Wants控制依賴(lài)強(qiáng)度。

[Service] Section：這是.service文件獨(dú)有的，也是最核心的部分。定義了進(jìn)程怎么啟動(dòng)、怎么停止、怎么重啟、以什么身份運(yùn)行、資源限制多少。

[Install] Section：定義systemctl enable時(shí)的行為。WantedBy=multi-user.target的意思是"當(dāng)系統(tǒng)進(jìn)入多用戶(hù)模式時(shí)，把我也帶上"。執(zhí)行enable時(shí)，systemd 會(huì)在multi-user.target.wants/目錄下創(chuàng)建一個(gè)指向這個(gè) service 文件的符號(hào)鏈接。

# enable 的本質(zhì)就是創(chuàng)建符號(hào)鏈接
sudo systemctlenablemyapp.service
# 等價(jià)于：
# ln -s /etc/systemd/system/myapp.service 
#  /etc/systemd/system/multi-user.target.wants/myapp.service

# 查看一個(gè) unit 是否 enabled
systemctl is-enabled myapp.service

2.5 Service Type 詳解

Type=是 [Service] Section 里最關(guān)鍵的一個(gè)參數(shù)，它決定了 systemd 如何判斷"服務(wù)已經(jīng)啟動(dòng)成功"。選錯(cuò)了 Type，輕則systemctl start超時(shí)報(bào)錯(cuò)，重則服務(wù)狀態(tài)判斷錯(cuò)亂、重啟策略失效。

2.5.1 五種主要 Type

simple vs exec：simple是默認(rèn)值，進(jìn)程被 fork 出來(lái)就算啟動(dòng)成功，哪怕二進(jìn)制文件路徑寫(xiě)錯(cuò)了，systemctl start也可能返回成功（因?yàn)?fork 本身成功了）。exec更嚴(yán)格，它會(huì)等到exec()系統(tǒng)調(diào)用真正執(zhí)行成功才算就緒。systemd 256+ 推薦用exec替代simple。

forking 的坑：傳統(tǒng) daemon 程序（如 Nginx 默認(rèn)配置）啟動(dòng)時(shí)會(huì) fork 子進(jìn)程，父進(jìn)程退出。用Type=forking時(shí)，systemd 需要知道哪個(gè)是"主進(jìn)程"，通常通過(guò)PIDFile=指定 PID 文件路徑來(lái)追蹤。如果 PID 文件寫(xiě)入不及時(shí)或路徑配錯(cuò)，systemd 就會(huì)丟失對(duì)進(jìn)程的追蹤。

# forking 類(lèi)型的典型配置（Nginx 為例）
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID

notify 的優(yōu)勢(shì)：這是生產(chǎn)環(huán)境最推薦的 Type。進(jìn)程在完成所有初始化工作（加載配置、連接數(shù)據(jù)庫(kù)、預(yù)熱緩存）之后，主動(dòng)調(diào)用sd_notify(0, "READY=1")告訴 systemd "我準(zhǔn)備好了"。這樣 systemd 對(duì)服務(wù)狀態(tài)的判斷是最準(zhǔn)確的。

// Go 程序中使用 sd_notify 的示例
import"github.com/coreos/go-systemd/v22/daemon"

funcmain(){
 // 初始化工作...
  loadConfig()
  connectDB()
  warmupCache()

 // 通知 systemd 服務(wù)就緒
  daemon.SdNotify(false, daemon.SdNotifyReady)

 // 開(kāi)始服務(wù)主循環(huán)
  serve()
}

2.5.2 選型決策樹(shù)

你的程序啟動(dòng)后會(huì) fork 并退出父進(jìn)程嗎？
├── 是 → Type=forking + PIDFile=
└── 否 → 程序支持 sd_notify 嗎？
  ├── 是 → Type=notify（最佳選擇）
  └── 否 → 程序是一次性任務(wù)嗎？
    ├── 是 → Type=oneshot（可選 RemainAfterExit=yes）
    └── 否 → Type=exec（推薦）或 Type=simple

2.6 啟動(dòng)依賴(lài)管理

服務(wù)之間的依賴(lài)關(guān)系是 systemd 的核心能力之一。這里有兩個(gè)維度需要區(qū)分清楚：啟動(dòng)順序和依賴(lài)強(qiáng)度。

2.6.1 啟動(dòng)順序：After / Before

After和Before只控制順序，不控制依賴(lài)。聲明After=postgresql.service意味著"如果 postgresql 也要啟動(dòng)，那先啟動(dòng)它，再啟動(dòng)我"。但如果 postgresql 根本沒(méi)有被激活，這條聲明不會(huì)自動(dòng)把它拉起來(lái)。

[Unit]
# 正確：先等網(wǎng)絡(luò)和數(shù)據(jù)庫(kù)就緒，再啟動(dòng)本服務(wù)
After=network-online.target postgresql.service redis.service

2.6.2 依賴(lài)強(qiáng)度：Requires / Wants / BindsTo

生產(chǎn)建議：大多數(shù)場(chǎng)景用Wants=+After=的組合就夠了。Requires=看起來(lái)更"安全"，但它有一個(gè)副作用——如果被依賴(lài)的服務(wù)后來(lái)掛了，本服務(wù)也會(huì)被連帶停止。這在微服務(wù)架構(gòu)下往往不是你想要的行為。

[Unit]
Description=My Web Application
After=network-online.target postgresql.service
# 用 Wants 而不是 Requires，數(shù)據(jù)庫(kù)臨時(shí)不可用時(shí)服務(wù)自己處理重連
Wants=network-online.target postgresql.service

2.6.3 網(wǎng)絡(luò)依賴(lài)的正確寫(xiě)法

這是一個(gè)高頻踩坑點(diǎn)。很多人寫(xiě)After=network.target，結(jié)果服務(wù)啟動(dòng)時(shí)網(wǎng)絡(luò)還沒(méi)通。原因是network.target只表示"網(wǎng)絡(luò)管理器已啟動(dòng)"，不代表網(wǎng)絡(luò)已經(jīng)可用。正確的寫(xiě)法：

[Unit]
After=network-online.target
Wants=network-online.target

同時(shí)需要確保systemd-networkd-wait-online.service或NetworkManager-wait-online.service是啟用的，否則network-online.target會(huì)被立即視為已達(dá)成。

2.7 進(jìn)程管理：重啟策略與健康檢查

2.7.1 Restart 策略

Restart=控制進(jìn)程退出后是否自動(dòng)重啟：

生產(chǎn)建議：大多數(shù)守護(hù)進(jìn)程用Restart=on-failure。不要無(wú)腦用always——如果程序是正常退出（比如收到 SIGTERM 后優(yōu)雅關(guān)閉），你通常不希望它被自動(dòng)拉起來(lái)。always適合那些"只要沒(méi)在跑就是不正常"的核心服務(wù)。

2.7.2 重啟頻率控制

光有Restart=on-failure還不夠，還需要控制重啟的節(jié)奏，防止進(jìn)程反復(fù)崩潰導(dǎo)致 CPU 空轉(zhuǎn)：

[Service]
Restart=on-failure
RestartSec=5s       # 每次重啟前等待 5 秒
RestartSteps=5       # 重啟間隔逐步遞增的步數(shù)（systemd 256+）
RestartMaxDelaySec=60s   # 遞增的最大間隔（systemd 256+）
StartLimitIntervalSec=300 # 在 300 秒的窗口內(nèi)
StartLimitBurst=5     # 最多重啟 5 次，超過(guò)則放棄

systemd 256+ 新增了RestartSteps和RestartMaxDelaySec，可以實(shí)現(xiàn)指數(shù)退避式重啟。第一次重啟等 5 秒，第二次等 16 秒，逐步遞增到 60 秒封頂。這比固定間隔更合理——如果是瞬時(shí)故障，快速重啟能盡快恢復(fù)；如果是持續(xù)性故障，拉長(zhǎng)間隔避免雪崩。

2.7.3 超時(shí)控制

[Service]
TimeoutStartSec=30s  # 啟動(dòng)超時(shí)，超過(guò) 30 秒未就緒則判定失敗
TimeoutStopSec=30s   # 停止超時(shí)，超過(guò) 30 秒未退出則發(fā) SIGKILL
TimeoutAbortSec=60s  # 收到 abort 信號(hào)后的超時(shí)（用于生成 core dump）

TimeoutStopSec特別重要。systemctl stop時(shí)，systemd 先發(fā) SIGTERM，等TimeoutStopSec秒后如果進(jìn)程還沒(méi)退出，就發(fā) SIGKILL 強(qiáng)殺。Java 應(yīng)用通常需要把這個(gè)值調(diào)大一些（比如 60s），給 JVM 足夠的時(shí)間做優(yōu)雅關(guān)閉。

2.7.4 Watchdog 看門(mén)狗

Watchdog 是 systemd 提供的進(jìn)程健康檢查機(jī)制。服務(wù)進(jìn)程需要定期向 systemd 發(fā)送心跳，如果超時(shí)沒(méi)收到，systemd 就認(rèn)為進(jìn)程卡死了，按照 Restart 策略處理。

[Service]
Type=notify
WatchdogSec=30s      # 每 30 秒需要收到一次心跳
WatchdogSignal=SIGABRT   # 超時(shí)后發(fā)送的信號(hào)（默認(rèn) SIGABRT，可生成 core dump）

程序端需要配合發(fā)送心跳：

// Go 程序中發(fā)送 watchdog 心跳
import"github.com/coreos/go-systemd/v22/daemon"

funcwatchdogLoop(){
  interval, _ := daemon.SdWatchdogEnabled(false)
 ifinterval ==0{
   return// watchdog 未啟用
  }
  ticker := time.NewTicker(interval /2)// 以一半間隔發(fā)送，留足余量
 forrangeticker.C {
    daemon.SdNotify(false, daemon.SdNotifyWatchdog)
  }
}

Watchdog 解決的是"進(jìn)程還活著但已經(jīng)卡死"的問(wèn)題——進(jìn)程沒(méi)崩潰、PID 還在、端口還監(jiān)聽(tīng)著，但內(nèi)部死鎖了或者陷入無(wú)限循環(huán)，外部健康檢查可能還沒(méi)來(lái)得及發(fā)現(xiàn)。Watchdog 從進(jìn)程內(nèi)部檢測(cè)這種狀態(tài)，比外部探測(cè)更及時(shí)。

三、資源限制、安全加固與日志管理

3.1 資源限制（cgroup v2）

不做資源限制的服務(wù)就是在裸奔。一個(gè)內(nèi)存泄漏的進(jìn)程可以把整臺(tái)機(jī)器的內(nèi)存吃光觸發(fā) OOM Killer，一個(gè)死循環(huán)可以把所有 CPU 核心打滿(mǎn)。systemd 通過(guò) cgroup v2 提供了細(xì)粒度的資源限制能力，直接在 Service 文件里配置就行，不需要手動(dòng)操作 cgroup 文件系統(tǒng)。

3.1.1 CPU 限制

[Service]
# CPU 配額：200% 表示最多使用 2 個(gè)核心
CPUQuota=200%

# CPU 權(quán)重：默認(rèn) 100，范圍 1-10000
# 只在 CPU 競(jìng)爭(zhēng)時(shí)生效，空閑時(shí)不限制
CPUWeight=50

# 綁定到特定 CPU 核心（可選，通常不需要）
AllowedCPUs=0-3

CPUQuota是硬限制，不管 CPU 是否空閑都不會(huì)超過(guò)這個(gè)值。CPUWeight是軟限制，只在多個(gè)服務(wù)競(jìng)爭(zhēng) CPU 時(shí)按權(quán)重分配，CPU 空閑時(shí)不起作用。生產(chǎn)環(huán)境建議兩個(gè)都配：CPUWeight保證公平調(diào)度，CPUQuota兜底防止單個(gè)服務(wù)吃滿(mǎn)所有核心。

3.1.2 內(nèi)存限制

[Service]
# 內(nèi)存硬上限：超過(guò)直接 OOM Kill
MemoryMax=2G

# 內(nèi)存軟上限：超過(guò)后內(nèi)核會(huì)優(yōu)先回收該 cgroup 的內(nèi)存
MemoryHigh=1536M

# 最低內(nèi)存保障：內(nèi)存緊張時(shí)至少保留這么多
MemoryMin=256M

# 禁用 swap（推薦）
MemorySwapMax=0

MemoryMax和MemoryHigh的區(qū)別很關(guān)鍵。MemoryHigh是軟限制，超過(guò)后內(nèi)核會(huì)加大內(nèi)存回收力度（進(jìn)程會(huì)變慢但不會(huì)被殺）；MemoryMax是硬限制，超過(guò)直接觸發(fā) OOM Kill。生產(chǎn)環(huán)境建議MemoryHigh設(shè)為正常峰值的 120%，MemoryMax設(shè)為 150%，給一個(gè)緩沖區(qū)間。

3.1.3 IO 限制

[Service]
# IO 權(quán)重：默認(rèn) 100，范圍 1-10000
IOWeight=50

# 針對(duì)特定設(shè)備的帶寬限制
IOReadBandwidthMax=/dev/sda 50M
IOWriteBandwidthMax=/dev/sda 20M

# IOPS 限制
IOReadIOPSMax=/dev/sda 1000
IOWriteIOPSMax=/dev/sda 500

IO 限制在數(shù)據(jù)庫(kù)服務(wù)和日志密集型服務(wù)上特別有用。一個(gè)瘋狂寫(xiě)日志的服務(wù)可以把磁盤(pán) IO 打滿(mǎn)，影響同機(jī)器上的其他服務(wù)。

3.1.4 其他資源限制

[Service]
# 最大文件描述符數(shù)
LimitNOFILE=65536

# 最大進(jìn)程/線(xiàn)程數(shù)
LimitNPROC=4096

# core dump 大?。? 表示禁用）
LimitCORE=infinity

# 最大打開(kāi)文件鎖數(shù)
LimitLOCKS=infinity

# 任務(wù)數(shù)上限（cgroup 級(jí)別，比 NPROC 更準(zhǔn)確）
TasksMax=4096

LimitNOFILE是高并發(fā)服務(wù)的必配項(xiàng)。Linux 默認(rèn)的 1024 對(duì)于任何生產(chǎn)服務(wù)都太小了，Nginx、Redis、數(shù)據(jù)庫(kù)類(lèi)服務(wù)通常需要 65536 甚至更高。

3.2 安全加固

Systemd 提供了一整套沙箱機(jī)制，可以在不修改應(yīng)用代碼的情況下大幅收窄進(jìn)程的權(quán)限范圍。這些配置的成本幾乎為零，但安全收益很高。

3.2.1 文件系統(tǒng)保護(hù)

[Service]
# 將 /usr 和 /boot 掛載為只讀
ProtectSystem=strict

# 為進(jìn)程創(chuàng)建獨(dú)立的 /tmp，與其他進(jìn)程隔離
PrivateTmp=yes

# 將 /home、/root、/run/user 設(shè)為不可訪(fǎng)問(wèn)
ProtectHome=yes

# 只允許讀寫(xiě)指定目錄
ReadWritePaths=/var/lib/myapp /var/log/myapp
ReadOnlyPaths=/etc/myapp

# 禁止訪(fǎng)問(wèn)指定目錄
InaccessiblePaths=/var/lib/mysql

ProtectSystem=strict是最嚴(yán)格的模式，整個(gè)文件系統(tǒng)變成只讀，只有通過(guò)ReadWritePaths顯式聲明的目錄才可寫(xiě)。這意味著即使應(yīng)用被攻破，攻擊者也無(wú)法篡改系統(tǒng)文件。

3.2.2 權(quán)限收窄

[Service]
# 禁止獲取新的特權(quán)（防止 setuid 提權(quán)）
NoNewPrivileges=yes

# 以非 root 用戶(hù)運(yùn)行
User=myapp
Group=myapp
DynamicUser=yes  # 自動(dòng)創(chuàng)建臨時(shí)用戶(hù)（systemd 256+ 推薦）

# 移除所有 Linux capabilities
CapabilityBoundingSet=
# 如果需要綁定低端口，只給 NET_BIND_SERVICE
# CapabilityBoundingSet=CAP_NET_BIND_SERVICE

# 限制系統(tǒng)調(diào)用（白名單模式）
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

NoNewPrivileges=yes是零成本的安全加固，沒(méi)有任何副作用，所有服務(wù)都應(yīng)該加上。DynamicUser=yes是 systemd 的一個(gè)巧妙設(shè)計(jì)——它會(huì)在服務(wù)啟動(dòng)時(shí)動(dòng)態(tài)分配一個(gè) UID/GID，服務(wù)停止后自動(dòng)回收，不需要手動(dòng)創(chuàng)建系統(tǒng)用戶(hù)。

3.2.3 網(wǎng)絡(luò)和內(nèi)核隔離

[Service]
# 創(chuàng)建獨(dú)立的網(wǎng)絡(luò)命名空間（完全斷網(wǎng)）
PrivateNetwork=yes
# 如果需要網(wǎng)絡(luò)但想限制，用 RestrictAddressFamilies
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

# 禁止加載內(nèi)核模塊
ProtectKernelModules=yes

# 禁止修改內(nèi)核參數(shù)
ProtectKernelTunables=yes

# 禁止訪(fǎng)問(wèn)內(nèi)核日志
ProtectKernelLogs=yes

# 禁止修改系統(tǒng)時(shí)鐘
ProtectClock=yes

# 禁止創(chuàng)建設(shè)備節(jié)點(diǎn)
PrivateDevices=yes

3.2.4 一鍵查看安全評(píng)分

systemd 提供了一個(gè)內(nèi)置的安全審計(jì)工具，可以對(duì) Service 文件進(jìn)行安全評(píng)分：

# 查看某個(gè)服務(wù)的安全評(píng)分
systemd-analyze security myapp.service

# 輸出示例（分?jǐn)?shù)越低越安全，10 分最不安全）
# → Overall exposure level for myapp.service: 2.1 OK

這個(gè)工具會(huì)逐項(xiàng)檢查所有安全相關(guān)的配置，給出評(píng)分和改進(jìn)建議。新寫(xiě)的 Service 文件跑一遍這個(gè)命令，把能加的安全配置都加上，目標(biāo)是控制在 3 分以?xún)?nèi)。

3.3 日志管理

3.3.1 journald 基礎(chǔ)

Systemd 服務(wù)的標(biāo)準(zhǔn)輸出和標(biāo)準(zhǔn)錯(cuò)誤默認(rèn)會(huì)被 journald 捕獲。不需要在應(yīng)用里配置日志文件路徑，直接往 stdout/stderr 寫(xiě)就行，journald 會(huì)自動(dòng)加上時(shí)間戳、服務(wù)名、PID 等元數(shù)據(jù)。

# 查看某個(gè)服務(wù)的日志
journalctl -u myapp.service

# 實(shí)時(shí)跟蹤日志（類(lèi)似 tail -f）
journalctl -u myapp.service -f

# 查看最近 1 小時(shí)的日志
journalctl -u myapp.service --since"1 hour ago"

# 按優(yōu)先級(jí)過(guò)濾（0=emerg 到 7=debug）
journalctl -u myapp.service -p err

# 輸出 JSON 格式（方便程序處理）
journalctl -u myapp.service -o json-pretty

3.3.2 Service 文件中的日志配置

[Service]
# 日志輸出目標(biāo)
StandardOutput=journal
StandardError=journal

# 設(shè)置日志標(biāo)識(shí)符（默認(rèn)是服務(wù)名）
SyslogIdentifier=myapp

# 設(shè)置日志級(jí)別過(guò)濾
LogLevelMax=info  # 只記錄 info 及以上級(jí)別

# 限制日志速率（防止日志風(fēng)暴）
LogRateLimitIntervalSec=30s
LogRateLimitBurst=10000  # 30 秒內(nèi)最多 10000 條

LogRateLimitIntervalSec和LogRateLimitBurst是生產(chǎn)環(huán)境的保命配置。見(jiàn)過(guò)太多次應(yīng)用出 bug 后瘋狂打日志，每秒幾萬(wàn)條，把磁盤(pán) IO 打滿(mǎn)、把 journald 撐爆的情況。

3.3.3 journald 全局配置和日志輪轉(zhuǎn)

編輯/etc/systemd/journald.conf：

[Journal]
# 持久化存儲(chǔ)（默認(rèn)是 volatile，重啟丟失）
Storage=persistent

# 磁盤(pán)占用上限
SystemMaxUse=2G     # 日志總大小上限
SystemMaxFileSize=128M  # 單個(gè)日志文件上限
SystemKeepFree=4G    # 至少保留 4G 磁盤(pán)空間

# 運(yùn)行時(shí)（內(nèi)存中）日志限制
RuntimeMaxUse=256M

# 日志保留時(shí)間
MaxRetentionSec=30day

# 壓縮
Compress=yes

journald 的日志輪轉(zhuǎn)是自動(dòng)的，不需要像 logrotate 那樣配置 cron。當(dāng)日志總量超過(guò)SystemMaxUse或單文件超過(guò)SystemMaxFileSize時(shí)，journald 會(huì)自動(dòng)刪除最舊的日志。

# 手動(dòng)清理日志
sudo journalctl --vacuum-size=1G  # 只保留 1G
sudo journalctl --vacuum-time=7d  # 只保留 7 天

# 查看日志占用空間
journalctl --disk-usage

四、Timer 定時(shí)任務(wù)

4.1 為什么用 Timer 替代 Cron

Cron 用了幾十年，能跑但問(wèn)題不少：沒(méi)有日志集成（輸出靠郵件或重定向）、沒(méi)有依賴(lài)管理、沒(méi)有資源限制、錯(cuò)過(guò)的任務(wù)不會(huì)補(bǔ)執(zhí)行、多實(shí)例并發(fā)沒(méi)有保護(hù)。Systemd Timer 解決了這些問(wèn)題，而且和 Service 文件共享同一套管理體系。

4.2 Timer 文件結(jié)構(gòu)

一個(gè) Timer 由兩個(gè)文件組成：.timer文件定義觸發(fā)時(shí)間，.service文件定義要執(zhí)行的任務(wù)。兩個(gè)文件同名（后綴不同），systemd 自動(dòng)關(guān)聯(lián)。

# /etc/systemd/system/db-backup.timer
[Unit]
Description=Database Backup Timer

[Timer]
# 每天凌晨 2 點(diǎn)執(zhí)行
OnCalendar=*-*-* 0200

# 如果錯(cuò)過(guò)了（比如機(jī)器當(dāng)時(shí)關(guān)機(jī)），開(kāi)機(jī)后補(bǔ)執(zhí)行
Persistent=yes

# 隨機(jī)延遲 0-15 分鐘，避免多臺(tái)機(jī)器同時(shí)執(zhí)行
RandomizedDelaySec=15min

# 精度（默認(rèn) 1min，設(shè)小一點(diǎn)更準(zhǔn)時(shí)）
AccuracySec=1s

[Install]
WantedBy=timers.target

# /etc/systemd/system/db-backup.service
[Unit]
Description=Database Backup Job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-db.sh
User=backup
Group=backup

# 資源限制和安全加固同樣適用
MemoryMax=512M
CPUQuota=50%
ProtectSystem=strict
PrivateTmp=yes
NoNewPrivileges=yes
ReadWritePaths=/var/backups

4.3 OnCalendar 時(shí)間表達(dá)式

OnCalendar的語(yǔ)法比 cron 更直觀(guān)：

# 格式：星期 年-月-日 時(shí):分:秒
OnCalendar=Mon..Fri *-*-* 0900  # 工作日每天 9 點(diǎn)
OnCalendar=*-*-* *:00/15:00     # 每 15 分鐘
OnCalendar=*-*-01 0000      # 每月 1 號(hào)零點(diǎn)
OnCalendar=weekly           # 每周一零點(diǎn)
OnCalendar=hourly           # 每小時(shí)整點(diǎn)

# 驗(yàn)證時(shí)間表達(dá)式
systemd-analyze calendar"*-*-* 0200"
# 輸出下次觸發(fā)時(shí)間，確認(rèn)表達(dá)式寫(xiě)對(duì)了

也可以用相對(duì)時(shí)間觸發(fā)：

[Timer]
# 系統(tǒng)啟動(dòng) 5 分鐘后執(zhí)行
OnBootSec=5min

# 上次執(zhí)行完成后 30 分鐘再執(zhí)行
OnUnitActiveSec=30min

4.4 Timer 管理命令

# 啟用并啟動(dòng) timer
sudo systemctlenable--now db-backup.timer

# 查看所有 timer 的狀態(tài)和下次觸發(fā)時(shí)間
systemctl list-timers --all

# 手動(dòng)觸發(fā)一次（不影響定時(shí)計(jì)劃）
sudo systemctl start db-backup.service

# 查看 timer 的執(zhí)行歷史
journalctl -u db-backup.service --since"7 days ago"

五、Socket 激活

5.1 什么是 Socket 激活

Socket 激活是 systemd 的一個(gè)精巧設(shè)計(jì)：由 systemd 預(yù)先監(jiān)聽(tīng)端口，當(dāng)?shù)谝粋€(gè)連接請(qǐng)求到達(dá)時(shí)，再啟動(dòng)對(duì)應(yīng)的服務(wù)進(jìn)程，并把 socket 文件描述符傳遞給它。服務(wù)進(jìn)程啟動(dòng)后接管 socket，后續(xù)請(qǐng)求直接由服務(wù)處理。

這個(gè)機(jī)制帶來(lái)三個(gè)好處：

啟動(dòng)加速：系統(tǒng)啟動(dòng)時(shí)不需要等所有服務(wù)都起來(lái)，端口先占著，請(qǐng)求來(lái)了再啟動(dòng)

按需啟動(dòng)：不常用的服務(wù)平時(shí)不占資源，有請(qǐng)求才拉起來(lái)

零停機(jī)重啟：重啟服務(wù)時(shí)，systemd 繼續(xù)持有 socket，新連接排隊(duì)等待，服務(wù)重啟完成后繼續(xù)處理，客戶(hù)端感知不到中斷

5.2 Socket 激活配置示例

# /etc/systemd/system/myapp.socket
[Unit]
Description=My Application Socket

[Socket]
# 監(jiān)聽(tīng)地址和端口
ListenStream=0.0.0.0:8080

# 也可以監(jiān)聽(tīng) Unix Socket
# ListenStream=/run/myapp/myapp.sock

# 連接隊(duì)列長(zhǎng)度
Backlog=4096

# Socket 文件權(quán)限（Unix Socket 時(shí)有效）
# SocketMode=0660
# SocketUser=myapp
# SocketGroup=myapp

# 接受連接后傳遞給哪個(gè)服務(wù)（默認(rèn)同名 .service）
# Service=myapp.service

[Install]
WantedBy=sockets.target

對(duì)應(yīng)的 Service 文件不需要特殊修改，只要程序能從文件描述符 3 接收 socket 即可。Go 標(biāo)準(zhǔn)庫(kù)的net包、systemd 的sd_listen_fds()API 都支持這種模式。

# 啟用 socket 激活（注意：?jiǎn)?dòng)的是 .socket 不是 .service）
sudo systemctlenable--now myapp.socket

# 此時(shí) myapp.service 還沒(méi)啟動(dòng)，但端口已經(jīng)在監(jiān)聽(tīng)
ss -tlnp | grep 8080
# 輸出：systemd 在監(jiān)聽(tīng)

# 發(fā)送第一個(gè)請(qǐng)求，觸發(fā) myapp.service 啟動(dòng)
curl http://localhost:8080/health

六、生產(chǎn)級(jí) Service 文件完整示例

6.1 Go Web 服務(wù)（推薦模板）

這是一個(gè)經(jīng)過(guò)生產(chǎn)驗(yàn)證的完整 Service 文件，覆蓋了前面講到的所有關(guān)鍵配置?？梢宰鳛槟０澹鶕?jù)實(shí)際需求增刪參數(shù)。

# /etc/systemd/system/myapp.service
# 生產(chǎn)級(jí) Go Web 服務(wù)配置模板

# ============================================================
# [Unit] 元信息和依賴(lài)
# ============================================================
[Unit]
Description=My Application API Server
Documentation=https://docs.example.com/myapp
After=network-online.target postgresql.service redis.service
Wants=network-online.target
# 用 Wants 而非 Requires，依賴(lài)服務(wù)臨時(shí)不可用時(shí)由應(yīng)用自行處理重連
Wants=postgresql.service redis.service

# 條件檢查：配置文件必須存在才啟動(dòng)
ConditionPathExists=/etc/myapp/config.yaml

# ============================================================
# [Service] 核心運(yùn)行參數(shù)
# ============================================================
[Service]
Type=notify
NotifyAccess=main

# --- 啟動(dòng)命令 ---
ExecStartPre=/usr/local/bin/myapp validate --config /etc/myapp/config.yaml
ExecStart=/usr/local/bin/myapp serve --config /etc/myapp/config.yaml
ExecReload=/bin/kill -s HUP $MAINPID

# --- 運(yùn)行身份 ---
User=myapp
Group=myapp

# --- 工作目錄和環(huán)境 ---
WorkingDirectory=/var/lib/myapp
EnvironmentFile=-/etc/myapp/env  # 減號(hào)表示文件不存在時(shí)不報(bào)錯(cuò)
Environment=GOMAXPROCS=4
Environment=GIN_MODE=release

# --- 重啟策略 ---
Restart=on-failure
RestartSec=5s
RestartSteps=5
RestartMaxDelaySec=60s
StartLimitIntervalSec=300
StartLimitBurst=5

# --- 超時(shí)和看門(mén)狗 ---
TimeoutStartSec=30s
TimeoutStopSec=60s
WatchdogSec=30s

# --- 資源限制 ---
CPUQuota=200%
CPUWeight=100
MemoryMax=2G
MemoryHigh=1536M
MemorySwapMax=0
TasksMax=4096
LimitNOFILE=65536
LimitNPROC=4096

# --- 安全加固 ---
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectKernelLogs=yes
ProtectClock=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
ReadWritePaths=/var/lib/myapp /var/log/myapp
ReadOnlyPaths=/etc/myapp

# --- 日志 ---
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapp
LogRateLimitIntervalSec=30s
LogRateLimitBurst=10000

# ============================================================
# [Install] 安裝信息
# ============================================================
[Install]
WantedBy=multi-user.target

6.2 部署流程

寫(xiě)好 Service 文件后，部署流程如下：

# 1. 創(chuàng)建運(yùn)行用戶(hù)
sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp

# 2. 創(chuàng)建必要目錄
sudo mkdir -p /var/lib/myapp /var/log/myapp /etc/myapp
sudo chown myapp:myapp /var/lib/myapp /var/log/myapp

# 3. 部署二進(jìn)制和配置文件
sudo cp myapp /usr/local/bin/myapp
sudo chmod 755 /usr/local/bin/myapp
sudo cp config.yaml /etc/myapp/config.yaml

# 4. 部署 Service 文件
sudo cp myapp.service /etc/systemd/system/myapp.service

# 5. 重新加載 systemd 配置
sudo systemctl daemon-reload

# 6. 啟用并啟動(dòng)服務(wù)
sudo systemctlenable--now myapp.service

# 7. 驗(yàn)證服務(wù)狀態(tài)
systemctl status myapp.service
journalctl -u myapp.service -n 50 --no-pager

6.3 Java 服務(wù)示例

Java 服務(wù)和 Go 服務(wù)的主要區(qū)別在于：JVM 啟動(dòng)慢需要更長(zhǎng)的超時(shí)時(shí)間、內(nèi)存模型不同需要調(diào)整限制策略、不支持 sd_notify 通常用Type=exec。

# /etc/systemd/system/myapp-java.service
[Unit]
Description=My Java Application
After=network-online.target
Wants=network-online.target

[Service]
Type=exec

ExecStart=/usr/bin/java 
  -Xms512m -Xmx1536m 
  -XX:+UseZGC 
  -jar /opt/myapp/myapp.jar 
  --spring.config.location=/etc/myapp/

User=myapp
Group=myapp
WorkingDirectory=/opt/myapp

Restart=on-failure
RestartSec=10s
StartLimitIntervalSec=300
StartLimitBurst=3

# JVM 啟動(dòng)慢，給足時(shí)間
TimeoutStartSec=120s
# 優(yōu)雅關(guān)閉需要時(shí)間（Spring Boot shutdown hook）
TimeoutStopSec=60s

# 內(nèi)存限制要考慮 JVM 堆外內(nèi)存，設(shè)為 Xmx 的 1.5 倍左右
MemoryMax=3G
MemoryHigh=2560M
MemorySwapMax=0
CPUQuota=400%
LimitNOFILE=65536
TasksMax=4096

# 安全加固
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ReadWritePaths=/var/lib/myapp /var/log/myapp /tmp

StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapp-java

[Install]
WantedBy=multi-user.target

Java 服務(wù)的MemoryMax不能簡(jiǎn)單等于-Xmx。JVM 除了堆內(nèi)存還有 Metaspace、線(xiàn)程棧、直接內(nèi)存、JIT 編譯緩存等堆外開(kāi)銷(xiāo)，實(shí)際內(nèi)存占用通常是-Xmx的 1.3 到 1.8 倍。MemoryMax設(shè)太小會(huì)導(dǎo)致 JVM 被 OOM Kill，設(shè)太大又失去了限制的意義。建議用-Xmx的 1.5 倍作為起點(diǎn)，再根據(jù)實(shí)際監(jiān)控?cái)?shù)據(jù)調(diào)整。

七、systemctl 常用命令速查

7.1 服務(wù)生命周期管理

# 啟動(dòng)/停止/重啟/重載
sudo systemctl start myapp.service
sudo systemctl stop myapp.service
sudo systemctl restart myapp.service
sudo systemctl reload myapp.service    # 發(fā)送 SIGHUP，不中斷服務(wù)
sudo systemctl reload-or-restart myapp.service # 支持 reload 就 reload，否則 restart

# 開(kāi)機(jī)自啟
sudo systemctlenablemyapp.service    # 設(shè)置開(kāi)機(jī)自啟
sudo systemctldisablemyapp.service   # 取消開(kāi)機(jī)自啟
sudo systemctlenable--now myapp.service # 設(shè)置自啟并立即啟動(dòng)

# 徹底屏蔽服務(wù)（防止被其他服務(wù)拉起）
sudo systemctl mask myapp.service
sudo systemctl unmask myapp.service

7.2 狀態(tài)查看和診斷

# 查看服務(wù)狀態(tài)（最常用）
systemctl status myapp.service

# 查看服務(wù)是否在運(yùn)行
systemctl is-active myapp.service

# 查看服務(wù)是否啟動(dòng)失敗
systemctl is-failed myapp.service

# 查看所有失敗的服務(wù)
systemctl --failed

# 查看服務(wù)的完整配置（合并 drop-in）
systemctl cat myapp.service

# 查看服務(wù)的所有屬性
systemctl show myapp.service

# 查看某個(gè)具體屬性
systemctl show myapp.service -p MainPID -p MemoryCurrent -p CPUUsageNSec

7.3 配置管理和分析

# 修改后重新加載配置（不重啟服務(wù)）
sudo systemctl daemon-reload

# 用 drop-in 方式修改配置（推薦）
sudo systemctl edit myapp.service
# 編輯完整的 service 文件（不推薦，會(huì)覆蓋原文件）
sudo systemctl edit --full myapp.service

# 分析啟動(dòng)耗時(shí)
systemd-analyze             # 總啟動(dòng)時(shí)間
systemd-analyze blame          # 各服務(wù)啟動(dòng)耗時(shí)排序
systemd-analyze critical-chain myapp.service # 關(guān)鍵路徑分析

# 安全審計(jì)
systemd-analyze security myapp.service

# 驗(yàn)證 unit 文件語(yǔ)法
systemd-analyze verify /etc/systemd/system/myapp.service

# 查看服務(wù)的依賴(lài)樹(shù)
systemctl list-dependencies myapp.service
systemctl list-dependencies --reverse myapp.service # 反向：誰(shuí)依賴(lài)我

7.4 日志查看速查

# 查看某個(gè)服務(wù)的日志
journalctl -u myapp.service

# 實(shí)時(shí)跟蹤（tail -f 模式）
journalctl -u myapp.service -f

# 最近 N 條
journalctl -u myapp.service -n 100

# 時(shí)間范圍
journalctl -u myapp.service --since"2026-02-06 0000"--until"2026-02-06 1200"
journalctl -u myapp.service --since"30 min ago"

# 按級(jí)別過(guò)濾
journalctl -u myapp.service -p err   # error 及以上
journalctl -u myapp.service -p warning # warning 及以上

# 輸出格式
journalctl -u myapp.service -o json-pretty # JSON 格式
journalctl -u myapp.service -o short-iso  # ISO 時(shí)間格式

# 查看上一次啟動(dòng)的日志（排查重啟前的崩潰原因）
journalctl -u myapp.service -b -1

# 查看內(nèi)核 OOM Kill 記錄
journalctl -k | grep -i"oom|killed"

7.5 資源監(jiān)控

# 查看服務(wù)的實(shí)時(shí)資源占用
systemctl status myapp.service
# 輸出中包含 Memory: 和 CPU: 行

# 查看 cgroup 級(jí)別的詳細(xì)資源數(shù)據(jù)
systemctl show myapp.service -p MemoryCurrent -p MemoryPeak -p CPUUsageNSec

# 查看所有服務(wù)的資源占用排序
systemd-cgtop

# 查看某個(gè)服務(wù)的 cgroup 路徑
systemctl show myapp.service -p ControlGroup

# 直接查看 cgroup 文件（更詳細(xì)）
cat /sys/fs/cgroup/system.slice/myapp.service/memory.current
cat /sys/fs/cgroup/system.slice/myapp.service/cpu.stat

八、總結(jié)

8.1 技術(shù)要點(diǎn)回顧

Unit/Target/Slice是 systemd 的三個(gè)核心抽象：Unit 是管理單元，Target 是邏輯分組，Slice 是資源分組

Service Type 選型：優(yōu)先用notify（程序支持的話(huà)），其次exec，傳統(tǒng) daemon 用forking，一次性任務(wù)用oneshot

依賴(lài)管理：After/Before控制順序，Wants/Requires控制強(qiáng)度，生產(chǎn)環(huán)境優(yōu)先用Wants+After組合

重啟策略：Restart=on-failure覆蓋大多數(shù)場(chǎng)景，配合RestartSteps實(shí)現(xiàn)指數(shù)退避，用StartLimitBurst防止無(wú)限重啟

Watchdog：解決"進(jìn)程活著但卡死"的問(wèn)題，需要程序端配合發(fā)送心跳

資源限制：MemoryMax硬限制兜底，MemoryHigh軟限制緩沖，CPUQuota防止單服務(wù)吃滿(mǎn) CPU

安全加固：NoNewPrivileges=yes零成本必加，ProtectSystem=strict+ReadWritePaths最小化文件系統(tǒng)權(quán)限

日志管理：用 journald 統(tǒng)一管理，配置LogRateLimitBurst防日志風(fēng)暴，配置SystemMaxUse防磁盤(pán)寫(xiě)爆

Timer 替代 Cron：日志集成、依賴(lài)管理、資源限制、錯(cuò)過(guò)補(bǔ)執(zhí)行，全面優(yōu)于 cron

Socket 激活：按需啟動(dòng)、零停機(jī)重啟，適合低頻訪(fǎng)問(wèn)或需要平滑重啟的服務(wù)

8.2 Service 文件編寫(xiě) Checklist

寫(xiě)完一個(gè) Service 文件后，對(duì)照這個(gè)清單檢查一遍：

[ ] Type 選對(duì)了嗎？程序的啟動(dòng)行為和 Type 匹配嗎？
[ ] 依賴(lài)關(guān)系配了嗎？After 和 Wants 寫(xiě)對(duì)了嗎？
[ ] 用非 root 用戶(hù)運(yùn)行了嗎？User/Group 配了嗎？
[ ] Restart 策略配了嗎？RestartSec 和 StartLimitBurst 配了嗎？
[ ] 超時(shí)時(shí)間合理嗎？TimeoutStartSec/TimeoutStopSec 夠用嗎？
[ ] 內(nèi)存限制配了嗎？MemoryMax 和 MemoryHigh 設(shè)了合理的值嗎？
[ ] CPU 限制配了嗎？CPUQuota 設(shè)了上限嗎？
[ ] LimitNOFILE 夠大嗎？高并發(fā)服務(wù)至少 65536
[ ] NoNewPrivileges=yes 加了嗎？
[ ] ProtectSystem=strict 加了嗎？ReadWritePaths 列全了嗎？
[ ] 日志速率限制配了嗎？LogRateLimitBurst 設(shè)了嗎？
[ ] systemd-analyze security 跑過(guò)了嗎？評(píng)分在 3 分以?xún)?nèi)嗎？

8.3 進(jìn)階學(xué)習(xí)方向

Service 文件寫(xiě)好只是起點(diǎn)，systemd 的能力遠(yuǎn)不止于此。以下幾個(gè)方向在生產(chǎn)環(huán)境中有明確的落地價(jià)值，值得持續(xù)跟進(jìn)。

1. systemd-nspawn 輕量級(jí)容器

systemd-nspawn 可以理解為"systemd 原生的容器運(yùn)行時(shí)"。它不需要 Docker 或 containerd，直接用一個(gè)目錄樹(shù)作為根文件系統(tǒng)就能啟動(dòng)一個(gè)隔離的 Linux 環(huán)境。典型場(chǎng)景是構(gòu)建環(huán)境隔離和遺留應(yīng)用封裝——比如在 RHEL 9 的宿主機(jī)上跑一個(gè) CentOS 7 的 nspawn 容器來(lái)編譯老項(xiàng)目，或者把一個(gè)不方便容器化的傳統(tǒng) Java 應(yīng)用丟進(jìn) nspawn 里做資源隔離。machinectl命令管理 nspawn 實(shí)例，systemd-nspawn@.service模板讓它和普通 Service 一樣被 systemctl 管理。相比 Docker，nspawn 的優(yōu)勢(shì)在于和 systemd 生態(tài)的深度集成——日志走 journald、資源限制走 cgroup slice、網(wǎng)絡(luò)走 systemd-networkd，運(yùn)維工具鏈完全統(tǒng)一。

2. Portable Services

Portable Services 是 systemd 240+ 引入的特性，目標(biāo)是在"傳統(tǒng) Service 文件"和"完整容器化"之間找一個(gè)平衡點(diǎn)。它把應(yīng)用和依賴(lài)打包成一個(gè) OS 鏡像（通常是 raw 或 squashfs 格式），通過(guò)portablectl attach掛載到宿主機(jī)上，自動(dòng)生成對(duì)應(yīng)的 Service/Timer 文件。應(yīng)用運(yùn)行時(shí)共享宿主機(jī)內(nèi)核但使用自己的用戶(hù)空間庫(kù)，既解決了依賴(lài)沖突問(wèn)題，又不需要完整的容器編排棧。對(duì)于邊緣計(jì)算節(jié)點(diǎn)、嵌入式網(wǎng)關(guān)這類(lèi)資源受限且不適合跑 K8s 的場(chǎng)景，Portable Services 是一個(gè)務(wù)實(shí)的選擇。

3. systemd-sysext 和 Composefs

systemd 254+ 的 sysext（System Extensions）機(jī)制允許在不可變根文件系統(tǒng)上疊加擴(kuò)展層，配合 Composefs 實(shí)現(xiàn)內(nèi)容尋址的只讀文件系統(tǒng)疊加。這個(gè)方向和 Flatcar Container Linux、Fedora CoreOS 等不可變基礎(chǔ)設(shè)施操作系統(tǒng)密切相關(guān)。如果團(tuán)隊(duì)在推進(jìn)不可變基礎(chǔ)設(shè)施或 GitOps 驅(qū)動(dòng)的節(jié)點(diǎn)管理，sysext 是繞不開(kāi)的技術(shù)點(diǎn)。

8.4 參考資料

systemd 官方文檔- 最權(quán)威的參數(shù)說(shuō)明

systemd.service(5)- Service 文件完整參數(shù)列表

systemd.exec(5)- 執(zhí)行環(huán)境配置（安全加固參數(shù)在這里）

systemd.resource-control(5)- 資源限制參數(shù)

Arch Wiki - systemd- 社區(qū)維護(hù)的實(shí)用指南

systemd-nspawn(1)- nspawn 容器完整參數(shù)說(shuō)明

Portable Services 文檔- Portable Services 設(shè)計(jì)文檔和使用指南

systemd-sysext(8)- 系統(tǒng)擴(kuò)展層管理工具

六、總結(jié)

6.1 技術(shù)要點(diǎn)回顧

回頭看整篇文章，有幾個(gè)核心認(rèn)知需要釘死：

Unit 文件三段式結(jié)構(gòu)（[Unit]/[Service]/[Install]）是基礎(chǔ)中的基礎(chǔ)。[Unit]管依賴(lài)和描述，[Service]管運(yùn)行行為，[Install]管啟用方式。寫(xiě) Service 文件的第一步不是去查參數(shù)，而是先把這三個(gè) Section 的職責(zé)分清楚。搞混了職責(zé)，參數(shù)放錯(cuò) Section，systemd 不會(huì)報(bào)錯(cuò)但也不會(huì)生效，排查起來(lái)浪費(fèi)時(shí)間。

Service Type 選擇直接決定 systemd 對(duì)進(jìn)程生命周期的判定邏輯。大多數(shù)現(xiàn)代應(yīng)用（Go 二進(jìn)制、Node.js、Python 腳本）直接用simple就夠了，進(jìn)程在前臺(tái)跑，PID 1 直接追蹤。傳統(tǒng) daemon 類(lèi)程序（比如老版本的 MySQL、Nginx）會(huì) fork 子進(jìn)程后父進(jìn)程退出，這種必須用forking并配合PIDFile。一次性初始化腳本（建目錄、改權(quán)限、跑遷移）用oneshot，配合RemainAfterExit=yes讓 systemd 認(rèn)為服務(wù)處于 active 狀態(tài)。Type 選錯(cuò)了，輕則systemctl status顯示狀態(tài)不對(duì)，重則 systemd 誤判進(jìn)程已死反復(fù)重啟。

資源限制和安全加固不是錦上添花，是生產(chǎn)級(jí)配置的標(biāo)配。CPUQuota防止單個(gè)服務(wù)吃滿(mǎn)所有核心拖垮整機(jī)，MemoryMax在 OOM 之前主動(dòng)干掉失控進(jìn)程，ProtectSystem=strict把根文件系統(tǒng)鎖成只讀，PrivateTmp=yes隔離臨時(shí)目錄防止跨服務(wù)信息泄露。這些配置的成本幾乎為零，但缺了它們，一個(gè)失控的服務(wù)就能把整臺(tái)機(jī)器拉下水。

Timer 單元完全可以替代 cron，且在所有維度上更優(yōu)。cron 的問(wèn)題在于：沒(méi)有日志集成（輸出丟了就是丟了）、沒(méi)有依賴(lài)管理（不能聲明"等網(wǎng)絡(luò)就緒再跑"）、沒(méi)有資源限制（定時(shí)腳本跑飛了沒(méi)人管）、錯(cuò)過(guò)的任務(wù)不會(huì)補(bǔ)執(zhí)行。systemd Timer 把這些問(wèn)題全部解決了，Persistent=yes一個(gè)參數(shù)就能處理機(jī)器關(guān)機(jī)期間錯(cuò)過(guò)的任務(wù)，OnCalendar的語(yǔ)法比 crontab 的五星表達(dá)式可讀性強(qiáng)得多。2026 年了，新項(xiàng)目沒(méi)有理由再用 cron。

6.2 進(jìn)階學(xué)習(xí)方向

systemd 的能力邊界遠(yuǎn)不止 Service 文件。以下三個(gè)方向在生產(chǎn)環(huán)境中有明確的落地價(jià)值，值得持續(xù)跟進(jìn)。

1. systemd-nspawn 輕量級(jí)容器

systemd 自帶的容器運(yùn)行時(shí)，不依賴(lài) Docker 或 containerd，直接用一個(gè)目錄樹(shù)作為根文件系統(tǒng)就能拉起隔離環(huán)境。典型場(chǎng)景是構(gòu)建環(huán)境隔離和遺留應(yīng)用封裝。和 Docker 相比，nspawn 的核心優(yōu)勢(shì)在于和 systemd 生態(tài)的深度集成——日志走 journald、資源限制走 cgroup slice、網(wǎng)絡(luò)走 systemd-networkd，運(yùn)維工具鏈完全統(tǒng)一，不需要額外引入一套容器編排體系。對(duì)于不需要鏡像分發(fā)能力、只需要本地隔離的場(chǎng)景，nspawn 比 Docker 更輕量也更省心。

2. Portable Services（可移植服務(wù)單元）

systemd 240+ 引入的特性，定位在"裸 Service 文件"和"完整容器化"之間。把應(yīng)用和依賴(lài)打包成 OS 鏡像，通過(guò)portablectl attach掛載到宿主機(jī)，自動(dòng)生成對(duì)應(yīng)的 Service/Timer 文件。應(yīng)用共享宿主機(jī)內(nèi)核但使用自己的用戶(hù)空間庫(kù)，既解決依賴(lài)沖突又不需要完整的容器編排棧。對(duì)于邊緣計(jì)算節(jié)點(diǎn)、嵌入式網(wǎng)關(guān)這類(lèi)資源受限且不適合跑 K8s 的場(chǎng)景，Portable Services 是一個(gè)務(wù)實(shí)的選擇。

3. systemd-homed 用戶(hù)目錄管理

systemd 245+ 引入的用戶(hù)目錄管理方案，把用戶(hù)的家目錄封裝成一個(gè)可加密、可遷移的獨(dú)立單元（LUKS 加密鏡像或 fscrypt 目錄）。用戶(hù)登錄時(shí)自動(dòng)掛載解密，登出時(shí)自動(dòng)卸載鎖定。對(duì)于多用戶(hù)共享的開(kāi)發(fā)服務(wù)器或需要滿(mǎn)足數(shù)據(jù)加密合規(guī)要求的場(chǎng)景，homed 提供了一種比傳統(tǒng)/home+ LDAP 更現(xiàn)代的方案。homectl命令管理用戶(hù)，用戶(hù)記錄以 JSON 格式存儲(chǔ)，支持跨機(jī)器遷移。

6.3 參考資料

systemd 官方文檔- 所有 man page 的在線(xiàn)版本，參數(shù)說(shuō)明以這里為準(zhǔn)

Lennart Poettering - The systemd for Administrators Blog Series- systemd 作者本人寫(xiě)的系列博客，從設(shè)計(jì)哲學(xué)到具體用法都有覆蓋，雖然部分內(nèi)容寫(xiě)于早期版本，但核心思路至今適用

Arch Wiki - systemd- 社區(qū)維護(hù)的實(shí)用指南，示例豐富，更新及時(shí)，遇到具體問(wèn)題時(shí)往往比官方文檔更容易找到答案