Systemd · XB 现场笔记

systemd 依赖要区分激活、顺序与就绪

Fri, 18 Feb 2028 00:00:00 +0000

依赖图需要表达的不只是“先启动数据库”。一种关系决定是否把另一个单元拉进本次任务，一种关系决定启动任务的先后，服务类型则决定怎样才算启动完成。应用就绪还是程序必须真正兑现的承诺。把这些层次混在一起，得到的开机流程可能看起来很有顺序，依赖方实际却仍然在所需条件成立之前就开始运行。

激活、顺序和就绪是独立契约。Requires 加 After 会在提供方激活失败时阻止消费者；通知机制可将有序启动保持到 READY=1。图解基于原文，不是本轮 systemd 实测，也不是持续健康保证。

坏掉的样子

After=provider.service 在双方都有启动任务时，把当前单元排在提供方之后，但它不会主动请求启动提供方。如果本次只激活消费者，单靠这条排序关系，提供方完全可能继续保持非活动。只有消费者确实应当带着提供方一起启动时，才需要另外声明合适的激活依赖；“排在它后面”与“把它启动起来”不能互相替代。

Wants 会请求启动另一个单元，但容忍对方启动失败。Requires 表达更强的关系；与 After 配合时，如果提供方激活失败，依赖它的单元就不会启动。但这两个关键字各自都不会自动建立启动顺序。应根据服务的真实需要选择组合，而不是把所有可选组件都变成硬性前提，也不能把弱依赖误当作一定成功的就绪屏障。

有序启动的强度取决于提供方怎样报告完成。Type=exec 表示程序已经成功执行，不表示数据库完成初始化；Type=notify 可以把启动任务保持到程序发送 READY=1；oneshot 则可以等待有限的设置工作结束。应用必须在承诺的就绪条件真的满足后才发送通知，管理器无法替它判断某个业务表或外部依赖是否已经可用。

快速验证

在一次性的 Linux systemd 环境中，以管理员身份运行下面的完整 Python 脚本。它安装两个临时运行时单元，依次验证六种配置。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。确认两个实验单元名尚未使用；临时文件分别记录提供方是否进入程序、是否就绪，以及消费者实际观察到了什么：

from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess,time

provider='xbcatm-provider-lab.service';consumer='xbcatm-consumer-lab.service'
paths={name:Path('/run/systemd/system')/name for name in (provider,consumer)}
assert all(not p.exists() for p in paths.values())
def ctl(*args,success=True):
 result=subprocess.run(['systemctl',*args],text=True,capture_output=True,timeout=10)
 assert (result.returncode==0)==success,(args,result.stderr)
 return result.stdout.strip()
def value(name,key):return ctl('show',name,'-p',key,'--value')
def wait_for(check):
 deadline=time.monotonic()+5
 while not check():
 assert time.monotonic()<deadline,'state transition timed out'
 time.sleep(0.02)
with TemporaryDirectory(prefix='xbcatm-dependency-',dir='/run') as directory:
 root=Path(directory)
 (root/'provider.py').write_text(r"""from pathlib import Path
import os,socket,sys,time
root=Path(__file__).parent;mode=(root/'mode').read_text()
if mode=='fail': sys.exit(7)
(root/'entered').touch()
if mode in ('exec','notify'):
 while not (root/'gate').exists(): time.sleep(0.01)
(root/'ready').touch()
if mode=='notify':
 address=os.environ['NOTIFY_SOCKET']
 if address.startswith('@'): address='\0'+address[1:]
 with socket.socket(socket.AF_UNIX,socket.SOCK_DGRAM) as notification:
 notification.connect(address);notification.sendall(b'READY=1')
if mode in ('exec','notify'): time.sleep(60)
""")
 (root/'consumer.py').write_text("from pathlib import Path\nr=Path(__file__).parent\n(r/'observed').write_text(str((r/'ready').exists()))\n")
 def install(mode,requirement):
 (root/'mode').write_text(mode)
 kind='oneshot' if mode in ('oneshot','fail') else mode
 paths[provider].write_text(f'[Service]\nType={kind}\nExecStart=/usr/bin/python3 {root}/provider.py\nTimeoutStartSec=5s\n'+('RemainAfterExit=yes\n' if kind=='oneshot' else ''))
 paths[consumer].write_text(f'[Unit]\nAfter={provider}\n'+(f'{requirement}={provider}\n' if requirement else '')+f'[Service]\nType=oneshot\nExecStart=/usr/bin/python3 {root}/consumer.py\n')
 subprocess.run(['systemd-analyze','verify',*[str(p) for p in paths.values()]],check=True)
 ctl('daemon-reload')
 def reset():
 ctl('stop',consumer,provider)
 for name in paths:
 if value(name,'ActiveState')=='failed':ctl('reset-failed',name)
 for name in ('entered','gate','ready','observed'):(root/name).unlink(missing_ok=True)
 pending=None
 install('oneshot','')
 try:
 ctl('start',consumer)
 assert (root/'observed').read_text()=='False' and value(provider,'ActiveState')=='inactive'
 print('After alone: provider not pulled in; consumer ran before readiness')
 reset();install('fail','Wants');ctl('start',consumer)
 assert value(provider,'ActiveState')=='failed' and (root/'observed').read_text()=='False'
 print('Wants plus After: consumer runs despite provider failure')
 reset();install('fail','Requires');ctl('start',consumer,success=False)
 assert value(provider,'ActiveState')=='failed' and not (root/'observed').exists()
 print('Requires plus After: failed provider prevents consumer execution')
 reset();install('oneshot','Requires');ctl('start',consumer)
 assert (root/'observed').read_text()=='True'
 print('oneshot provider: consumer sees completed setup')
 reset();install('exec','Requires');ctl('start',consumer)
 assert (root/'observed').read_text()=='False' and value(provider,'ActiveState')=='active'
 (root/'gate').touch();wait_for(lambda:(root/'ready').exists())
 print('Type=exec provider: process started before application readiness')
 reset();install('notify','Requires')
 pending=subprocess.Popen(['systemctl','start',consumer],text=True,stdout=subprocess.PIPE,stderr=subprocess.PIPE)
 wait_for(lambda:(root/'entered').exists())
 assert pending.poll() is None and not (root/'observed').exists()
 assert value(provider,'ActiveState')=='activating'
 (root/'gate').touch();out,err=pending.communicate(timeout=10)
 assert pending.returncode==0,err
 assert (root/'observed').read_text()=='True'
 print('Type=notify provider: dependent waits for actual READY=1')
 finally:
 reset()
 if pending is not None and pending.poll() is None:pending.communicate(timeout=5)
 for path in paths.values():path.unlink()
 ctl('daemon-reload')

只有 After 时，消费者运行并记录尚未就绪，而提供方保持非活动。这不是提供方启动得慢，而是没有任何激活关系把它拉进来。使用 Wants 加 After 时，提供方故意以状态七退出，消费者仍然执行并记录否。样本程序接受这个观察结果；真实消费者如果确实必须依赖它，随后可能在自己的业务操作中失败，弱依赖不会替业务消除这个事实。

改为 Requires 加 After，相同的提供方失败会使消费者的启动命令返回失败，而且没有生成观察文件。文件缺席证明消费者程序根本没有执行。把提供方改成成功的 oneshot 设置工作，观察结果则变成真，因为此时排序等待的边界就是那段有限设置工作完成，符合消费者需要读取标记的前提。

下一种配置使用 Type=exec。提供方进程已经处于活动状态，却刻意停在应用门槛处，尚未发布就绪标记；消费者仍然开始执行并记录否。之后打开门槛，提供方才就绪。这个安排用明确的状态控制复现了时间差，不依赖随意睡几秒、希望碰巧赶上竞态，因此结果能够稳定区分进程启动与应用完成初始化。

最后使用 Type=notify，提供方在同一个门槛前保持激活中。消费者启动任务仍然等待，其程序也还没有执行。门槛打开后，提供方先发布就绪标记，再由主进程向真实 systemd 通知套接字发送就绪消息。此后消费者才运行，并记录真。这里验证的是管理器实际等待通知的行为，不是把一个文件存在误当成管理器已经收到通知。

脚本逐次验证单元配置，并在结束时清理双方服务；如果断言中断，也会处理仍在等待的任务。这些断言需要真实进程和真实通知通道，不能通过阅读源码确认其实际结果；即使实验通过，也不能证明生产数据库的就绪定义足以满足所有客户端操作。实验检查的是启动边界如何传播，业务条件本身仍须由真正的应用实现与验证。

让依赖关系对应失败语义

就绪定义应以消费者的需求为准。端口开始监听时，迁移、凭据或必要数据可能还未准备好；反过来，等待一个可选的远程组件，也可能不必要地阻止本地服务启动。应明确究竟等待什么条件，哪些失败必须阻止启动，哪些可以交给运行中的应用按既定策略处理，不能只根据组件名称猜测依赖强度。

启动曾经成功，不保证提供方以后一直健康。普通依赖关系不是持续的业务健康检查，条件未满足导致跳过也不同于激活失败。应用需要处理后续连接中断、服务重启和外部系统不可用，而不是把开机依赖图当作永久的可用性保证。已经越过启动边界之后，系统仍然可能进入新的故障状态。

诊断顺序问题时，应检查已载入的单元定义、实际生效的依赖关系和对应启动结果。更改单元文件后重新加载管理器，再验证失败场景与正常启动。没有实际先后要求的服务应保持独立，以便并行启动；只保留真正由完成契约要求的排序边，既避免过早执行，也避免无依据地把整套系统串成一条长链。

来源

systemd 252 单元依赖，排序、激活强度与条件行为，已核验 2026-09-12。
systemd 252 服务类型，exec、oneshot 与通知式启动边界，已核验 2026-09-12。
systemd 252 systemctl，启动任务、状态检查与管理器重载，已核验 2026-09-12。

socket 激活让服务按需启动

Tue, 01 Feb 2028 00:00:00 +0000

一个 socket 单元可以在兼容应用停止时继续提供监听端点，从而减少少用服务的常驻内存与周期性工作。但套接字、内核队列和管理器仍然占用资源，已经安装的软件也仍然需要安全更新。监听可用还取决于绑定成功、权限正确以及 socket 单元保持活动。端口正在监听，只表示客户端有机会请求工作，并不能证明应用已经初始化或能够返回正确结果；这些条件必须分别观察。

交接方式由配置决定。Accept=no 把监听描述符交给守护进程，由它自己接受连接；Accept=yes 则先接受连接，再启动适合处理该连接的服务实例。客户端可能在应用初始化之前完成连接，随后等待响应，甚至等到超时。应测量从连接到应用回复的完整延迟，不能因为交接对客户端接口透明，就推断冷启动和常驻服务在时延、失败诊断或实际资源成本上没有区别。

socket 单元活动时，请求可以启动兼容服务。应用明确定义的空闲退出可使进程停止，后续需求再触发启动；没有空闲退出时，服务仍继续运行。应在真实负载下测量连接至首个响应的冷启动延迟、客户端截止时间和常驻资源。监控可能同时唤醒多个服务，因此需要验证聚合启动负载。仅示意所选机制；原文仍为搁置/待审，不为其错误泛化背书。仅示意选定的原文机制；本轮没有执行示例。

让监听器先等着

socket 单元启动时，systemd 打开 ListenStream 指定的端点。Accept=no 通常由 foo.socket 激活 foo.service 并传递监听器，Service= 可以指定其他服务；Accept=yes 通常使用 foo@.service 模板，为每条接受的流连接生成实例。数据报套接字不采用这种逐连接模型。程序必须匹配选定的描述符契约，不能只因为两个单元名称相近，就认为普通绑定逻辑可以原样使用。

这种分离可以减少启动顺序上的耦合，但不会消除依赖。客户端使用套接字之前，socket 单元必须已经活动并监听，所需的服务、挂载、设备与先后顺序依赖仍然适用。兼容服务启动时，连接可以在有限的内核积压队列中等待，但客户端仍可能在应用就绪前失败或超时。当然积压长度也要调：启动慢的服务遇上开机早期的连接洪峰，溢出起来和普通监听队列一样。

服务按需唤醒

按需激活可以在 socket 保持活动时推迟应用的首次启动，但不会让已运行的守护进程自动休眠，也不会自动停止进入空闲的程序。管理服务、罕用协议处理器是否适合这种方式，要看激活接口、请求截止时间与资源画像。其他依赖或人工启动仍然可能提前激活服务，因此不能把首次连接当成所有环境中唯一的启动入口，更不能从文章标题推导永久的运行限制。

要形成反复节省资源的循环，应用必须明确实现安全的空闲退出，先完成或转交进行中的工作，并让管理器持有的监听器继续可用。socket 单元仍活动时，后续需求可以请求再次启动；没有空闲退出逻辑，守护进程可能在第一次激活后一直常驻。这两种情况都不是零成本状态，也不保证套接字永远不会关闭。应验证待处理请求和退出边界，而不是仅设置一个空闲秒数就认定节省已经成立。

用速度换内存

冷启动预算应从连接开始，一直计算到首个有效应用响应，并在有代表性的负载下比较常驻内存。假设启动三百毫秒能够节省八百 MB，在一种工作负载中可能合适，在另一种场景却可能超过请求期限。二十秒预热对异步任务也许可接受，对交互请求则可能不可用。这些数字只是说明取舍，并不是实测结果或通用决策阈值。

有些工作无法承受启动间隙。健康检查本身可能唤醒服务，也可能在初始化时把端点判为不可用；客户端截止时间和负载均衡策略必须匹配实际启动行为。若稳定响应时间比空闲内存更重要，保持守护进程运行可能更简单。开机预热一次并不会自动实现之后的空闲退出，也不能替代对长时间停用后恢复状态的检查。

坏掉的样子

一轮监控可能同时唤醒很多服务，引发总体 CPU 或内存尖峰。错峰检查可以减少同时到来的需求，单服务启动速率限制则约束该单元反复启动的次数，并不能限制整机并发数量或总内存。过短的空闲超时还可能增加启停抖动。应测试聚合启动负载，并使用合适资源控制，而不是把几个独立单元上的限制误认为全机容量保证。

若守护进程启动时再次绑定已经占用的端点，就可能因地址被占用而失败。程序必须通过原生激活接口或受支持的 inetd 风格接口使用传入的描述符；仅仅继承一个描述符再执行不知情的程序，不会改变它内部的 bind 逻辑。协议适配器需要单独验证，不能承诺一个通用的小包装就能让任意网络守护进程支持激活。

快速验证

下面只是检查草图，前提是另有经过配置与授权的 foo.socket/foo.service，在回环地址的 8080 端口提供健康端点。本文没有给出这组单元的完整配置，本轮也没有执行这些命令：

systemctl status foo.socket foo.service
ss -ltnp | grep ':8080'
curl -m 10 localhost:8080/health; systemctl show foo.service -p ActiveState,ExecMainStartTimestamp

先确认服务未活动、目标套接字正在监听，再核对请求获得预期应用响应，比较前后的运行实例或启动信息。每条命令都要检查结果：分号会在 curl 失败后继续执行 show，因此最后退出状态不能代替请求成功。状态输出本身也不证明健康或启动因果关系，其他激活入口必须一并排除。

来源

systemd.socket 手册，套接字单元官方参考，已核验 2026-06-01。
systemd.service 手册，服务激活、终止与重启行为，已核验 2026-09-05。

systemd-tmpfiles 执行创建与年龄策略

Fri, 10 Dec 2027 00:00:00 +0000

systemd-tmpfiles 用配置文件描述文件系统对象与维护规则。一条规则可以按指定模式创建目录，年龄规则则可以让旧条目符合清理条件，但只有命令实际执行对应操作，效果才会发生。这是一种有用的生命周期策略，不是连续监视器，也不是硬性存储配额。目录已经声明、清理命令曾经运行和磁盘空间始终有界，是三种不能互相替代的事实。

树形图描述原文特定的 d 与 x 年龄清理样例。x 排除不能覆盖显式 r 或 R 删除。执行清理、删除路径名与释放存储是不同事件；本轮绘图没有运行清理。

坏掉的样子

年龄不只是“创建文件多久了”，也不只是“多久没有修改内容”。文档中的默认规则考虑多个时间戳，包括访问与修改时间、文件状态变化时间，以及可获得的创建时间。某个参与判断的时间戳较新，就可能保留一个看起来 mtime 很老的条目。因此，为了测试而改写时间戳，也可能以意外方式改变结果；不能只观察其中一个字段就断定工具应该删除文件。

--create 和 --clean 执行不同操作。创建配置中的目录，不证明里面的旧内容已经清除。下面使用的 d 规则保留目录本身，同时让符合年龄条件的内容参与清理；其他类型有不同删除语义。不能因为都叫“清理”，就随意换成递归移除规则，否则可能把按条件删除变成完全不同的破坏性操作。

年龄清理中的 x 排除规则可以保留匹配目录及其内容，X 则只排除目录本身，没有相同的递归保护。它们也不会覆盖显式 r 或 R 删除规则。判断一次维护会删什么，必须同时阅读最终生效配置与执行操作，而不是只找到某条看起来写着“忽略”的记录，就认定其他规则都不可能影响该路径。

快速验证

在装有 systemd-tmpfiles 的一次性 Linux 环境中，以管理员身份运行下面的 Python 脚本。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。脚本传入一份明确配置和临时 --root，所有创建对象与删除目标都属于本次实验，不会使用当前系统平时执行的 tmpfiles 配置：

from pathlib import Path
from tempfile import TemporaryDirectory
import os,stat,subprocess,time

with TemporaryDirectory(prefix='xbcatm-tmpfiles-') as directory:
 root=Path(directory);config=root/'policy.conf'
 definition='d /work 0750 - - 1s -\nx /work/keep - - - - -\n'
 config.write_text(definition)
 def apply(action):
 result=subprocess.run(['systemd-tmpfiles','--root='+str(root),action,str(config)],capture_output=True,text=True,timeout=10)
 assert result.returncode==0,result.stderr
 apply('--create');work=root/'work'
 assert stat.S_IMODE(work.stat().st_mode)==0o750
 old=work/'old';old.write_text('fixture');past=time.time()-60;os.utime(old,(past,past))
 apply('--clean');assert old.exists()
 print('old atime and mtime alone do not satisfy the default age rule')
 config.write_text(definition.replace('1s','m:1s'));apply('--clean')
 assert not old.exists()
 print('explicit mtime-only age removes the same recently created file')
 config.write_text(definition);old.write_text('aged fixture')
 keep=work/'keep';keep.mkdir();(keep/'preserved').write_text('excluded fixture')
 outside=root/'outside';outside.write_text('outside cleanup tree')
 link=work/'link';link.symlink_to(outside)
 with old.open('rb') as retained:
 time.sleep(1.2)
 fresh=work/'fresh';fresh.write_text('recent fixture')
 apply('--clean')
 assert not old.exists() and not link.is_symlink()
 assert retained.read()==b'aged fixture'
 print('unlinked file remains readable through its already open descriptor')
 assert fresh.read_text()=='recent fixture'
 assert (keep/'preserved').read_text()=='excluded fixture'
 assert outside.read_text()=='outside cleanup tree'
 assert work.is_dir()
 print('aged entries removed; recent file and recursively excluded subtree remain')
 print('symlink removed without following it; target outside the cleaned tree survives')
print('all creation and cleanup occurred in a temporary alternate root')

创建操作在临时根目录内生成模式为 0750 的 /work。随后创建一个文件，把访问与修改时间故意调到过去，默认清理仍然保留它，因为其他相关时间戳较新。仅仅回拨 mtime 和 atime，并不足以让这个文件满足完整默认年龄规则。这一对照可以解释为什么只用 touch 修改时间的测试，有时得不到想象中的删除结果。

只把年龄说明改成 m:1s，选择文件修改时间后，再次清理就删除了同一个刚创建的文件。这证明时间戳选择改变的是策略，不是显示格式。随后脚本恢复默认规则；只看 mtime 是需要结合应用访问模式评估的有意选择，并不天然比默认规则更好。尤其是读多写少的数据，采用不同时间基准可能产生明显不同的保留结果。

下一阶段创建普通文件、排除子树，以及指向清理树外另一份无害文件的符号链接。等待相关时间戳充分变旧，再创建新文件并清理，旧普通条目和链接消失，新文件及排除子树仍在，链接指向的目标也保持完整，配置中的 /work 目录本身继续存在。这样同时核对需要删除与必须保留的两类对象，避免验证只有单一成功路径。

清理期间，普通旧文件始终被一个描述符打开。虽然路径已经消失，已有描述符仍能读到原来的内容，直到它被关闭。删除目录项与释放所有打开引用背后的存储，是不同事件。因此，如果清理确实删掉了名字，却没有释放预期空间，仍持有已删文件的进程就是一个需要检查的具体原因，不能仅靠再次扫描目录判断没有数据占用。

脚本比较真实模式、路径存在性和内容，不会只把零退出码当成预期删除已经完成。结束时删除整个替代根目录，主机已有临时文件及日常策略都未改变。实验范围保持明确，也让多次重跑能够核对相同的创建、判断与清理语义，而不是碰巧依赖机器上某份未知配置。

让维护策略匹配数据生产者

应检查发行版的 tmpfiles 创建与清理单元，明确规则什么时候真正执行。文件在一秒后符合条件，不代表恰好一秒后就被删除，清理频率和当时负载都会影响时点。定时器未活动或清理命令失败，也可能让符合条件的文件长期留下。年龄阈值与调度周期需要一起理解，不能只改其中一个数字就承诺结果。

年龄策略不能限制生产者在两次清理之间写入多少字节。高写入量、近期访问、排除路径和未关闭描述符都会影响实际保留空间。容量必须有界时，应采用合适的存储限制并监控磁盘，同时排查产生数据的应用，不能一味缩短保留时间，直到有用诊断资料被提前删掉，却仍没有控制写入来源。

应区分服务的运行时数据、缓存与持久状态。重启后仍然需要的数据，不应误继承临时文件删除策略。如果受管理服务目录已经表达了所需所有权和生命周期，就应复用该机制。增加 tmpfiles 规则应对应具体维护需求，并同时验证符合条件的数据确实被删除、必须保留的数据仍然存在，让策略和业务语义保持一致。

来源

systemd 252 tmpfiles.d，创建类型、按时间戳判断年龄、排除规则与符号链接，已核验 2026-09-12。
systemd 252 systemd-tmpfiles，分别执行创建与清理、替代根目录与定时集成，已核验 2026-09-12。

systemd oneshot 完成的是一次激活

Sun, 28 Nov 2027 00:00:00 +0000

Type=oneshot 服务表达一段有限工作，启动命令成功结束后，本次启动才算完成。因此，它适合初始化步骤，以及依赖方需要等待任务结束的定时工作。oneshot 描述的是一次激活的进程模型，不会建立永久记录来阻止任务在重启、再次激活或机器重新开机后重跑。名字中的“一次”，不能直接推导为业务意义上的“永远只做一次”。

oneshot 完成的是一次激活。后续命令失败不会撤销先前副作用，保留的 active/exited 状态也可以没有存活主进程。三个命令和 PID 0 来自原文样例；本轮绘图没有执行服务。

坏掉的样子

成功的 oneshot 通常在命令完成后变为非活动状态，这是任务已经结束的正常表现，不是守护进程崩溃的证据。设置 RemainAfterExit=yes 后，管理器会在命令退出后仍把单元记为活动。因此，active (exited) 可以完全没有主进程；如果监控假定任何活动服务都必须有一个存活 PID，就会错误判断这种单元类型。

oneshot 允许多条 ExecStart，并按顺序执行。采用普通成功规则时，某条命令失败会阻止后续启动命令运行，并让本次激活失败。但前面的命令可能已经修改文件或数据库，systemd 不会回滚这些副作用。重新尝试整个激活，就可能重复之前已经成功的部分，不能把管理器的失败状态误当作业务事务已经全部撤销。

RemainAfterExit 保存的是管理器状态，不是持久的恰好一次执行保证。再次启动已经活动的单元不会重跑，重启却会。定时器指向一个仍然活动的 oneshot 时，也不会把每个到达的时间点都变成另一次执行。只有它确实代表一个持续成立的状态时，才适合保留活动标记；需要反复触发的定时工作，应在各次执行之间回到非活动状态。

快速验证

在由 systemd 管理的临时 Linux 环境中，以管理员身份运行下列 Python 脚本。它创建一个运行时单元和临时步骤程序。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测；执行前确认示例单元文件名尚未使用。每个步骤先记录自身名字，第二步随后故意失败：

from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess

unit='xbcatm-oneshot-lab.service';path=Path('/run/systemd/system')/unit
assert not path.exists()
def ctl(*args,success=True):
 result=subprocess.run(['systemctl',*args],text=True,capture_output=True,timeout=10)
 assert (result.returncode==0)==success,(args,result.stderr)
 return result.stdout.strip()
def value(key):return ctl('show',unit,'-p',key,'--value')
with TemporaryDirectory(prefix='xbcatm-oneshot-',dir='/run') as directory:
 root=Path(directory);worker=root/'step.py';calls=root/'calls'
 worker.write_text("""from pathlib import Path
import sys
root=Path(__file__).parent
with (root/'calls').open('a') as output: output.write(sys.argv[1]+'\\n')
if sys.argv[1]=='second' and not (root/'healthy').exists(): sys.exit(7)
""")
 definition=f'''[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutStartSec=3s
ExecStart=/usr/bin/python3 {worker} first
ExecStart=/usr/bin/python3 {worker} second
ExecStart=/usr/bin/python3 {worker} third
'''
 path.write_text(definition)
 try:
 subprocess.run(['systemd-analyze','verify',str(path)],check=True)
 ctl('daemon-reload');ctl('start',unit,success=False)
 assert calls.read_text().splitlines()==['first','second']
 assert value('Result')=='exit-code' and value('ExecMainStatus')=='7'
 print('second command fails; third command does not run')
 (root/'healthy').touch();ctl('reset-failed',unit);ctl('start',unit)
 assert calls.read_text().splitlines()==['first','second','first','second','third']
 assert (value('ActiveState'),value('SubState'),value('MainPID'))==('active','exited','0')
 before=calls.read_text();ctl('start',unit);assert calls.read_text()==before
 print('active/exited with PID 0; repeated start does not rerun')
 ctl('restart',unit)
 assert calls.read_text()==before+'first\nsecond\nthird\n'
 print('restart executes all commands again')
 ctl('stop',unit);path.write_text(definition.replace('RemainAfterExit=yes','RemainAfterExit=no'))
 ctl('daemon-reload');before=calls.read_text()
 for _ in range(2):
 ctl('start',unit)
 assert value('ActiveState')=='inactive' and value('Result')=='success'
 assert calls.read_text()==before+'first\nsecond\nthird\n'*2
 print('without RemainAfterExit: two starts, two successful executions')
 finally:
 ctl('stop',unit)
 if value('ActiveState')=='failed':ctl('reset-failed',unit)
 path.unlink();ctl('daemon-reload')

第一次激活只留下 first 和 second 两项记录，启动命令返回失败，退出状态为七；第三条命令没有运行。此前的记录仍然存在，让我们直接看见部分副作用，而不是假设激活失败意味着什么都没做过。这对于会修改真实数据的任务尤其关键：管理器状态并不能描述全部业务影响。

创建健康标记后再重试，三个步骤都被记录。完整文件此时是上次留下的两项，加上新的一组三项。单元状态变为活动、已退出，主进程编号为零。这组状态说明管理器保留了成功激活的记录，不是说工作程序仍在后台运行，也不能用来判断某个隐藏子进程是否继续提供服务。

单元仍活动时，再执行一次启动，记录不会变化；重启同一单元则追加一整组步骤。这直接反驳了“把迁移写成 oneshot，就能保证机器生命周期内只执行一次”的理解。管理器只是按照新的激活请求，再次执行已经声明的命令，并没有负责判断业务变更以前是否完成过。

接着脚本停止单元，把 RemainAfterExit 改成否，重新加载管理器配置，再启动两次。两次均成功结束并回到非活动状态，日志增加两组完整步骤。这适合每次受到触发就执行、完成后等待下一次触发的任务。是否再次运行，由调度与当前激活状态决定，而不是由类型名称永久封存。

示例显式设置三秒启动超时。在所核验的版本中，oneshot 默认没有启动超时，因此卡住的命令可能无限期占着激活任务。实际工作应设置符合业务时长的边界，不要把这个小实验里的三秒直接复制到耗时很长的数据库迁移，否则会把正常工作中途终止，并留下需要判断的部分结果。

任务自身仍要保证正确性

每条启动命令应是有限、前台运行的工作。如果任务需要启动长期工作者，就应给那个工作者合适的服务生命周期，而不是根据父进程成功退出来推断它会持续运行。单元类型、命令完成与业务结果，应当描述同一件事；管理器只能按声明的进程协议工作，不能猜测业务实际上希望保持什么状态。

数据库迁移是否已经执行，应依靠迁移记录、事务语义和并发控制判断。一个管理器保留的活动状态，无法协调多台主机，也无法跨越所有操作变化持续保证只做一次。应在副作用真正发生的层面让重试安全，并保留足够结果来诊断部分完成，特别是前一条命令已成功、后一条失败的情形。

检查服务记录的结果和应用输出，不要只检查定时器或依赖是否触发过它。定时器可以保持活动，同时最近一次工作已经失败。安装、调度与执行是不同的保证，应在开机流程或发布流程依赖这项任务之前，同时验证成功路径与失败路径，而不是只看到某一次启动返回零就结束验证。

来源

systemd 252 服务类型，oneshot 命令顺序、保留状态与启动超时，已核验 2026-09-12。
systemd 252 systemctl，启动、重启与管理器重载行为，已核验 2026-09-12。
systemd 252 定时器，目标服务已经活动时的激活行为，已核验 2026-09-12。

Socket 激活把监听器交给兼容的服务

Mon, 08 Nov 2027 00:00:00 +0000

Socket 激活让 systemd 在应用进程启动之前先打开监听端点。端点上的活动随后可以触发兼容服务，并把管理器已经持有的套接字描述符传给它。这里真正分开的，是监听器所有权与应用生命周期。端点已经开放，还不证明应用完成初始化、接受了请求或生成了正确响应；传输层能连接与业务层能工作，需要分别验证。

socket 单元先活动，对应服务的 MainPID 为 0。首个连接触发工作进程，它校验 LISTEN_PID、LISTEN_FDS 1 及监听中的 FD 3，处理有完整边界的请求并回复。工作进程主动退出，管理器保留监听器；后续连接启动不同的进程，仍使用 FD 3。重复绑定会得到 EADDRINUSE。停止 socket 后移除路径，是因为本例明确配置了 RemoveOnStop=yes。仅示意选定的原文机制；本轮没有执行示例。

坏掉的样子

应用必须理解激活协议。如果守护进程无条件再次绑定同一个端点，就可能因为管理器已经占用而失败。激活机制把绑定责任移到 socket 单元，并不会消除地址冲突、接口缺失、文件系统权限错误，或其他导致首次绑定失败的条件。因此不能把“端口先开好”写成所有启动竞态已经自动消失，真正的监听建立仍然可能失败。

使用 Accept=no 时，服务接收监听套接字并自行接受连接；Accept=yes 则为合适的流套接字支持按连接启动服务实例的模式。它们对应不同的应用契约，不能互换。任何一种模式都不意味着任意守护进程会自动判断空闲、完成工作后退出，或者只在安全时重新启动。是否退出，以及退出时哪些请求已经完成，仍然由应用行为决定。

排队连接也有边界。客户端可以在应用初始化完成之前建立传输状态，随后因为等不到响应而超时。Socket 激活不会让数据库依赖自动就绪，也不会提供无限请求队列。真实工作负载仍需要合适的服务依赖、就绪逻辑与客户端超时；先拥有监听器只是交付链路的一部分，不等于依赖链已经完整兑现。

快速验证

在 PID 1 为 systemd 的一次性 Linux 系统中，以管理员身份运行下面的 Python 脚本。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。脚本在临时目录中使用 Unix 流套接字，创建唯一命名的 socket 与 service，不暴露公共 TCP 端口。工作程序有意只处理一条以换行结尾的消息，然后退出：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,socket,subprocess,time,uuid

name='xbcatm-socket-'+uuid.uuid4().hex[:8];service=name+'.service';unit=name+'.socket'
paths={n:Path('/run/systemd/system')/n for n in (service,unit)}
assert all(not p.exists() for p in paths.values())
def run(*args):
 result=subprocess.run(args,capture_output=True,text=True,timeout=10)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def value(key):return run('systemctl','show',service,'-p',key,'--value')
def wait_inactive():
 deadline=time.monotonic()+5
 while value('ActiveState')!='inactive':
 assert time.monotonic()<deadline,'service did not exit';time.sleep(0.02)
with TemporaryDirectory(prefix=name+'-',dir='/run') as directory:
 root=Path(directory);endpoint=root/'listener.sock';worker=root/'worker.py'
 worker.write_text(r'''from pathlib import Path
import errno,json,os,socket
root=Path(__file__).parent
assert int(os.environ['LISTEN_PID'])==os.getpid()
assert int(os.environ['LISTEN_FDS'])==1
with socket.socket(fileno=3) as listener:
 assert listener.getsockopt(socket.SOL_SOCKET,socket.SO_ACCEPTCONN)==1
 with socket.socket(socket.AF_UNIX,socket.SOCK_STREAM) as duplicate:
 try:duplicate.bind(str(root/'listener.sock'))
 except OSError as error:assert error.errno==errno.EADDRINUSE
 else:raise AssertionError('unexpected duplicate bind success')
 connection,_=listener.accept()
 with connection,connection.makefile('rb') as incoming:
 message=incoming.readline(256);assert message.endswith(b'\n')
 connection.sendall(b'ack '+message)
 (root/(str(os.getpid())+'.json')).write_text(json.dumps({'pid':os.getpid(),'fd':3,'message':message.decode().strip()}))
''')
 paths[unit].write_text(f'[Socket]\nListenStream={endpoint}\nAccept=no\nSocketMode=0600\nRemoveOnStop=yes\n')
 paths[service].write_text(f'[Service]\nType=exec\nExecStart=/usr/bin/python3 {worker}\n')
 try:
 run('systemd-analyze','verify',*[str(p) for p in paths.values()]);run('systemctl','daemon-reload')
 run('systemctl','start',unit)
 assert endpoint.is_socket() and value('ActiveState')=='inactive' and value('MainPID')=='0'
 print('socket listening while service has no process')
 for message in ('first','second'):
 with socket.socket(socket.AF_UNIX,socket.SOCK_STREAM) as client:
 client.settimeout(5);client.connect(str(endpoint));client.sendall((message+'\n').encode())
 with client.makefile('rb') as response:assert response.readline()==('ack '+message+'\n').encode()
 wait_inactive();assert endpoint.is_socket() and value('Result')=='success'
 records=[json.loads(p.read_text()) for p in root.glob('*.json')]
 assert len(records)==2 and len({row['pid'] for row in records})==2
 assert {row['message'] for row in records}=={'first','second'}
 assert all(row['fd']==3 for row in records)
 print('two requests: two deliberate one-request workers; each uses inherited listening fd 3')
 print('rebinding the occupied socket fails; manager retains listener between workers')
 run('systemctl','stop',unit);assert not endpoint.exists()
 print('stopping socket removes its endpoint with RemoveOnStop=yes')
 finally:
 run('systemctl','stop',unit,service)
 for name,path in paths.items():
 if run('systemctl','show',name,'-p','ActiveState','--value')=='failed':run('systemctl','reset-failed',name)
 path.unlink()
 run('systemctl','daemon-reload')

只启动 socket 单元后，端点已经存在，对应服务却仍为非活动，主进程编号为零。第一个客户端连接随后触发工作程序执行，客户端发送有完整边界的消息，并检查应用回复，不会仅凭 connect 成功就认定服务可用。流式连接并不自动划分应用消息，所以样本明确使用换行作为这一小型协议的结束标记。

工作程序检查 LISTEN_PID 是否指向自身，确认 LISTEN_FDS 声明一个继承描述符，然后包装编号三的描述符，并验证它已经处于监听状态。这些编号与环境检查符合原生激活契约。生产程序如果接收多个描述符，还应识别和验证自己真正期待的套接字，不能只看存在一个整数就随意当成某个固定用途的连接。

再次绑定同一个 Unix 套接字路径时，会得到 EADDRINUSE。工作程序随后继续使用继承的监听器，返回预期回复。这项受控失败说明，应用不能既保留普通启动流程中无条件 bind 的逻辑，又假定激活机制会神奇地避开冲突。监听器已经由谁建立，必须在程序启动协议中有明确答案。

工作进程成功退出后，管理器仍然持有监听端点。第二次连接启动新的工作进程，处理第二条消息后同样退出。记录中的进程编号不同，两次都使用了描述符三。出现两个进程，是因为本例程序有意每次只处理一个请求；并不是 Accept=no 自身要求每个连接必须创建新进程。普通长期运行的兼容服务可以继续接受后续连接。

停止 socket 单元后，端点被移除，因为样本显式设置了 RemoveOnStop=yes。脚本再停止可能残留的实验单元，删除运行时定义和临时文件。这是样例配置并断言的清理行为，不能扩大为所有套接字路径都会在任意相关守护进程退出时自动消失；端点与服务的生命周期需要分别理解。

同时设计交接与停止

长期运行的守护进程应按自己的集成契约接受并服务继承套接字，由正常关闭流程决定什么时候关闭描述符。如果希望应用空闲后退出，就要验证空闲判定和进行中请求的处理，管理器无法推断业务工作何时安全完成。节省常驻进程资源，是匹配了应用生命周期之后可能得到的结果，不是只启用 socket 单元便自动获得的保证。

维护时，停止后续激活与终止当前工作是不同决定，应同时检查 socket 和 service。服务也可能被其他依赖或操作者显式启动，而仍然活动的监听器可能再次触发它。应测试真实部署的单元关系，不能以为停止一个眼前的进程就永久禁用了端点，否则维护期间仍可能出现新的业务执行。

设置合适的端点权限与服务身份。传递已经打开的描述符，可以让监听建立权限与应用执行权限不同，但不会自动把服务变成沙箱。应验证真实请求处理、重新启动、排队客户端的结果和失败诊断。实际优势在于监听器与进程之间存在明确、可测试的交接，而不是自动就绪或完全没有资源成本。

来源

systemd 252 systemd.socket，监听器所有权、Accept 模式、激活与端点移除，已核验 2026-09-12。
systemd 252 sd_listen_fds，继承描述符编号、数量与进程身份检查，已核验 2026-09-12。
systemd 252 systemd.service，服务启动类型与进程生命周期，已核验 2026-09-12。

systemd 重启策略要明确失败与限流规则

Sun, 07 Nov 2027 00:00:00 +0000

重启策略决定当前进程结束后，服务管理器是否应该再启动一个进程。它可以帮助恢复短暂故障，但修不好缺失配置或必然重复的程序错误。一个有用的契约需要分别回答三个问题：哪些结束方式应该重试、重试前等多久、一个时间窗口内允许启动多少次。这些设置各管一件事，不能把它们笼统理解为“失败后会自己恢复”。

先分类结束原因，再应用固定延迟和窗口启动上限。100 毫秒、十秒、三次启动来自原文 systemd 252.39 样例，图形不按时间比例，也不是本轮实测或生产推荐值。清除限流前先读取并修复失败原因。

坏掉的样子

Restart=on-failure 不代表任何信号结束都会重启。对于 oneshot 以外的服务类型，通常的 SIGHUP、SIGINT、SIGTERM 和 SIGPIPE 终止，默认被视为干净结束；非零退出码，以及 SIGKILL 这样的异常信号，才符合默认失败规则。SuccessExitStatus 和专门的重启例外指令还能改变分类，因此要检查最终生效的单元，不能只看其中一行策略名字。

on-abnormal 也不是 on-failure 的“更严格同义词”：它排除了普通的非零进程退出码，保留异常信号以及部分超时或看门狗故障。选择依据应是程序怎样报告可恢复失败与主动结束。如果进程始终存活，却已经不再提供有用工作，还需要单独配置发现这种状态的机制；基于退出的重启逻辑不会自动推断业务是否健康。

RestartSec 提供下一次重启前的等待时间。在下面的 systemd 252 实验里，它是固定延迟，不是越来越长的指数退避。StartLimitIntervalSec 和 StartLimitBurst 限制窗口内的启动次数，手动启动也算在内；它们既不是整个生命周期的重试预算，也不会在超限后自动预约下一窗口边界再尝试一次。限流与恢复触发应分别理解。

快速验证

在一次性的 Linux systemd 环境中，以管理员身份运行这个 Python 脚本。它创建带有唯一名字的运行时单元和临时工作程序，完成后删除。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。工作程序起初每次都以状态七退出，同时记录每次真实调用：

from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess,time,uuid

unit='xbcatm-restart-lab-'+uuid.uuid4().hex[:8]+'.service'
path=Path('/run/systemd/system')/unit
assert not path.exists()
def ctl(*args):
 result=subprocess.run(['systemctl',*args],text=True,capture_output=True,timeout=10)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def value(key):return ctl('show',unit,'-p',key,'--value')
def wait_for(check):
 deadline=time.monotonic()+5
 while not check():
 assert time.monotonic()<deadline,'state transition timed out'
 time.sleep(0.02)
with TemporaryDirectory(prefix='xbcatm-restart-',dir='/run') as directory:
 root=Path(directory);worker=root/'worker.py';calls=root/'calls';healthy=root/'healthy'
 worker.write_text("""from pathlib import Path
import sys,time
root=Path(__file__).parent
with (root/'calls').open('a') as output: output.write('started\\n')
if not (root/'healthy').exists(): sys.exit(7)
time.sleep(60)
""")
 path.write_text(f'''[Unit]
StartLimitIntervalSec=10s
StartLimitBurst=3
[Service]
Type=exec
ExecStart=/usr/bin/python3 {worker}
Restart=on-failure
RestartSec=100ms
''')
 try:
 ctl('daemon-reload');ctl('start',unit)
 wait_for(lambda: value('ActiveState')=='failed')
 assert calls.read_text().splitlines()==['started']*3
 assert value('Result')=='exit-code'
 subprocess.run(['journalctl','--sync'],check=True)
 logs=subprocess.run(['journalctl','-u',unit,'--no-pager','-o','cat'],capture_output=True,text=True,check=True).stdout
 assert 'Start request repeated too quickly' in logs
 print('three starts; failed/exit-code with start-rate-limit journal message')
 healthy.touch();ctl('reset-failed',unit);ctl('start',unit)
 wait_for(lambda: len(calls.read_text().splitlines())==4)
 first=value('MainPID');assert first!='0'
 ctl('kill','--kill-who=main','--signal=TERM',unit)
 wait_for(lambda: value('ActiveState')=='inactive')
 assert value('NRestarts')=='0'
 print('on-failure treats ordinary SIGTERM as clean; no restart')
 ctl('start',unit);first=value('MainPID')
 ctl('kill','--kill-who=main','--signal=KILL',unit)
 wait_for(lambda: value('MainPID') not in ('0',first))
 assert value('NRestarts')=='1'
 print('SIGKILL triggers one restart')
 ctl('stop',unit);time.sleep(0.2)
 assert value('ActiveState')=='inactive'
 print('explicit stop remains stopped')
 finally:
 ctl('stop',unit)
 if value('ActiveState')=='failed':ctl('reset-failed',unit)
 path.unlink();ctl('daemon-reload')

第一阶段允许十秒内启动三次，自动重启间隔设得很短且固定。程序自己写出的文件恰好包含三项记录，所以这里统计的是实际进程启动，而不是先猜某个管理器计数器的含义，再把那个数字当作执行证据。之后单元留在失败状态，日志明确说明启动请求过于频繁，新的启动被速率规则挡住。

保留样例预期最终 Result=exit-code，同时在日志中出现启动限流消息。v252.39 的 service_enter_dead 会保留此前的非成功结果，这支持该结果存在的可能性，但不能复现原文声称的运行。应结合单元状态、程序调用记录和相应日志判断，不要假定不同版本、不同失败路径都给出完全相同的单一诊断标签。

随后脚本通过创建健康标记修复样本程序，清除失败状态和速率计数，再次启动。这一次进程保持运行。向它发送普通 SIGTERM 后，单元变为非活动，on-failure 没有安排自动重启；之后另一次运行收到 SIGKILL，则确实产生一个替代进程。实验由此区分信号分类与“只要进程消失就重启”的错误理解。

最后，显式执行 systemctl stop，等待超过重启延迟，服务依然保持停止。管理器要求的关闭不会被当成需要立刻逆转的崩溃。清理时也只在失败状态仍存在时重置它，因为没有引用的非活动单元可能已经被管理器卸载，不能把不存在的失败状态当作必须成功清除的对象。

恢复服务，而不是只清空计数

清除证据前先阅读失败原因。检查配置命令、退出状态、最近一次运行日志和依赖错误，修正原因或部署已知可工作的版本，再决定是否值得立即重试并清除限流。反复清空计数，却不改变导致失败的条件，只会把原本有界的崩溃循环变成由操作者手动驱动的循环，服务本身并没有因此更可靠。

持续不可用和过量重启应交给实际负责该服务的监控系统告警。这里展示的单元设置并不会自动创建告警接收渠道。保留足够诊断上下文，用来区分程序无法执行、应用自行退出、资源耗尽和主动停止，同时避免把敏感配置写进日志。计数和退出码应帮助定位故障，而不是替代故障含义本身。

延迟与窗口大小应匹配启动成本和依赖行为。一次很快的重试可能恢复单点短暂错误，也可能在共享依赖故障时放大负载。应在真正部署的配置中验证恢复和终止，包括所有覆盖文件。只有应用恢复了有用工作，而且仍能受控停止，策略才达到目的；进程编号反复变化，并不是成功交付服务的充分证据。

来源

systemd 252 服务重启规则，退出分类、固定等待时间和重启例外，已核验 2026-09-12。
systemd 252 单元启动限制，窗口限流、手动启动与计数清除，已核验 2026-09-12。
systemd 252 systemctl，停止、状态读取与失败状态重置，已核验 2026-09-12。
systemd-stable v252.39 服务源码，service_enter_dead 保留此前非成功结果；仅属源码证据，已核验 2026-10-19。

systemd journal 的保留范围需要明确约定

Tue, 26 Oct 2027 00:00:00 +0000

systemd journal 把消息与结构化元数据一起保存在日志文件中，因此可以查询服务输出，不必先为每种应用文本设计一套解析器。但让这些消息保留足够长时间，是另一项需要明确的要求。存储位置、空间策略、轮转方式与转发路径，决定了事故发生一段时间后还有哪些证据可查。查询方便，不等于历史永远完整，也不等于数据已经离开这台机器安全保存。

存储路径与保留范围是不同问题。轮转将旧文件关闭成归档并打开替代文件；vacuum 可以删除归档，不能删除活动文件。journald 服务重启不能证明整机重启或断电耐久性，字节目标也不保证固定证据窗口。本图是原文模型，不是新的执行结果。

坏掉的样子

默认命名空间通常使用 Storage=auto：存在 /var/log/journal 时选择持久存储，否则使用运行时存储。Storage=volatile 把文件放在 /run/log/journal 下，并不是简单借用内核的文本环形缓冲区。这些运行时文件通常会在整台机器重新启动后消失，但重启 journald 服务是不同的事件，并不必然清空文件。排查“重启后日志去哪了”之前，必须明确重启的是哪个对象。

Storage=persistent 优先使用 /var/log/journal，早期启动阶段或持久位置不可写时仍可能使用运行时存储。满足文档规定条件时，flush 操作可以转移运行时数据。因此应检查真实文件和最终生效配置，不能只因为某份配置片段里出现了 persistent，就推定所有消息已经写在预期磁盘上。路径、挂载状态与执行时点都需要对应到实际记录。

journald 本身有默认空间限制和轮转行为，不会仅仅因为管理员没有写一个轮转任务就无限增长。不过，SystemMaxUse 也不是保证文件系统永不写满的精确硬配额。运行时存储有另一组设置，可用空间限制同时起作用，其他程序也会占用磁盘，而清理时只能删除已经归档的 journal 文件。把这些条件压缩成“设置一个上限就绝对安全”，会掩盖真正的磁盘压力来源。

快速验证

在由 systemd 管理的一次性 Linux 系统中，以管理员身份运行下面的 Python 脚本。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。脚本创建唯一日志命名空间，显式配置持久存储，通过临时服务写入两条无害消息，最后只删除该命名空间的数据。实验中的 vacuum 会有意删除自己刚写入的旧消息：

from pathlib import Path
import json,shutil,subprocess,uuid

name='xbcatm-journal-'+uuid.uuid4().hex[:8]
config=Path('/etc/systemd')/('journald@'+name+'.conf')
directory=Path('/var/log/journal')/(Path('/etc/machine-id').read_text().strip()+'.'+name)
assert not config.exists() and not directory.exists()
def run(*args):
 result=subprocess.run(args,text=True,capture_output=True,timeout=15)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout
def journal(*args):return run('journalctl','--namespace='+name,*args)
def emit(message):
 run('systemd-run','--quiet','--wait','--collect','--unit='+name+'-'+message,
 '--property=LogNamespace='+name,'--property=StandardOutput=journal',
 '--property=SyslogIdentifier='+name,'/usr/bin/printf',message+'\n')
 journal('--sync')
def messages():
 rows=journal('--no-pager','-o','json','SYSLOG_IDENTIFIER='+name)
 return [json.loads(line)['MESSAGE'] for line in rows.splitlines()]
config.write_text('[Journal]\nStorage=persistent\nSystemMaxUse=16M\nRuntimeMaxUse=8M\n')
try:
 emit('old');journal('--flush');journal('--sync')
 assert messages()==['old'] and list(directory.glob('*.journal'))
 run('systemctl','restart','systemd-journald@'+name+'.service')
 assert messages()==['old']
 print('persistent namespace: message survives journald service restart')
 journal('--vacuum-size=1')
 assert messages()==['old']
 print('vacuum cannot remove the active journal file to satisfy a one-byte target')
 journal('--rotate');emit('new')
 assert messages()==['old','new']
 assert list(directory.glob('*@*.journal'))
 journal('--vacuum-size=1')
 assert messages()==['new'] and not list(directory.glob('*@*.journal'))
 print('after rotation: archived old message removed; active new message remains')
 print('persistent files observed under /var/log/journal; no reboot durability claim')
finally:
 run('systemctl','stop','systemd-journald@'+name+'.service',
 'systemd-journald@'+name+'.socket','systemd-journald-varlink@'+name+'.socket')
 config.unlink(missing_ok=True)
 for path in (directory,Path('/run/log/journal')/directory.name,Path('/run/systemd')/('journal.'+name)):
 if path.exists():shutil.rmtree(path)

第一条消息位于该命名空间的 /var/log/journal 目录中，重启对应 journald 服务后仍然能够查到。这验证了选中的存储位置，以及消息跨越日志守护进程重启仍然存在；它没有模拟突然断电，也没有证明存储设备的持久性，更没有执行整台机器重启。说明验证范围，可以避免把一个真实但有限的结果扩大成并未做过的耐久性测试。

第一次要求把占用清到一个字节，消息依然可见，因为承载它的文件还在写入。目标数字很小，但 vacuum 不会为了达到数字而删除活动文件。这直接说明，清理命令接受一个空间目标，不代表最终磁盘占用一定低于它。运维脚本如果只看命令返回成功就报告“空间已经降到目标”，会漏掉这一差别。

随后脚本轮转日志，再写入新消息。轮转把先前文件关闭成归档，同时打开替代文件；第二次清理之前，两条消息都能查到。再次 vacuum 后，归档里的旧消息消失，活动文件中的新消息仍在。轮转与删除是两项不同操作，对排障证据的影响也不同，不能把轮转本身说成已经删掉历史。

所有 journal 命令都显式选择唯一命名空间，因此不会清理默认系统日志。删除测试目录前，会先停止对应的服务和套接字实例。如果查询时省略命名空间参数，就会看默认空间，可能完全找不到这些已经成功存储的记录。查询范围错误与数据未写入，应当分别排除。

按需要保留证据

保留策略应依据事故响应窗口和实际消息量制定。流量变化时，空间上限不能承诺固定保留多少天；按时间清理的上限也不会自动预留足够空间，让每条消息都活到那个年龄。应观察实际占用与最早可查记录，尤其是一次异常故障产生大量重复日志之后，否则名义上的保留天数可能远大于真正可查询的范围。

消息也可能在保留策略生效前就已丢失。速率限制、应用输出路由、访问权限和存储不可用，都会影响哪些消息最终进入 journal。应区分“没有匹配的已存记录”与“事件从未发生”，也不要因为本机日志有权限限制，就把凭据写进消息正文。结构化字段有助于检索，并不会消除内容泄漏风险。

如果记录必须在整机丢失后仍然存在，就需要独立的采集路径并验证它。配置了转发，不等于远端已经收到或保存消息；应使用可识别的无害事件检查交付、访问控制与远端保留窗口。本机可检索日志和独立保存的外部证据，服务于相关但不同的运维需要，两者都应有实际结果支持。

来源

systemd 252 journald.conf，存储选择、默认空间限制、剩余空间与保留策略，已核验 2026-09-12。
systemd 252 journalctl，命名空间选择、轮转、同步与归档清理，已核验 2026-09-12。
systemd 252 systemd-journald.service，日志命名空间、传输与持久文件位置，已核验 2026-09-12。

按明确的字段与优先级规则查询 journal

Fri, 30 Jul 2027 00:00:00 +0000

有效的 journal 查询应该选出能够回答具体事故问题的记录。单元身份、运行实例、时间、优先级和应用字段提供了不同维度；正确组合它们，比在整台机器的历史里找到一个熟悉词语更重要。journald 可以附加进程元数据，但不会自动收集应用写出的每个文件，也不会自动理解每条消息的业务含义。查询条件和日志实际采集路径必须相互对应。

不同字段按 AND 组合，同字段多个取值按 OR 组合，独立 + 将条件组按 OR 连接。在原文首次运行示例中，-p err 选择 API 的二、三级，而 PRIORITY=3 只选三级。单元身份比一次运行实例更宽。空输出可能是成功查询，不证明事件未发生。本图不新增运行验证结论。

坏掉的样子

字段匹配有明确的布尔组合规则：不同字段之间是 AND，同一字段的多个取值之间是 OR，单独一个 + 则把两组条件按 OR 连接。因此，再添加一个字段值，有时会扩大结果集，而不是进一步缩小。应把查询看成一个明确的条件表达式，先用已知记录验证它，再放进事故脚本，避免因为“参数更多了”就误认为结果必然更精确。

-p err 选择错误及更严重的级别，并不是只选择数字三。如果真正需要精确的三级记录，应使用 PRIORITY=3 字段匹配。应用在文本中写了“error”，本身也不等于设置了错误优先级；标准输出的采集使用配置好的优先级规则，除非应用通过受支持的表示方式提供级别。消息文字、日志字段和筛选阈值不能互相混同。

命令成功但没有记录，不证明服务从未运行。所选启动周期、时间窗口、命名空间、读取权限、保留策略或输出路由，都可能解释空结果。反过来，查询一个单元的全部历史，又可能找到以前的成功启动，然后错误归因到当前进程。应区分服务长期身份与某一次具体运行，不能只因为单元名称相同就把证据拼接成一次执行。

快速验证

在 PID 1 为 systemd 的一次性 Linux 系统中，以管理员身份运行下面的 Python 脚本。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。脚本安装一个唯一命名的临时服务，并激活两次。每个工作进程向原生日志套接字发送四条较短的结构化消息，分别包含两个应用组件和几个明确的优先级：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid

name='xbcatm-query-'+uuid.uuid4().hex[:8];unit=name+'.service'
path=Path('/run/systemd/system')/unit
assert not path.exists()
def run(*args):
 result=subprocess.run(args,text=True,capture_output=True,timeout=10)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def query(*matches):
 output=run('journalctl','--no-pager','-o','json','-u',unit,*matches)
 return [json.loads(line) for line in output.splitlines() if line]
def labels(rows):return sorted(row['MESSAGE'] for row in rows)
with TemporaryDirectory(prefix=name+'-',dir='/run') as directory:
 root=Path(directory);worker=root/'worker.py'
 worker.write_text(r'''from pathlib import Path
import socket
phase=Path(__file__).with_name('phase').read_text()
with socket.socket(socket.AF_UNIX,socket.SOCK_DGRAM) as log:
 log.connect('/run/systemd/journal/socket')
 for component,priority in [('api',2),('api',3),('api',6),('db',3)]:
 fields=[f'MESSAGE={phase}-{component}-{priority}',f'PRIORITY={priority}',
 f'LAB_RUN={phase}',f'LAB_COMPONENT={component}',
 '_SYSTEMD_UNIT=forged.service']
 log.sendall(('\n'.join(fields)+'\n').encode())
''')
 path.write_text(f'[Service]\nType=oneshot\nExecStart=/usr/bin/python3 {worker}\n')
 try:
 run('systemd-analyze','verify',str(path));run('systemctl','daemon-reload')
 for phase in ('first','second'):
 (root/'phase').write_text(phase);run('systemctl','start',unit)
 run('journalctl','--sync')
 first=query('LAB_RUN=first')
 assert len(first)==4 and all(row['_SYSTEMD_UNIT']==unit for row in first)
 second=query('LAB_RUN=second');assert len(second)==4
 invocation=first[0]['_SYSTEMD_INVOCATION_ID']
 assert {row['_SYSTEMD_INVOCATION_ID'] for row in first}=={invocation}
 assert {row['_SYSTEMD_INVOCATION_ID'] for row in second}!={invocation}
 assert labels(query('LAB_RUN=first','LAB_COMPONENT=api','-p','err'))==['first-api-2','first-api-3']
 print('different fields AND; -p err includes critical priority 2 and error priority 3')
 assert labels(query('LAB_RUN=first','LAB_COMPONENT=api','PRIORITY=3'))==['first-api-3']
 assert labels(query('LAB_RUN=first','LAB_COMPONENT=api','LAB_COMPONENT=db','PRIORITY=3'))==['first-api-3','first-db-3']
 print('exact PRIORITY=3 differs from threshold; repeated component fields OR')
 union=query('LAB_RUN=first','LAB_COMPONENT=db','+','LAB_RUN=second','LAB_COMPONENT=db')
 assert labels(union)==['first-db-3','second-db-3']
 assert labels(query('_SYSTEMD_INVOCATION_ID='+invocation,'LAB_COMPONENT=db'))==['first-db-3']
 print('explicit + joins match groups; invocation filter separates repeated starts')
 assert query('LAB_RUN=absent')==[]
 print('empty query still succeeds; underscore unit field comes from journal metadata')
 finally:
 run('systemctl','stop',unit)
 if run('systemctl','show',unit,'-p','ActiveState','--value')=='failed':run('systemctl','reset-failed',unit)
 path.unlink();run('systemctl','daemon-reload')

第一次激活生成 API 严重消息、API 错误消息、API 普通信息和数据库错误消息；第二次生成相同类别，但带另一个应用运行标签。按第一次运行、API 组件和 -p err 过滤，会返回两条记录，优先级分别为二和三。改成精确匹配三级，只剩 API 错误。这组对照直接展示阈值与精确值的区别，而不是仅解释命令名称。

同一个组件字段同时写 API 与数据库取值，会返回第一次运行中两个组件的错误记录，并不要求一条记录同时具有两个值。随后使用显式 +，选出前后两次运行各自的数据库消息。断言比较的是完整预期消息列表，因此过滤条件意外过宽时，不能仅靠结果里包含某句想找的话就通过检查；多出来的记录同样会使验证失败。

两次激活具有不同的 journal 运行实例标识。使用第一次的标识过滤，只会选出那次激活的数据库消息，尽管单元名称没有变化。这对崩溃循环和反复手动启动很有价值：单元名称组织服务长期历史，运行实例则标识一次执行生命周期。排障时把两者都保留下来，能减少把上次成功误认为本次恢复的判断错误。

工作程序还尝试提交一个伪造的、下划线开头的单元字段，但返回记录仍然携带真实服务单元。这类可信字段由 journal 根据进程上下文提供，不会像普通应用标签一样接受程序自报。与之不同，组件和运行标签是应用自身的声明；实验能够控制它们，但生产解析器不能仅因为字段名称看起来正式，就把它们当成独立身份认证机制。

最后，匹配一个不存在的运行标签，查询成功返回空列表，脚本专门断言这一情况。完成后会移除临时单元和工作文件；八条无害日志继续遵循主机正常保留策略，不会为了抹掉少量实验记录而删除无关系统历史。空结果、命令失败与后续历史清理，分别属于不同层面的行为。

导出时保留上下文

当另一个程序消费查询结果时，应使用结构化输出。本例解析 JSON，并有意使用短小文本字段；通用 journal JSON 对重复取值或二进制数据可能使用不同表示，所以消费方应明确接受的数据结构，不能假定任意字段永远是一条简单字符串。导出证据时保留时间戳与归属字段，后续才能对照执行顺序和实例，而不是只剩无法定位来源的消息正文。

按时间窗口查询时，应记录对应启动周期或运行实例，并明确时区假设。读取身份和所选命名空间也是观察条件，不是无关细节。在认定某个应用事件缺失前，先确认同一路径产生的一条已知无害事件确实可见。一个范围明确、能够复现的查询，应让选择规则和证据边界都清楚可查，而不是只给出一行看似有结果的命令。

来源

systemd 252 journalctl，字段布尔组合、优先级筛选与 JSON 输出，已核验 2026-09-12。
systemd 252 systemd.journal-fields，可信元数据、应用字段与运行实例标识，已核验 2026-09-12。
systemd 252 systemd-journald.service，原生日志传输、命名空间区分与采集范围，已核验 2026-09-12。

systemd timer 安排服务启动，不保证任务成功

Mon, 21 Jun 2027 00:00:00 +0000

systemd timer 把调度规则与执行工作的服务分开。定时器决定何时请求激活，服务则定义命令、执行身份、环境、超时和结果。因此，维护任务可以使用普通单元工具检查，但一个按时发出的启动请求，并不能证明备份、清理或报表已经正确完成。调度是否运转与工作是否成功，需要不同证据；只有两者都符合要求，周期任务才真正达到目的。

定时器状态不能证明服务成功。图中仅展示原文示例相对完成的事件顺序，不表示实测时间比例，也不保证精确启动时刻。停止后续调度与停止当前工作是两个决定；此前示例未在本轮重跑。

坏掉的样子

活动的定时器可以与失败的服务同时存在。如果监控只检查 timer 是否活动，就会漏掉真正执行工作的失败。同样，最近触发时间只说明调度发生过，不代表业务输出成功。应检查服务结果，以及任务本来要生成的产物或状态变化，并保留足够上下文区分前后两次激活，避免把昨天留下的文件误当成今天任务已经完成。

除非通过 Unit 指向别的目标，定时器通常激活同名的 service。如果目标服务已经活动，就不会再启动另一份独立副本。这阻止的是同一个单元重叠激活，不是分布式锁，也不能阻止另一个服务执行相同命令。oneshot 如果使用 RemainAfterExit=yes 保持活动，后续计划执行就可能一直不再运行命令；保留状态是否合适，取决于任务真正需要表达什么。

停止定时器会停止后续调度，但不会自动停止已经开始的服务调用。事故期间暂停维护工作时，这个区别尤其重要：需要检查目标服务，再有意决定让当前工作结束还是中断它。即使停止命令成功，先前已经发生的文件或数据库修改也不会因此自动回滚，因此不能把“停了 timer”当成系统已经没有维护副作用。

快速验证

在 PID 1 为 systemd 的一次性 Linux 系统中，以管理员身份运行下面的 Python 脚本。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。它创建唯一命名的定时器与服务，以及临时工作程序。工作程序记录真实进程进入和完成时刻，成功任务则通过显式释放文件等待，以便直接观察调度行为：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,time,uuid

name='xbcatm-timer-'+uuid.uuid4().hex[:8];service=name+'.service';timer=name+'.timer'
paths={unit:Path('/run/systemd/system')/unit for unit in (service,timer)}
assert all(not p.exists() for p in paths.values())
def run(*args):
 result=subprocess.run(args,text=True,capture_output=True,timeout=10)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def value(unit,key):return run('systemctl','show',unit,'-p',key,'--value')
def wait_for(check):
 deadline=time.monotonic()+5
 while not check():
 assert time.monotonic()<deadline,'transition timed out'
 time.sleep(0.02)
with TemporaryDirectory(prefix=name+'-',dir='/run') as directory:
 root=Path(directory);worker=root/'worker.py'
 worker.write_text(r'''from pathlib import Path
import json,sys,time
root=Path(__file__).parent;number=len(list(root.glob('start-*.json')))+1
def record(kind):
 temp=root/'record.tmp';temp.write_text(json.dumps(time.monotonic()))
 temp.replace(root/(kind+'-'+str(number)+'.json'))
record('start')
if (root/'fail').exists():sys.exit(7)
while not (root/('release-'+str(number))).exists():time.sleep(0.01)
record('end')
''')
 paths[service].write_text(f'[Service]\nType=oneshot\nTimeoutStartSec=10s\nExecStart=/usr/bin/python3 {worker}\n')
 definition='[Timer]\nOnActiveSec=100ms\nOnUnitInactiveSec=10s\nAccuracySec=1ms\n'
 paths[timer].write_text(definition);(root/'fail').touch()
 try:
 run('systemd-analyze','verify',*[str(p) for p in paths.values()])
 run('systemctl','daemon-reload');run('systemctl','start',timer)
 wait_for(lambda:value(service,'ActiveState')=='failed')
 assert value(service,'ExecMainStatus')=='7' and value(timer,'ActiveState')=='active'
 run('systemctl','stop',timer)
 print('timer active while its first job failed with exit status 7')
 (root/'fail').unlink();run('systemctl','reset-failed',service)
 paths[timer].write_text(definition.replace('OnUnitInactiveSec=10s','OnUnitInactiveSec=250ms'))
 run('systemctl','daemon-reload');run('systemctl','start',timer)
 wait_for(lambda:(root/'start-2.json').exists())
 time.sleep(0.65)
 assert len(list(root.glob('start-*.json')))==2
 (root/'release-2').touch();wait_for(lambda:(root/'start-3.json').exists())
 gap=json.loads((root/'start-3.json').read_text())-json.loads((root/'end-2.json').read_text())
 assert gap>=0.25,gap
 print('no overlapping launch; next job starts at least 250ms after prior deactivation')
 pid=value(service,'MainPID');assert pid!='0'
 run('systemctl','stop',timer)
 assert value(service,'MainPID')==pid and value(service,'ActiveState')=='activating'
 print('stopping timer leaves its already running oneshot alive')
 (root/'release-3').touch();wait_for(lambda:value(service,'ActiveState')=='inactive')
 time.sleep(0.4)
 assert len(list(root.glob('start-*.json')))==3 and value(service,'Result')=='success'
 print('released job completes; stopped timer schedules no further run')
 finally:
 run('systemctl','stop',timer,service)
 for unit,path in paths.items():
 if value(unit,'ActiveState')=='failed':run('systemctl','reset-failed',unit)
 path.unlink()
 run('systemctl','daemon-reload')

第一次触发的工作进程故意以状态七退出，服务变为失败，定时器却继续活动。此时相对服务结束的下一次间隔先设置为十秒，让脚本有时间检查这个状态，并在再次尝试前停止定时器。结果证明调度器完全可能正常工作，而它安排的业务任务一直失败；仅凭 timer 状态不能得出任务可靠的结论。

修正样本的故障条件后，脚本清除失败状态，把间隔改为二百五十毫秒，再次启动调度。第二个工作进程在释放门槛处等待，即使超过两个名义间隔，也没有第三个进程出现。因为 OnUnitInactiveSec 从服务结束活动时计算，尚未完成的工作还没有提供那个参考事件；它不是简单从上次进程启动就开始固定倒计时。

释放第二个工作进程后，它完成执行，第三个进程才开始，且与前一完成标记至少相隔配置的间隔。真正的单元结束活动发生在该标记之后，因此断言验证的是“相对完成”的关系，不要求某个容易受调度影响的精确启动时间。实验使用 AccuracySec=1ms 减少短间隔下的合并延迟，但这不构成实时执行保证，机器负载仍然可能推迟工作开始。

脚本在第三个进程继续等待时停止定时器，进程编号没有变化，oneshot 仍处于激活中。只有释放这个工作进程，服务才成功完成。再经过一个间隔，调用次数保持不变，说明已停止的 timer 没有继续安排工作。最后清理双方运行时单元与临时程序；暂停计划与结束当前执行的不同效果，需要由实际进程状态分别验证；本轮没有取得这类运行证据。

同时迁移执行契约

从 cron 迁移任务时，不能只翻译时间表达式。还应检查工作目录、明确的命令路径、必要环境、合适的运行用户与执行时限。systemd 命令行不会隐式成为 shell 程序；管道、重定向和 shell 展开，需要有意调用 shell，或放入行为已经验证的独立脚本。否则同一段看似熟悉的命令，可能在新的执行环境中改变含义。

安装与激活也应区分。手动启动一次运行时定时器，不等于配置开机启用；启用服务本身，又可能额外引入一次不需要的开机运行。应按部署策略安装和启用 timer，再检查已载入定义与下次触发时间，并让服务可以独立受控执行，以便诊断真实工作流程。调度入口与人工诊断入口应遵守相同的执行契约。

失败如何重试、如何报告，需要另外决定。下一个 timer 事件可能再次尝试，服务的重启设置又有自己的规则与限制；两者叠加之前，应明确实际会发生几次调用。让重复副作用安全，并保留绑定真实结果的最近成功信号。运维目标是让有用工作在规定窗口内完成，而不是只得到一个长期显示活动的定时器。

来源

systemd 252 systemd.timer，目标选择、目标活动时的行为与相对完成间隔，已核验 2026-09-12。
systemd 252 systemd.service，oneshot 生命周期、保留状态、执行失败与超时，已核验 2026-09-12。
systemd 252 systemctl，启动、停止、启用以及检查定时器与服务单元，已核验 2026-09-12。

systemd-sysusers 创建缺少的服务账号

Tue, 08 Jun 2027 00:00:00 +0000

服务包经常需要先准备专用账号，才能拥有文件或避免以 root 身份运行。systemd-sysusers 用一份小配置声明账号及其组，核心操作是创建缺少的身份，并建立要求的成员关系。它不是通用账号迁移引擎，不负责创建所有目录，也不保证自动分配的数字标识在每台机器上都相同。把这些职责分清楚，才能判断声明已经执行究竟证明了什么。

sysusers 创建缺少的身份与要求的成员关系；不会迁移既有账号字段、保证跨主机自动 UID 一致，或创建家目录。图解基于原文；本轮没有更改账号数据库。

坏掉的样子

u 条目创建缺少的系统用户，通常也创建同名主组；g 创建组，m 添加附加组关系。ID 写成 - 表示自动分配，r 条目向分配池添加区间，多条区间合并使用；已有账号占用了某个数字，就会改变剩余可用范围。因此相同的分配池并不能建立跨机器身份一致性，尤其不能因为两边使用同一份配置，就假定共享存储里的数字所有者一定对应同一人。

更改既有账号的声明，不会自动为它重新编号，也不会自动更新家目录和描述字段。这种行为便于重复执行包初始化，但同时意味着配置差异不等于活动账号记录已经发生变化。真正迁移 UID，需要另外处理既有文件归属、正在运行的进程、共享存储和回退策略；不能只改一行声明，再把命令返回成功当作迁移完成。

家目录列设置的是账号数据库字段，不会创建实际目录。因此，一个服务可能已经拥有有效账号，却仍因为状态路径不存在或不可写而启动失败。需要目录时，应使用合适的受管理服务目录或 tmpfiles 规则，明确创建、所有权和权限。账号存在与目录可用，是两项独立条件，应沿真实服务启动路径分别验证。

快速验证

在装有 systemd-sysusers 的一次性 Linux 环境中，以管理员身份运行下面的 Python 脚本。它不修改机器正在使用的账号数据库，恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。每组测试都通过 --root 指向单独的临时根目录；shadow 数据库只在内部比较内容，不会把值打印出来：

from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess

definition='''r - 61000-61010
u field-worker - "Field worker" /var/lib/field-worker /usr/sbin/nologin
g field-readers -
m field-worker field-readers
'''
def prepare(root,occupied=None):
 (root/'etc').mkdir(parents=True)
 passwd='root:x:0:0:root:/root:/bin/sh\n';group='root:x:0:\n'
 if occupied is not None:
 passwd+=f'occupied:x:{occupied}:{occupied}:Fixture:/nonexistent:/usr/sbin/nologin\n'
 group+=f'occupied:x:{occupied}:\n'
 (root/'etc/passwd').write_text(passwd);(root/'etc/group').write_text(group)
 directory=root/'usr/lib/sysusers.d';directory.mkdir(parents=True)
 (directory/'field.conf').write_text(definition)
def apply(root):
 result=subprocess.run(['systemd-sysusers','--root='+str(root)],capture_output=True,text=True,timeout=10)
 assert result.returncode==0,result.stderr
def entries(root,name):
 return {line.split(':')[0]:line.split(':') for line in (root/'etc'/name).read_text().splitlines()}
with TemporaryDirectory(prefix='xbcatm-sysusers-') as directory:
 first=Path(directory)/'first';second=Path(directory)/'second';prepare(first);apply(first)
 worker=entries(first,'passwd')['field-worker'];groups=entries(first,'group')
 assert worker[3]==groups['field-worker'][2]
 assert 'field-worker' in groups['field-readers'][3].split(',')
 assert worker[5:]==['/var/lib/field-worker','/usr/sbin/nologin']
 assert not (first/'var/lib/field-worker').exists()
 before={name:(first/'etc'/name).read_bytes() for name in ('passwd','group','shadow','gshadow')}
 apply(first)
 assert before=={name:(first/'etc'/name).read_bytes() for name in before}
 print('user, primary group, and supplementary membership created; repeat leaves databases unchanged')
 print('home and nologin shell recorded; home directory was not created')
 prepare(second,int(worker[2]));apply(second)
 other=entries(second,'passwd')['field-worker']
 assert other[2]!=worker[2]
 print('same allocation range and definition choose different UIDs when existing accounts differ')
 changed=definition.replace('u field-worker - "Field worker" /var/lib/field-worker',
 'u field-worker 62000 "Changed description" /changed-home')
 (first/'usr/lib/sysusers.d/field.conf').write_text(changed);apply(first)
 assert entries(first,'passwd')['field-worker']==worker
 print('changing a declaration does not renumber or rewrite an existing account')
 assert not (first/'changed-home').exists()
print('only temporary alternate-root account databases were changed')

第一份根目录起初只有样本 root 账号。应用声明后，会生成工作用户、它的主组、读者组，以及工作用户的附加组成员关系。脚本检查数字主组关系和实际成员列表，而不是只检查配置能够解析。这样可以明确证明创建结果满足所声明的访问结构，避免把一个存在的组误认为用户已经加入其中。

用户记录包含要求的家目录路径和 nologin shell，但家目录本身并不存在。这直接区分了身份声明与文件系统准备。用于服务执行的账号仍然可以被获得授权的服务管理器使用；nologin shell 也不能替代所有权限和凭据控制。应根据程序真实的执行入口理解账号用途，而不是把账号字段当成完整隔离策略。

再次应用相同声明，passwd、group、shadow 和 gshadow 文件内容均不变。这验证的是当前明确输入的重复执行行为，不代表任何可能的声明都没有副作用。遇到输入冲突或分配范围耗尽时，仍应根据工具报告定位原因，不能因为它被称为声明式工具，就跳过对失败结果的检查。

第二份根目录先让另一个样本账号占用第一份工作用户的数字身份，再应用完全相同的配置，工作用户便得到不同 UID。名称与要求的分配区间相同，已有数据库状态却不同。因此，在两个根目录之间直接复制数字文件所有权、却不进行身份映射，是不成立的做法。是否要求跨主机数字一致，应当由数据共享契约决定。

最后，把第一份根目录中既有工作用户的声明改成新的数字 UID、描述和家目录，再次执行，完整账号记录仍然保持原样，也没有创建新目录。这体现的是以创建为主的初始化边界，不是证明新字段已经迁移成功。实验结束后删除临时根目录，所有账号变化始终局限于这些替代数据库。

明确打包时点与身份规则

软件包通常把声明放在 /usr/lib/sysusers.d，管理员可以在 /etc/sysusers.d 中用同名文件覆盖。文件名顺序与重复名称会影响最终输入，不能承诺声明永远与排列顺序无关。当多个包或本地策略涉及同一身份时，应检查真正生效的文件，以及冲突提示，而不是只阅读自己刚编辑的那份配置。

写入文件本身不会执行 sysusers。发行版启动单元和包集成决定工具何时被调用，因此需要验证实际安装路径及服务依赖，避免守护进程在账号或状态目录准备完成之前启动。账号创建与目录准备需要协调，但两者仍是不同操作，失败语义和验证方式也不相同。

只需要主机本地身份时，可以使用自动分配。如果共享存储或已经公开的接口要求某个数字身份，就应明确建立并验证分配规则，包括数字冲突与既有账号的处理。安装后还要测试实际服务访问。名称稳定、数字稳定和文件所有权正确是相关要求，但没有哪一项能够自动替代其余证据。

来源

systemd 252 sysusers.d，用户与组指令、分配区间、文件优先级和家目录字段，已核验 2026-09-12。
systemd 252 systemd-sysusers，账号创建、重复执行与替代根目录处理，已核验 2026-09-12。
systemd 252 tmpfiles.d，独立创建服务目录与设置所有权，已核验 2026-09-12。

Linger 延长 systemd 用户管理器在登录之外的寿命

Tue, 20 Apr 2027 00:00:00 +0000

Linger 改变的是一个账号的 systemd 用户管理器在什么时候保持可用。启用后，logind 可以在开机时启动该管理器，并在该账号登录会话结束后继续保留它，从而支持普通账号拥有的无人值守工作。这个标志控制管理器寿命，各个服务仍然遵守自己的激活、失败、停止和安装规则。账号可以没有登录会话，同时有管理器运行，但这不等于所有应用都已经启动。

Linger 控制管理器寿命，单元激活是另一项操作；管理器重启后，已启用单元创建新进程。PID A 和 PID B 是示意身份，不是测量值。图解解释原文，历史运行验证仍受阻。

坏掉的样子

开启 linger 不会自动启用账号配置目录里的每一个单元文件。服务仍需要通过启用关系、依赖、定时器、套接字或其他明确路径受到激活。因此管理器可能完全正常，目标应用却保持非活动。应同时检查两者，而不能把一个 linger 标志理解成当前所有服务的运行清单，更不能仅凭它存在就认定某个后台端口已经提供业务响应。

进程不会跨过整台机器重启继续存活。Linger 可以让新的用户管理器在开机时启动，已启用单元再创建新的进程，原来的内存状态已经消失。加密家目录或较晚挂载的路径，也可能让配置和应用数据在管理器启动时不可用。需要保留的状态应持久化，开机依赖应明确安排，不能靠“会跨重启”这种模糊说法跳过实际恢复过程。

Linger 也不是让崩溃应用无限重启的指令，不会自动把任意 shell 后台任务纳入服务管理。重启策略、资源限制和 logind 对会话进程的处理，分别属于不同控制。稳定的后台角色需要真实用户单元和可观察结果，不能只依赖登出前启动过一个命令，再把账号管理器继续存在当成那个命令必然受控运行。

快速验证

在具备 systemd、logind、用户 D-Bus 支持与账号管理工具的一次性 Linux 系统中，以管理员身份运行下面的 Python 脚本。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。它创建临时账号和家目录，只为该账号开启 linger，最后回收本次改动，全程不为这个账号建立登录会话。最后二十秒等待只是样例的超时上限，不是承诺的停止延迟。这个没有登录会话的实验不能证明最后登出后的 UserStopDelaySec 行为：

from pathlib import Path
from tempfile import TemporaryDirectory
import os,pwd,subprocess,time,uuid

name='xbcatm-linger-'+uuid.uuid4().hex[:8];unit='field-worker.service'
def run(*args):
 result=subprocess.run(args,capture_output=True,text=True,timeout=20)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def wait_for(check,seconds=5):
 deadline=time.monotonic()+seconds
 while not check():
 assert time.monotonic()<deadline,'state transition timed out';time.sleep(0.05)
with TemporaryDirectory(prefix=name+'-',dir='/run') as directory:
 root=Path(directory);root.chmod(0o755);home=root/'home';home.mkdir()
 run('useradd','--no-create-home','--user-group','--home-dir',str(home),'--shell','/bin/sh',name)
 account=pwd.getpwnam(name);uid=account.pw_uid;gid=account.pw_gid;manager=f'user@{uid}.service'
 def userctl(*args):
 return run('setpriv','--reuid='+str(uid),'--regid='+str(gid),'--init-groups',
 'env',f'XDG_RUNTIME_DIR=/run/user/{uid}',f'DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/{uid}/bus',
 'systemctl','--user',*args)
 def manager_value(key):return run('systemctl','show',manager,'-p',key,'--value')
 try:
 units=home/'.config/systemd/user';units.mkdir(parents=True)
 (home/'worker.py').write_text("from pathlib import Path\nimport os,time\np=Path(__file__).with_name('worker-pid');t=p.with_suffix('.tmp');t.write_text(str(os.getpid()));t.replace(p)\ntime.sleep(60)\n")
 (units/unit).write_text('[Service]\nType=exec\nExecStart=/usr/bin/python3 %h/worker.py\n[Install]\nWantedBy=default.target\n')
 for path in [home,*home.rglob('*')]:os.chown(path,uid,gid)
 run('loginctl','enable-linger',name)
 wait_for(lambda:Path(f'/run/user/{uid}/bus').exists())
 assert run('loginctl','show-user',name,'-p','Linger','--value')=='yes'
 assert run('loginctl','show-user',name,'-p','Sessions','--value')==''
 assert manager_value('ActiveState')=='active'
 assert userctl('show',unit,'-p','ActiveState','--value')=='inactive'
 print('linger starts a manager with zero login sessions; merely installing a user unit does not start it')
 userctl('enable','--now',unit);wait_for(lambda:(home/'worker-pid').exists())
 first=(home/'worker-pid').read_text();first_manager=manager_value('MainPID')
 run('systemctl','restart',manager)
 wait_for(lambda:Path(f'/run/user/{uid}/bus').exists() and (home/'worker-pid').read_text()!=first)
 assert manager_value('MainPID')!=first_manager
 assert userctl('show',unit,'-p','MainPID','--value')==(home/'worker-pid').read_text()
 assert run('loginctl','show-user',name,'-p','Sessions','--value')==''
 print('enabled user service starts as a new process after a real manager restart')
 userctl('disable',unit)
 assert userctl('show',unit,'-p','ActiveState','--value')=='active'
 print('disable removes future enablement but does not stop the current service')
 userctl('stop',unit);run('loginctl','disable-linger',name)
 wait_for(lambda:manager_value('ActiveState')=='inactive',seconds=20)
 print('with no sessions and linger disabled, user manager stops after policy delay')
 finally:
 run('loginctl','disable-linger',name)
 run('systemctl','stop',manager,f'user-runtime-dir@{uid}.service')
 run('userdel',name)

执行启用后，用户管理器变为活动，其总线端点出现，logind 报告 linger 已开启、会话列表为空。但已经安装的工作单元仍然非活动。这证明让管理器保持可用，与请求某个应用运行，是不同操作；即使文件已经出现在正确配置目录中，也还需要符合实际契约的激活入口。

随后脚本通过正确用户管理器启用并启动工作服务。安装段把它连接到用户默认 target，显式启动则开始当前执行，进程标记记录真正的工作者编号。控制器通过 setpriv 和用户运行时总线操作，不会悄悄建立登录会话。因此后续看到服务运行，不能归因于控制命令本身意外延长了某个会话。

重启系统层的 user@UID.service 后，账号管理器被替换，已启用的工作服务随后写出不同进程编号，新用户管理器也报告同一个新工作者，会话列表仍为空。这里验证的是根据保存的单元启用关系，在真实管理器重启后重新构建运行状态，而不是仅仅观察原进程多活了一段时间。新的进程身份也直接说明恢复与延续不是同一件事。

仅禁用工作服务、没有请求停止时，当前服务仍然活动。禁用移除的是后续启用链接，不是隐式终止命令。脚本检查这个差别，再显式停止工作者、关闭 linger；样例预期关闭 linger 后管理器回到非活动；它并未测量最后登出后的延迟。因此停当前工作、改变未来激活和改变管理器寿命，需要分别表达和核对。

清理过程在需要时再次关闭 linger，停止实验管理器和运行时目录单元，删除临时账号与家目录。实验有意使用临时配置，没有重启整台机器。正文涉及开机的语义来自文档契约，进程替换断言针对管理器重启，不能冒称已经完成了机器重启验证。正式部署若要求开机可用，仍应在对应环境检验这个阶段。

有意管理无人值守账号

保持账号启用单元可审阅，及时移除不再需要的服务。登出后仍然可用的服务可能持续持有内存、打开的文件、凭据与网络监听器。普通用户权限限制了部分动作，但该身份已经获得的访问仍然存在，因此应按工作负载配置合适权限和受支持资源控制，不能把非 root 当成完全不影响共享系统的保证。

配置与凭据应通过无需交互 shell 的机制供应。终端中成功启动一次，不证明无人登录时具有相同环境；需要核对工作目录、输入路径和管理器重启后的访问。当开机可用是部署要求时，再执行真实开机验证。这样才能发现家目录挂载、环境变量或外部依赖只在交互登录后才成立的问题。

退役后台角色时，应区分禁用服务、停止当前执行、关闭 linger 和删除账号数据，其他会话或激活入口也可能继续影响结果。完成目标操作后，检查账号管理器及服务的真实状态。有效保证是一套写清楚的无人值守生命周期，具有明确激活与停止方式，而不是承诺某一个进程编号永远存活。

来源

systemd 252 loginctl，启用与禁用按账号的 linger 并检查会话，已核验 2026-09-12。
systemd 252 user@.service，账号管理器与运行时目录生命周期，已核验 2026-09-12。
systemd 252 logind.conf，用户停止延迟以及会话与用户服务的区别，已核验 2026-09-12。
systemd 252 systemctl，启用与禁用以及启动与停止的不同效果，已核验 2026-09-12。
systemd-stable v252.39 用户生命周期源码，user_may_gc 仅在最后会话时间戳存在时检查停止延迟；仅属源码证据，已核验 2026-10-19。

分别检查 timesyncd 服务状态与时钟证据

Thu, 11 Mar 2027 00:00:00 +0000

systemd-timesyncd 是一个精简 SNTP 客户端，用配置的时间源同步本地系统时钟。它可以帮助证书检查与墙钟时间戳保持有意义，但不会无条件保证某个精度范围。守护进程能否运行、是否收到可接受样本，以及系统是否报告同步，是需要分别确认的事实。只看到安装了客户端，或者某条命令成功返回，都不足以推导时钟已经准确。

坏掉的样子

守护进程并不总是平滑校正。文档明确说明，大偏差会直接跳时，小偏差则逐渐调整。因此，开机时离正确时间很远的机器，可能发生时间不连续。经过时长测量应使用单调时钟，解释墙钟时间戳的应用则应处理校时，而不是假定时间永远平滑前进。不能把“精简客户端”误写成“绝不会让应用看见时间跳跃”。

FallbackNTP 不是显式服务器不可达时就一定会启用的通用应急列表，它在没有其他已知服务器信息时才适用。全局 NTP 条目和 networkd 提供的链路时间源，优先于这个后备设置。因此，应检查实际来源选择与配置覆盖文件，不能仅因为主来源连接失败，就断定某个写在 fallback 中的服务器必定已经被尝试。

未同步也不能证明 UDP 流量被阻止。服务可能缺失、未启用、被单元条件排除、没有调整时钟的权限，或者正在拒绝不合适样本。反过来，全局同步属性也不能单独说明哪个进程提供了时间。应区分管理器看到的服务状态、客户端观察到的样本，以及内核层同步指示，避免把来自不同层面的一个布尔值当成完整故障结论。

原文已准备场景中，条件不满足使激活被跳过，启动命令仍返回零；时钟证据需另行判断。

快速验证

原先的失败模式报告在一次性 Debian 12 Docker 容器中以 root 运行，PID 1 为 systemd 252.39。初始化进程通过 /usr/bin/setpriv --bounding-set=-sys_time,-sys_module /sbin/init 启动，移除相关能力以防止调整 Docker 虚拟机共享时钟。这只是用于已准备好 Python 3、D-Bus、timesyncd 安装包和未被覆盖的有效单元条件的容器探测，并不是容器启动配方。保存为 timesyncd-state.py，执行 python3 timesyncd-state.py 时必须启用断言，不使用 -O 或 PYTHONOPTIMIZE；脚本会先检查前提，再请求服务启动：

from pathlib import Path
import json,subprocess

def run(*args):
 result=subprocess.run(args,text=True,capture_output=True,timeout=10)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def properties(unit):
 output=run('systemctl','show',unit,'-p','ActiveState','-p','SubState','-p','MainPID','-p','ConditionResult')
 return dict(line.split('=',1) for line in output.splitlines())
# This failure-mode exercise requires an isolated container that cannot set time.
status=dict(line.split(':',1) for line in Path('/proc/1/status').read_text().splitlines() if ':' in line)
assert int(status['CapBnd'].strip(),16)&(1<<25)==0,'PID 1 must lack CAP_SYS_TIME'
assert run('systemd-detect-virt','--container')=='docker'
unit='systemd-timesyncd.service';definition=run('systemctl','cat',unit)
assert 'ConditionCapability=CAP_SYS_TIME' in definition
assert 'ConditionVirtualization=!container' in definition
assert properties(unit)['ActiveState']=='inactive'
run('systemctl','start',unit)
state=properties(unit)
assert state=={'MainPID':'0','ActiveState':'inactive','SubState':'dead','ConditionResult':'no'},state
clock=dict(line.split('=',1) for line in run('timedatectl','show','-p','CanNTP','-p','NTP','-p','NTPSynchronized').splitlines())
assert all(value in ('yes','no') for value in clock.values())
print('start command returned zero; unit stayed inactive with PID 0 and failed conditions')
print('clock properties:',json.dumps(clock,sort_keys=True))
print('PID 1 lacks time-setting capability; Docker condition also excludes this packaged service')
print('no clock-setting command was issued and no NTP synchronization was claimed')

启动命令返回零，但单元仍为非活动，主进程编号为零，ConditionResult=no。条件不满足而跳过激活，与守护进程成功运行，是不同结果。样本安装包要求调整时间的能力，并排除容器，而当前环境两项前提都不满足。因此在假设 NTP 报文被网络丢弃之前，就已经有具体证据解释服务为何没有工作。

记录中的时钟属性为 CanNTP=yes、NTP=no、NTPSynchronized=no，分别反映时间服务接口的不同方面。尤其是系统具有 NTP 服务支持，不代表该服务当前活动，也不证明时钟已经同步。脚本输出真实取值，不会把结果替换成预设健康状态；在另一环境中判断时，也应核对当时实际观察，而不是照抄本例的布尔值。

实验没有发出设置时钟的命令，也不声称成功交换 NTP 报文或完成校时。原先报告描述了这一激活失败模式；本轮未取得原始运行日志，也没有重新执行。要测试成功校时，需要具备相应权限、可以访问合适时间源的机器，或拥有独立时钟的虚拟机；不能让宿主共享时钟承担一个没有隔离边界的试验，也不能把未运行的客户端写成同步成功。

守护进程真实运行时，可以通过 timedatectl timesync-status 查看客户端自己的服务器与同步信息。但依赖这个接口之前，应先核对服务状态；请求不可用服务时，可能等待 D-Bus 激活并最终超时。另行报告的五秒探测不在这段脚本中，本轮也未重跑；它的超时不构成同步证据。接口存在、调用返回与内容证明什么，也需要分别判断。

建立能够验证的时间要求

按网络环境选择时间源，并持续观察偏移、延迟与所接受来源的质量。能够连接，并不让服务器自动准确或可信。轮询和根距离设置影响样本处理，但不能仅靠几个配置就把精简客户端变成完整时间分发服务，也不会自动形成某个精度服务承诺。需要什么精度、怎样观察偏差，应由实际应用要求决定。

保存的 /var/lib/systemd/timesync/clock 时间戳，有助于缺少可靠硬件时钟的系统在重启时初始化时间。但它也可能在近期没有成功同步时被周期更新，因此文件存在不证明刚刚接受了网络样本。大致初始化时间与同步到参考时钟，是两个不同里程碑，不应在开机就绪判断中混为一谈。

如果后续工作必须等到时钟同步，应配置并验证相应等待服务，以及排在 time-sync.target 之后的关系。仅启动 timesyncd，不会自动阻止所有应用在准确参考时间到达前运行。应明确启动条件和运行期监控，并以真实部署环境中的证据为准，而不是依赖一个笼统的“NTP 已开启”标签来判断所有时间相关要求已经满足。

来源

systemd 252 systemd-timesyncd.service，SNTP 行为、大偏差跳时、保存的时钟状态与同步信号，已核验 2026-09-12。
systemd 252 timesyncd.conf，时间源选择、后备来源优先级、轮询与根距离限制，已核验 2026-09-12。
systemd 252 org.freedesktop.timedate1，NTP 可用性、启用状态与内核同步属性，已核验 2026-09-12。
systemd 252 systemd-time-wait-sync.service，在确认时间同步后启动依赖服务，已核验 2026-09-12。
Python 3.11: assert statement，优化模式会移除断言检查，已核验 2026-10-18。

EnvironmentFile 在 systemd 执行进程时供应取值

Fri, 19 Feb 2027 00:00:00 +0000

环境文件把部署取值与描述进程监管的单元定义分开。systemd 在执行服务命令前读取指定文件，再把取值放入那个进程的环境。修改文件不会直接重写已经运行的进程环境。不过，重载辅助命令本身也是一个新进程，因此可能读到比现有主进程更新的文件值。理解这个执行时点，比笼统记住“改配置后做一次 reload”更可靠。

EnvironmentFile 在服务命令执行时读取。second、third、fourth 是原文样例值，不是本轮观测。文件由 systemd 按自身规则解析，并非执行 shell。本轮保留历史运行验证受阻状态。

坏掉的样子

daemon-reload 要求管理器重新读取单元定义、更新依赖信息；reload 则请求服务执行已配置的重载操作，例如 ExecReload。两者都不是把现有进程环境整体替换掉的通用指令。服务可以自行实现应用配置刷新，但这种能力必须来自应用或重载辅助程序，不能仅凭管理器接受了一个重载请求就认定业务设置已经切换。

EnvironmentFile 路径前加短横线，表示这个文件可以不存在。缺失时 systemd 会忽略它，并不会发出操作者可能期待的那条警告。因此，路径笔误可能让一个覆盖配置悄悄消失。只有缺少该文件确实具有合法含义时，才适合使用可选形式；必需的部署输入不应借这个前缀被静默跳过，否则很容易把供应错误变成难以解释的默认行为。

文件由 systemd 解析，不是交给 shell 加载。它有自己的引号和转义规则，但不会把命令替换和变量展开当作 shell 执行。包含 $HOME 的值仍然是这段文本。后列出的文件覆盖前面的同名值，文件赋值又覆盖单元中的 Environment 赋值。因此，需要检查真实优先级，不能认为自己首先看见的那一行就是最终值。

快速验证

在 PID 1 为 systemd 的隔离 Linux 环境中，以管理员身份运行下面的 Python 脚本。它只使用无害的样本设置与临时路径，恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。确认运行时单元名称尚未使用。工作程序仅记录四个特定测试值，不会把整个环境全部打印出来：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,time

unit='xbcatm-environment-lab.service';unit_path=Path('/run/systemd/system')/unit
assert not unit_path.exists()
def ctl(*args,success=True):
 result=subprocess.run(['systemctl',*args],capture_output=True,text=True,timeout=10)
 assert (result.returncode==0)==success,(args,result.stderr)
 return result.stdout.strip()
def value(key):return ctl('show',unit,'-p',key,'--value')
def wait_for(check):
 deadline=time.monotonic()+5
 while not check():
 assert time.monotonic()<deadline,'state transition timed out'
 time.sleep(0.02)
with TemporaryDirectory(prefix='xbcatm-environment-',dir='/run') as directory:
 root=Path(directory);first=root/'required.env';second=root/'optional.env';worker=root/'worker.py'
 command=f'$(touch {root}/unexpected)'
 initial=f'MODE=first\nLITERAL=$HOME\nQUOTED="two words"\nCOMMAND={command}\n'
 first.write_text(initial);first.chmod(0o600);second.write_text('MODE=second\n')
 worker.write_text("""from pathlib import Path
import json,os,sys,time
root=Path(__file__).parent;name=sys.argv[1]
data={key:os.environ.get(key) for key in ('MODE','LITERAL','QUOTED','COMMAND')}
data['pid']=os.getpid()
tmp=root/(name+'.tmp');tmp.write_text(json.dumps(data));tmp.replace(root/(name+'.json'))
if name=='main': time.sleep(60)
""")
 unit_path.write_text(f'''[Service]
Type=exec
Environment=MODE=unit-default
EnvironmentFile={first}
EnvironmentFile=-{second}
ExecStart=/usr/bin/python3 {worker} main
ExecReload=/usr/bin/python3 {worker} reload
''')
 def read(name):return json.loads((root/(name+'.json')).read_text())
 try:
 subprocess.run(['systemd-analyze','verify',str(unit_path)],check=True)
 ctl('daemon-reload');ctl('start',unit)
 wait_for(lambda:(root/'main.json').exists())
 current=read('main');assert current['MODE']=='second'
 assert current['LITERAL']=='$HOME' and current['QUOTED']=='two words'
 assert current['COMMAND']==command and not (root/'unexpected').exists()
 assert 'MODE=unit-default' in value('Environment')
 print('ordered environment files override unit value; quoting works; shell text stays literal')
 second.write_text('MODE=third\n')
 ctl('daemon-reload');assert value('MainPID')==str(current['pid'])
 live=Path(f'/proc/{current["pid"]}/environ').read_bytes().split(b'\0')
 assert b'MODE=second' in live
 ctl('reload',unit)
 assert read('reload')['MODE']=='third' and read('main')==current
 assert value('MainPID')==str(current['pid'])
 live=Path(f'/proc/{current["pid"]}/environ').read_bytes().split(b'\0')
 assert b'MODE=second' in live
 print('reload helper receives new file value; existing main process retains old environment')
 second.write_text('MODE=fourth\n');ctl('restart',unit)
 wait_for(lambda:read('main')['pid']!=current['pid'])
 assert read('main')['MODE']=='fourth'
 print('restart reads changed environment file without another daemon-reload')
 first.unlink()
 subprocess.run(['systemd-analyze','verify',str(unit_path)],check=True)
 ctl('restart',unit,success=False)
 assert value('ActiveState')=='failed' and value('MainPID')=='0'
 print('missing required environment file prevents start')
 first.write_text(initial);first.chmod(0o600);second.unlink()
 ctl('reset-failed',unit);ctl('start',unit)
 wait_for(lambda:read('main')['MODE']=='first')
 print('missing optional file is ignored; required-file value remains')
 finally:
 ctl('stop',unit)
 if value('ActiveState')=='failed':ctl('reset-failed',unit)
 unit_path.unlink();ctl('daemon-reload')

主进程最初得到第二份文件中的模式值：可选的第二份文件覆盖必需的第一份文件，第一份又覆盖单元默认值。带引号的内容正确解析为包含空格的两个词，看起来像变量和命令的文本则保持字面值；如果真经过 shell 替换本应产生的那个文件，也确实没有出现。实验同时验证了优先级与解析边界，而不是只展示几行配置样子。

管理器的 Environment 属性仍然包含单元默认赋值。它不是把所有环境文件读入后形成的完整生效值报告。对这个样本而言，工作程序记录的少量字段证明实际收到什么，管理器属性则说明单元配置了哪些直接赋值。混淆这两个观察面，会使排障人员追着一个已经被文件覆盖的默认值分析问题。

把文件改成第三个值之后，执行 daemon-reload，主进程编号和它在 /proc 中的实际环境都没有变化。再执行服务重载，新启动的辅助程序读到第三个值，原主进程仍保留第二个值。代码只核对那条无害的测试设置，没有输出进程环境中的其他内容，因此能够验证状态，又不会把完整环境复制进诊断日志。

随后把文件再改成第四个值，直接重启服务，没有再次重载管理器。替换进程收到第四个值，区分了执行进程时重新读取文件与重新读取单元定义这两件事。这也说明，重载辅助命令返回成功，本身不足以证明主应用采用了替换配置；必须根据实际刷新协议检查真正消费该值的进程。

删除必需文件后，静态单元验证依然通过，但真实重启失败，主进程编号为零。恢复必需文件、删除可选文件，则可以用第一份文件的值启动。因此，配置语法成立、文件实际加载成功、应用已经采用新值，是三项需要分别检查的结果，不能让其中一项代替其余两项。

有选择地暴露配置信息

环境文件适合承载合适的配置项，并应设置与服务相符的所有者和权限。但敏感值最终仍会进入进程环境，可能被继承或出现在诊断资料里。文件没有进入版本控制，不代表秘密边界已经完整成立。对于更适合专门凭据交付机制的秘密，应使用平台支持的机制，而不是把所有敏感输入都塞进环境文件后就停止评估。

文档中应明确一次变更需要新进程、应用支持的重载，还是两者都有。单元定义通过合适的覆盖位置修改，定义变更后让管理器重新加载。仅仅修改已有环境文件，不要求这一步，但目标消费者必须确实重新执行，或者实现有明确契约的其他刷新路径。否则磁盘上的新文件与运行中的旧配置可以长期并存。

验证最终行为或选择性的非敏感设置，避免把全量环境变量倒进事故日志。观察时确认正确的进程编号或运行实例，不要把旧进程记录误认成替换后的状态。保留足够信息来识别当前配置版本，同时不让排障渠道成为新的泄漏位置，这样配置拆分才真正有助于运维，而不是只是把值换了一个存放文件。

来源

systemd 252 执行环境，环境文件解析、优先级、可选路径与逐进程加载，已核验 2026-09-12。
systemd 252 systemctl，服务重载、管理器重载与重启的区别，已核验 2026-09-12。
systemd 252 服务命令，ExecStart 与 ExecReload 生命周期，已核验 2026-09-12。

同一账号的会话共享 systemd 用户管理器

Tue, 26 Jan 2027 00:00:00 +0000

systemd 用户管理器代表一个账号运行服务。同一账号的多个登录会话通常共享这个管理器，而不是每个 shell 都拥有一套私有服务世界。用户单元可以放在 ~/.config/systemd/user，通过 systemctl --user 操作对应管理器。这提供的是以账号权限执行的生命周期管理，并不自动隔离所有共享系统资源。使用它之前，需要同时理解服务属于谁，以及管理器在什么条件下继续存在。

会话共享账号级管理器。图中最后会话结束后的停止，以未开启 linger 和配置的停止延迟为前提，并非立即停止的普遍规则。本轮绘图没有重新执行原文样例。

坏掉的样子

关闭一个终端，不一定停止用户服务，因为另一个登录会话可能仍然存在，管理器寿命也受到 linger 和停止延迟配置影响。即使最后一个会话结束，立即终止也不是普遍规则。必须跟随某一次图形会话结束的应用，需要明确的生命周期关系，不能假定任何用户单元天然具有这个范围。账号级后台任务与某个窗口的寿命，是不同需求。

选错管理器也是常见故障。普通 systemctl 操作系统管理器，systemctl --user 则需要连接正确用户的管理器及其运行时通信端点。通过另一身份执行命令，或者所在环境没有完成会话准备，都可能导致连接失败。仅仅设置一个环境变量，不会创建管理器，也不会授予控制其他账号的权限；诊断时应先确认执行身份与目标总线是否一致。

用户服务也不会自动继承发出控制命令的那个终端环境。所需路径、配置和图形会话变量，应通过有意选择的机制提供。使用普通账号会减少权限，但该账号仍可以按既有权限访问共享可写文件、使用网络套接字并消耗资源。因此“没有 root”并不等于“所有影响都绝对局限于自己的文件”，还要检查真实权限和资源限制。

快速验证

在具备 systemd、logind、PAM 集成、用户 D-Bus 会话与账号管理工具的一次性 Linux 系统中，以管理员身份运行下面的 Python 脚本。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。脚本创建临时账号、两个真实 PAM 会话和一个用户服务，不修改任何已有人员的单元或登录状态。最后二十秒等待要求 UserStopDelaySec 有限且更短；合法取值 infinity 会阻止预期停止：

from pathlib import Path
from tempfile import TemporaryDirectory
import os,pwd,subprocess,time,uuid

name='xbcatm-user-'+uuid.uuid4().hex[:8];sessions=[name+'-a.service',name+'-b.service'];unit='field-worker.service'
def run(*args):
 result=subprocess.run(args,capture_output=True,text=True,timeout=20)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def wait_for(check,seconds=5):
 deadline=time.monotonic()+seconds
 while not check():
 assert time.monotonic()<deadline,'state transition timed out';time.sleep(0.05)
with TemporaryDirectory(prefix=name+'-',dir='/run') as directory:
 root=Path(directory);root.chmod(0o755);home=root/'home';home.mkdir()
 run('useradd','--no-create-home','--user-group','--home-dir',str(home),'--shell','/bin/sh',name)
 account=pwd.getpwnam(name);uid=account.pw_uid;gid=account.pw_gid;manager=f'user@{uid}.service'
 def userctl(*args):
 return run('setpriv','--reuid='+str(uid),'--regid='+str(gid),'--init-groups',
 'env',f'XDG_RUNTIME_DIR=/run/user/{uid}',f'DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/{uid}/bus',
 'systemctl','--user',*args)
 def manager_value(key):return run('systemctl','show',manager,'-p',key,'--value')
 try:
 units=home/'.config/systemd/user';units.mkdir(parents=True)
 (home/'worker.py').write_text("from pathlib import Path\nimport os,time\np=Path(__file__).with_name('worker-pid');t=p.with_suffix('.tmp');t.write_text(str(os.getpid()));t.replace(p)\ntime.sleep(60)\n")
 (units/unit).write_text('[Service]\nType=exec\nExecStart=/usr/bin/python3 %h/worker.py\n[Install]\nWantedBy=default.target\n')
 for path in [home,*home.rglob('*')]:os.chown(path,uid,gid)
 for session in sessions:
 run('systemd-run','--quiet','--unit='+session,'--property=Type=simple',
 '--property=User='+name,'--property=PAMName=login','/usr/bin/sleep','60')
 wait_for(lambda:Path(f'/run/user/{uid}/bus').exists())
 wait_for(lambda:len(run('loginctl','show-user',name,'-p','Sessions','--value').split())==2)
 assert run('loginctl','show-user',name,'-p','Linger','--value')=='no'
 initial=manager_value('MainPID');assert initial!='0'
 userctl('enable','--now',unit);wait_for(lambda:(home/'worker-pid').exists())
 worker_pid=(home/'worker-pid').read_text()
 assert userctl('show',unit,'-p','MainPID','--value')==worker_pid
 run('systemctl','stop',sessions[0])
 wait_for(lambda:len(run('loginctl','show-user',name,'-p','Sessions','--value').split())==1)
 assert manager_value('MainPID')==initial and userctl('show',unit,'-p','MainPID','--value')==worker_pid
 print('two PAM sessions share one user manager; closing one leaves its service unchanged')
 run('systemctl','stop',sessions[1])
 wait_for(lambda:manager_value('ActiveState')=='inactive',seconds=20)
 assert not Path('/proc/'+worker_pid).exists()
 print('after the final session and configured stop delay, non-lingering manager and worker stop')
 print('controllers use setpriv and the actual user bus; they do not create extra PAM sessions')
 finally:
 for session in sessions:
 if run('systemctl','show',session,'-p','LoadState','--value')!='not-found':run('systemctl','stop',session)
 run('systemctl','stop',manager,f'user-runtime-dir@{uid}.service')
 run('userdel',name)

两个临时会话启动器使用相同账号，并设置 PAMName=login。脚本等待 logind 报告两个会话、且用户总线可用后，才继续控制服务。启动器使用 simple 类型，因此命令返回不会被当成 PAM 已完成的证据；会话数量和总线状态提供了明确的观察边界，避免把尚在建立的登录环境当成已经可用。

工作进程通过用户管理器启动，并被启用到用户默认 target。它以原子替换方式把自身编号写入无害文件，脚本再与用户单元报告的主进程编号比较。系统管理器中的 user@UID.service 则提供账号管理器自身的另一编号。这样可以分别追踪管理器与它运行的服务，避免把两层进程身份混在一起。

停止第一个 PAM 会话后，会话数量降到一，但管理器和工作进程编号都保持不变。这直接反驳了“每个登录 shell 拥有独立管理器，shell 结束服务就必须消失”的理解。仍然存在的另一个会话继续使用同一份账号级服务上下文，没有因为一次会话结束就重新启动所有后台工作。

第二个会话停止后，脚本等待未启用 linger 的用户管理器按当前策略变为非活动，工作进程也随之消失。有限等待容纳了文档中的停止延迟，并不意味着每台机器都使用相同延迟，也不意味着无关 shell 进程一定适用相同终止规则。观察对象是用户管理器及其监管的工作单元，而不是把所有同 UID 进程都混为一类。

控制命令通过 setpriv 切换身份并连接真实用户总线，不会额外建立 PAM 会话来意外延长管理器寿命。如果诊断命令自身不断创建新会话，就可能破坏“最后会话已经结束”的测试前提。清理时停止实验启动器和运行时管理器，删除临时账号及其家目录，让验证也覆盖本次资源的回收。

为服务选择合适寿命

应先决定工作属于一次图形会话、账号的全部会话，还是无人登录时也必须运行的机器角色。用户管理器适合账号拥有的后台任务，linger 则可以有意把管理器寿命延长到登录之外。这项选择需要明确，因为它会改变资源和网络监听器什么时候继续活动，不能在部署后仅靠“用户服务”这个名字推定其运行窗口。

以账号权限作为起点，再为真实工作负载增加受支持的资源限制与沙箱。一些执行约束需要普通用户管理器不具备的权限或内核支持，不能假定系统单元的安全设置原样复制就一定生效。应同时验证限制实际执行，以及应用仍能完成必要工作，避免只有配置看起来严格，却没有对应运行时证据。

保持单元启用、应用环境与可观察结果一致，排障时查看目标用户的单元与日志。尤其当多个会话或部署工具共同控制一个账号时，共享状态本身就是需要理解的契约。只有明确了共享寿命与执行权限，用户管理器才能简化监管，而不是把某个终端的临时状态错误传播成长期服务行为。

来源

systemd 252 user@.service，按用户管理器、会话作用域与运行时目录，已核验 2026-09-12。
systemd 252 logind.conf，最后会话结束处理、用户管理器停止延迟与进程策略，已核验 2026-09-12。
systemd 252 systemd.exec，PAM 会话、执行身份、环境与沙箱限制，已核验 2026-09-12。
systemd 252 loginctl，用户与会话检查以及 linger 策略，已核验 2026-09-12。

只读根在其范围内限制文件系统修改

Wed, 23 Dec 2026 00:00:00 +0000

只读根文件系统限制对服务打包代码和配置所在文件系统层的普通写入，明确挂载仍可提供运行数据的可写位置。其边界是文件系统变更本身。它不会单独移除进程权限、阻止读取可访问数据，也不会禁止与其他服务通信，需要按实际作用范围理解其价值。

坏掉的样子

应用经常在主要数据目录之外写入临时文件、缓存、锁文件、生成配置或运行状态。只读根会让这些假设在启动或不常见操作中以 EROFS 暴露。只测健康检查端点，可能漏掉生成报表、刷新缓存或关停清理时才经过的写入路径。因此必须沿真实工作流程检查需求，不能把进程成功启动当成全部功能可用。

即使容器根层只读，可写挂载仍然可写，其中状态仍可能被故障或受损进程改坏。把大块可写目录覆盖到打包路径，也可能抵消这些路径原本需要的保护。应检查最终挂载布局，而不是根据一个根层选项推断整棵路径树的行为。路径看起来位于只读根之下，并不证明中间没有另一个可写挂载。

只读与保密也是不同属性。进程仍可能读取打包文件、执行已有程序，并通过允许的网络路径发送数据。该设置也不保证容器逃逸之后仍受相同保护，更不约束能够改变挂载安排的权限。应结合凭据、能力、隔离和应用行为理解它的贡献，避免把一项文件系统限制描述成完整安全边界。

只读根限制自身层的修改；可写挂载、读取、执行与本地通信仍需分别考虑。

快速验证

在一次性 Linux 容器内使用 root 身份，根层只读，/tmp 挂可写 tmpfs，/work 挂独立可写卷。镜像中必须已有 Python 3.7 或更新版本和 /etc/os-release，且断言保持启用。早期记录报告 Linux 6.12.76、Python 3.11.2，没有宿主机绑定挂载、特权模式或外部网络。这里没有复现该次运行；这些启动条件是前提，并非全部由脚本检查：

from pathlib import Path
from tempfile import mkdtemp
import errno,os,socket,subprocess,sys,time,uuid

def cleanup_steps(steps, primary):
 failures=[]
 for label, action in steps:
 try:action()
 except BaseException as error:
 failures.append(label+': '+type(error).__name__+': '+str(error))
 if failures:
 message='cleanup incomplete or uncertain: '+'; '.join(failures)
 try:print(message,file=sys.stderr)
 except (OSError,ValueError):pass
 if primary is None:raise RuntimeError(message)
 return failures

def remove_file(path):
 try:path.unlink()
 except FileNotFoundError:pass

def require_empty(value):
 if value:raise RuntimeError('residual resources: '+str(value))

assert os.geteuid()==0,'run inside a disposable read-only-root container as root'
assert os.statvfs('/').f_flag&os.ST_RDONLY
name='xbcatm-readonly-'+uuid.uuid4().hex
print('fixture root-tree probe:',name,flush=True)
for base in [Path('/'),Path('/usr'),Path('/etc')]:
 path=base/name
 fd=None
 try:
 try:fd=os.open(path,os.O_WRONLY|os.O_CREAT|os.O_EXCL,0o600)
 except OSError as error:assert error.errno==errno.EROFS,error
 else:raise AssertionError('root filesystem accepted a new file')
 finally:
 primary=sys.exc_info()[1]
 if fd is not None:
 cleanup_steps([('probe descriptor',lambda:os.close(fd)),('unexpected root-tree file '+str(path),lambda:remove_file(path))],primary)
print('even this root process receives EROFS on paths in the read-only root, usr and etc tree')
for base in ['/tmp','/work']:
 assert not os.statvfs(base).f_flag&os.ST_RDONLY
 directory=None
 try:
 directory=Path(mkdtemp(prefix='xbcatm-write-',dir=base))
 path=directory/'data';path.write_bytes(b'allowed');assert path.read_bytes()==b'allowed'
 path.write_bytes(b'changed');assert path.read_bytes()==b'changed'
 finally:
 primary=sys.exc_info()[1]
 if directory is not None:
 cleanup_steps([('temporary data',lambda:remove_file(directory/'data')),('temporary directory',directory.rmdir)],primary)
print('explicit tmpfs and data-volume mounts remain writable, including overwriting their contents')
assert Path('/etc/os-release').read_text()
result=subprocess.run([sys.executable,'-c','print("executed")'],capture_output=True,text=True,check=True,timeout=5)
assert result.stdout.strip()=='executed'
def remaining(deadline):
 seconds=deadline-time.monotonic()
 if seconds<=0:raise TimeoutError('loopback exchange deadline expired')
 return seconds

def receive_exact(connection,count,deadline):
 chunks=[];received=0
 while received<count:
 connection.settimeout(remaining(deadline))
 chunk=connection.recv(count-received)
 if not chunk:raise EOFError('loopback peer closed before the complete payload')
 chunks.append(chunk);received+=len(chunk)
 return b''.join(chunks)

listener=client=connection=None
try:
 deadline=time.monotonic()+5
 listener=socket.socket();listener.settimeout(remaining(deadline))
 listener.bind(('127.0.0.1',0));listener.listen(1)
 client=socket.socket();client.settimeout(remaining(deadline));client.connect(listener.getsockname())
 listener.settimeout(remaining(deadline));connection,_=listener.accept()
 client.settimeout(remaining(deadline));client.sendall(b'local')
 assert receive_exact(connection,5,deadline)==b'local'
finally:
 primary=sys.exc_info()[1]
 cleanup_steps([(label,sock.close) for label,sock in [('connection',connection),('client',client),('listener',listener)] if sock is not None],primary)
print('reading packaged files, executing an existing program, and loopback network I/O still work')

脚本先检查根文件系统报告的只读标志，再尝试在根、usr 和 etc 下排他创建唯一名字的文件。即使采用 root 身份，三次都得到 EROFS。唯一名称与排他创建保证探测不会覆盖既有配置文件。结果来自当前文件系统真正拒绝操作，而不是只看配置中出现了某个只读选项。

随后检查 tmp 与 work 不带相同只读标志，并在两处创建、读取和覆盖临时文件。这确认可写例外仍能工作，也说明这些位置的暴露面：根层设置不会保护特意可写的数据免受同一进程修改。正确部署既要验证拒绝了不需要的写入，也要验证真正需要的写入仍然可用。

读取 os-release 和执行已有 Python 解释器均成功，区分了只读存储与禁止读取或执行。保护打包文件免于被修改很有用，却不是对现有代码所能执行动作的全面限制。进程仍然拥有其他权限时，可以继续利用那些权限处理数据或启动程序，不能仅凭根层不可写就推断其行为范围。

最后，一个监听端与客户端通过回环交换无害数据。容器没有外部网络，但本地套接字仍然工作，展示文件系统选项本身不会关闭网络。这没有验证任何外部连通策略，也没有访问生产服务。实验把文件系统修改和通信操作分开观察，避免把一个设置误解为同时覆盖所有资源类型。

修订后的夹具尚未运行。接收累积短读并拒绝提前 EOF，与连接、接受连接和发送共享五秒单调时钟截止时间；解释器超时也是五秒。创建前建立保护，套接字及文件清理独立尝试，不替换最初异常，只有清理失败时也会失败。root 身份、容器标记和只读标志不证明隔离，须独立核验启动条件。启动器负责容器与卷销毁；失败后应检查报告的残留。进程创建、停滞的文件系统和突然终止仍不受这些限制约束。这些探针仅覆盖选定操作；根层写入失败不证明覆盖应用所有路径，也不限制未来新增可写挂载。真实服务是否完整可用，仍应由其具体调用路径和异常流程验证。

分开打包文件、临时空间与持久状态

可写路径应来自观察到的应用需要，并让程序明确使用这些位置。例外范围要小到能够解释用途。出现失败时，应定位所需路径和生命周期，而不是为了一个意外缓存或临时文件，就重新开放整个根层。这样既能修复真实功能要求，也能保留原本需要的修改边界。

tmpfs 适合相应临时数据，同时要考虑内存使用和生命周期。Docker 提醒，这些内存页仍可能进入交换空间，因此“由内存支持”不保证敏感字节绝不会写到持久介质；临时存储选择不能直接代替保密要求。状态需要独立于容器可写层保留时，应使用单独管理的卷，并配套备份和恢复。可写卷提供存储位置，却不会自动建立崩溃持久性、保密性或已经验证的恢复流程。位置选择和数据保证是相关但不同的设计事项。

对于 systemd 管理的服务，ProtectSystem 与指定状态、运行目录等机制，可以表达相关限制，但各自具有文档规定的语义。应验证服务真实视图和身份，不能只按选项名字在平台之间机械翻译。启动、普通工作、异常操作和清理都应被覆盖，并确认禁止和必需的写入分别符合预期。

来源

Docker container run reference，只读根文件系统与单独挂载的可写路径，已核验 2026-09-12。
Docker tmpfs mounts，临时挂载存储及生命周期，已核验 2026-09-12。
Docker volumes，独立于容器根层的卷生命周期，已核验 2026-09-12。
systemd 252 execution environment，ProtectSystem 与明确可写的服务目录，已核验 2026-09-12。

为 systemd 定时器选对时钟和补跑规则

Fri, 20 Nov 2026 00:00:00 +0000

一份计划必须先说清楚“时间”是什么意思。“纽约每天早上九点”指向民用日历，“任务结束十五分钟后”则指向经过时长和一个参考事件。systemd timer 同时支持这两类表达，但它们使用的时钟与起算点不同，在时区变化、系统休眠和定时器停用期间会表现出不同结果。只把它们统称为周期调度，会隐藏本来应该由需求决定的差别。

日历持久化请求一次补触发，不会逐个重放所有遗漏业务周期。日期与三个事件的例子来自原文；本图不增加定时器运行验证证据。

坏掉的样子

OnCalendar 按墙钟日历表达式触发，省略时区通常使用系统本地时区，因此同一份配置在不同机器上可能代表不同实际时刻。夏令时规则变化时，每天相同的本地时间也可能相对 UTC 移动。应使用固定参考日期预览预期表达式，而不是把今天的 UTC 偏移当成全年不变的事实。调度语法能解析，只证明表达式有效，不证明它符合业务要求的地区时间。

单调计时选项明确命名参考事件。OnActiveSec 从 timer 本身激活起算，OnStartupSec 从服务管理器启动起算，OnUnitInactiveSec 从目标单元结束活动起算。这些并不是“隔几分钟运行”的可互换写法。普通单调计时在系统休眠期间暂停，WakeSystem 会改变时钟选择，并依赖平台支持。因此是否计入休眠时间，也应该属于调度需求，而不是部署后的偶然发现。

Persistent=yes 对日历计时器生效。它记录触发时刻，在定时器恢复活动且至少错过一个事件时请求一次补触发；不会逐次重放所有错过的日历时刻，也不能证明上次业务执行成功。如果配置了随机延迟，补触发仍受其影响。触发历史不是一条持久业务队列，不能据此推定停机期间应做的所有工作都已完整保存。

快速验证

在 PID 1 为 systemd、安装了时区数据库的一次性 Linux 系统中，以管理员身份运行下面的 Python 脚本。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。脚本先预览日历表达式，再安装两个唯一命名的定时器与服务组合，双方使用同样三个即将到来的日历时刻，全程不会调整机器时钟：

from pathlib import Path
from tempfile import TemporaryDirectory
from datetime import datetime,timezone
import subprocess,time,uuid

name='xbcatm-calendar-'+uuid.uuid4().hex[:8]
names=[name,name+'-plain'];paths=[]
def run(*args):
 result=subprocess.run(args,text=True,capture_output=True,timeout=10)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
preview=run('systemd-analyze','calendar','--base-time=2026-03-07 00:00:00 UTC',
 '--iterations=3','*-*-* 09:00:00 America/New_York')
for expected in ('2026-03-07 14:00:00 UTC','2026-03-08 13:00:00 UTC','2026-03-09 13:00:00 UTC'):
 assert expected in preview,preview
print('09:00 New York: 14:00 UTC before spring DST, 13:00 UTC after it')
with TemporaryDirectory(prefix=name+'-',dir='/run') as directory:
 root=Path(directory);worker=root/'worker.py'
 worker.write_text("from pathlib import Path\nimport sys\np=Path(sys.argv[1])\nwith p.open('a') as output:output.write('run\\n')\n")
 now=int(time.time());events=[now+3,now+4,now+5]
 calendar=''.join('OnCalendar='+datetime.fromtimestamp(t,timezone.utc).strftime('%Y-%m-%d %H:%M:%S UTC')+'\n' for t in events)
 try:
 for index,prefix in enumerate(names):
 service=Path('/run/systemd/system')/(prefix+'.service');timer=service.with_suffix('.timer')
 assert not service.exists() and not timer.exists()
 service.write_text(f'[Service]\nType=oneshot\nExecStart=/usr/bin/python3 {worker} {root}/{index}.log\n');paths.append(service)
 timer.write_text('[Timer]\n'+calendar+'AccuracySec=1ms\nRandomizedDelaySec=0\nPersistent='+('yes' if index==0 else 'no')+'\n');paths.append(timer)
 run('systemd-analyze','verify',*[str(p) for p in paths]);run('systemctl','daemon-reload')
 run('systemctl','start',name+'.timer');run('systemctl','stop',name+'.timer')
 assert not (root/'0.log').exists() and time.time()<events[0]
 while time.time()<events[-1]+0.15:time.sleep(0.05)
 run('systemctl','start',name+'.timer',name+'-plain.timer')
 deadline=time.monotonic()+3
 while not (root/'0.log').exists():
 assert time.monotonic()<deadline,'catch-up did not run';time.sleep(0.02)
 time.sleep(0.15)
 assert (root/'0.log').read_text()=='run\n' and not (root/'1.log').exists()
 print('three elapsed calendar events: persistent timer catches up once; plain timer does not')
 run('systemctl','stop',name+'.timer');run('systemctl','start',name+'.timer')
 time.sleep(0.2);assert (root/'0.log').read_text()=='run\n'
 print('reactivating with no newly missed event does not replay the job')
 print('timer inactivity was tested without changing the system clock or rebooting')
 finally:
 if paths:
 run('systemctl','stop',*[p.name for p in paths])
 run('systemctl','clean','--what=state',name+'.timer')
 for path in paths:path.unlink(missing_ok=True)
 run('systemctl','daemon-reload')

预览从二〇二六年三月夏令时切换前的固定日期开始，询问纽约早上九点的后续发生时刻。第一次对应 UTC 十四点，后两次对应 UTC 十三点，本地钟表时间却始终是九点。这检查的是日历解释，并不是修改主机时区，也不是把系统时间跳到那些日期。对指定地区的每日任务而言，这种偏移变化可能正是正确行为。

持久化 timer 在第一个实验时刻到来前先启动，再停止；首次启动建立它的时间戳状态。停用期间，三个指定时刻全部经过。再次激活时，它恰好运行一次服务，结果文件只有一行。非持久化 timer 同样在这些时刻之后才激活，却没有生成结果文件。因此差别来自已经实际存在的停用区间及对应补触发策略，而不是两份命令做了不同的工作。

这个实验真实经历了定时器停用，没有手工修改时间戳文件来伪装漏跑，也不需要重启机器。三个过去事件合并为一次激活；如果应用必须处理三个独立结算周期，就需要自己发现并记录这些周期。不能让“已经补跑一次”的系统状态替代业务层对遗漏范围和处理结果的判断。

随后再次停止并启动持久化 timer，结果文件没有新增行，因为期间没有新的事件被错过。清理时先停止运行时单元，再通过 systemctl clean --what=state 删除持久化 timer 的状态；非持久化 timer 没有对应状态资源，不执行这项清理。最后删除配置文件和无害结果目录，让生命周期验证包括本次创建资源的实际回收。

实验把 AccuracySec 设为一毫秒，随机延迟设为零，让较短的过程容易观察。但这些设置不保证任意负载下进程都在精确时刻开始。代码会在有限等待窗口内观察实际完成，并断言调用次数，而不是把预测截止时间直接当成命令已经执行。计划时刻、管理器发出激活请求和程序开始运行，本来就是不同事件。

明确哪些漏掉的工作必须补齐

对于备份，停机后生成一份新的快照可能符合恢复策略；对于计费，每个遗漏周期可能都需要独立核对。这种差别应放进应用状态与幂等规则。服务在 timer 到点时已经活动，不会自动复制成另一个实例；保留活动状态的 oneshot，也可能阻止命令再次运行。因此补触发能力必须与目标服务生命周期一起考虑，不能只看 timer 配置。

检查调度时应查看已载入配置和下次、上次触发属性，检查执行时则查看目标服务结果。日历 timer 排在时间相关 target 之后，本身并不证明远端时间源已经完成校时；如果业务需要这个保证，实际时间服务配置必须提供它。只有顺序关系，没有兑现条件的服务，就不能当成可靠的同步屏障。

依赖一份计划之前，应验证有代表性的日期与生命周期变化，包括时区边界、定时器禁用和任务预期耗时。经过时长需求选择合适的单调参考事件，民用时间需求选择明确地区的日历规则。同时把“有用工作已完成”的证据与“管理器发出过触发”的证据分别保存，才能解释计划正确却业务结果缺失的情况。

来源

systemd 252 systemd.timer，参考时钟、日历持久化、精度与随机延迟，已核验 2026-09-12。
systemd 252 systemd.time，日历表达式与具名时区语法，已核验 2026-09-12。
systemd 252 systemd-analyze，固定参考时间的日历预览与多次发生时刻，已核验 2026-09-12。
systemd 252 systemctl，定时器激活与持久化状态清理，已核验 2026-09-12。

systemd 管理进程的启动、失败与停止

Sun, 01 Nov 2026 00:00:00 +0000

服务管理器把进程启动、失败和停止变成可以观察的状态变化。使用 systemd 时，单元可以明确前台命令、重启策略与输出目的地，不必再靠一个只会反复拉起程序、却说不清为什么停止的 shell 循环。但这并不能证明运行中的应用已经能响应请求，也不能证明重新启动一定修好了原来的故障。管理生命周期与验证业务可用性，需要各自成立。

对应主进程与运行实例，限制重启尝试，并单独检查应用就绪。主动停止不同于崩溃，重启计数不是可用性指标。

坏掉的样子

服务类型必须匹配程序的启动契约。Type=simple 很早就认为启动成功，此时可执行文件甚至还不一定已经成功执行。Type=exec 则等待执行程序成功，因此缺少可执行文件时，启动任务可以直接失败。不过，这两种类型都不会自动等待应用连接数据库、加载状态或完成业务初始化。看到启动命令返回成功，还不能据此开始向它发送必须成功的业务请求。

如果程序自行转入后台，就可能与预期前台主进程的单元不一致。应使用程序的前台模式，让管理器掌握生命周期，或者按照程序真实的守护化协议选择有文档依据的类型。不要靠进程名称搜索来猜主进程编号：名字可能重复，包装脚本也可能把错误的进程留作单元主进程，导致观察、停止和重启的对象都不符合预期。

重启策略也要有清楚边界。Restart=on-failure 覆盖的是规定的失败退出，并不是所有终止信号，更不是所有不健康状态。一个卡住却没有退出的进程，不会自动产生重启事件。应该结合有意义的应用健康观察与有限重试，而不是把单元状态为活动，直接等同于服务已经恢复对外工作。

快速验证

在 PID 1 为 systemd 的一次性 Linux 环境中，以管理员身份运行下面的 Python 脚本。它只写入明确命名的临时运行时单元和一个临时工作目录。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。执行前确认两个单元文件名尚未被使用，避免与已有服务混淆：

from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess,time

unit='xbcatm-supervise-lab.service';bad='xbcatm-exec-failure-lab.service'
unit_path=Path('/run/systemd/system')/unit;bad_path=unit_path.with_name(bad)
assert not unit_path.exists() and not bad_path.exists()
def run(args,success=True):
 result=subprocess.run(args,text=True,capture_output=True,timeout=10)
 assert (result.returncode==0)==success,(args,result.returncode,result.stderr)
 return result.stdout.strip()
def value(name,key):return run(['systemctl','show',name,'-p',key,'--value'])
def wait_for(check):
 deadline=time.monotonic()+5
 while not check():
 assert time.monotonic()<deadline,'state transition timed out'
 time.sleep(0.02)
with TemporaryDirectory(prefix='xbcatm-supervise-',dir='/run') as directory:
 root=Path(directory);worker=root/'worker.py';ready=root/'ready'
 worker.write_text("""from pathlib import Path
import os,signal,sys
signal.signal(signal.SIGTERM,lambda *_: sys.exit(0))
Path(__file__).with_name('ready').write_text(str(os.getpid()))
print('worker ready',flush=True)
while True: signal.pause()
""")
 unit_path.write_text(f'''[Unit]
Description=Disposable supervision exercise
StartLimitIntervalSec=10s
StartLimitBurst=3
[Service]
Type=exec
ExecStart=/usr/bin/python3 -u {worker}
Restart=on-failure
RestartSec=200ms
TimeoutStopSec=2s
StandardOutput=journal
StandardError=journal
''')
 bad_path.write_text(f'[Service]\nType=exec\nExecStart={root}/missing-program\n')
 try:
 run(['systemd-analyze','verify',str(unit_path)])
 run(['systemctl','daemon-reload']);run(['systemctl','start',unit])
 wait_for(lambda: ready.exists() and ready.read_text()==value(unit,'MainPID'))
 first=value(unit,'MainPID');assert first!='0'
 first_invocation=value(unit,'InvocationID')
 run(['systemctl','kill','--kill-who=main','--signal=KILL',unit])
 wait_for(lambda: value(unit,'MainPID') not in ('0',first) and ready.read_text()==value(unit,'MainPID'))
 assert int(value(unit,'NRestarts'))==1
 print('SIGKILL: replacement PID confirmed; NRestarts=1')
 run(['journalctl','--sync'])
 for invocation in (first_invocation,value(unit,'InvocationID')):
 logs=run(['journalctl','_SYSTEMD_INVOCATION_ID='+invocation,'--no-pager','-o','cat'])
 assert 'worker ready' in logs
 print('journal contains both application startups')
 run(['systemctl','stop',unit]);time.sleep(0.3)
 assert value(unit,'ActiveState')=='inactive' and value(unit,'MainPID')=='0'
 print('manager stop leaves service inactive')
 run(['systemctl','daemon-reload']);run(['systemctl','start',bad],success=False)
 assert value(bad,'Result')=='exit-code' and value(bad,'ExecMainStatus')=='203'
 print('Type=exec reports missing executable: status 203/EXEC')
 finally:
 run(['systemctl','stop',unit,bad])
 for name in (unit,bad):
 if value(name,'ActiveState')=='failed':
 run(['systemctl','reset-failed',name])
 unit_path.unlink();bad_path.unlink(missing_ok=True)
 run(['systemctl','daemon-reload'])

工作进程始终留在前台，并写出自己的启动标记。脚本等待该标记与管理器报告的主进程编号一致，再只向受管理的主进程发送 SIGKILL。随后确认编号发生变化，且自动重启次数为一，从而证明管理器确实替换了被终止的那个进程，并非只是原进程仍然存活，或者恰巧找到了同名程序。

日志检查使用前后两次运行的 invocation 标识，因此早先实验留下的同名单元日志不能替本次断言过关。每次运行都必须包含工作进程自己输出的启动消息。这同时检查了生命周期替换与两次实际进程输出的归属，不是只在多年积累的日志中找到一句熟悉文字，就认定当前启动已经正确记录。

显式执行管理器停止之后，等待超过重启延迟，单元仍为非活动状态，主进程编号为零。这是主动停止，不应被当成另一次需要自动修复的崩溃。另一个故障单元故意指向不存在的可执行文件，启动命令失败，并记录 203/EXEC。这个结果对应执行程序失败，不是数据库连通性故障，也不是应用层健康检查失败。

脚本在启动正常单元前验证定义，最后删除两个运行时单元文件。静态验证与成功运行是两类证据：前者检查管理器如何理解配置，后者观察真实进程行为。它们都不能替代一次生产端点检查，尤其不能从配置解析成功就推导应用的所有依赖已经满足。

让生命周期信息真正有用

部署时应让单元定义、运行时配置和应用就绪信号保持一致。把另一个单元排在本服务之后，排序的是管理器认定的启动完成；若依赖方需要更强的应用就绪保证，就应使用受支持的通知协议或明确的应用层检查。应用自身仍可能需要在启动期间重试短暂不可用的依赖，管理器排序并不会自动消除所有网络或外部服务故障。

使用 systemctl show 读取需要的具体状态属性，并在日志中对应到那一次运行。重复故障期间，主进程编号可能在两次观察之间变化，因此诊断要明确针对哪个实例。同时观察重启频率与有用工作是否恢复；一个成功增加的重启计数，本身不是可用性指标，也不能说明用户请求已经重新成功。

本实验把文件放在 /run/systemd/system，适合临时验证。正式服务还需要有意设计安装和启用策略、合适的运行身份，以及经过测试的停止流程。修改单元定义之后，需要让管理器重新加载配置；仅仅手动启动一次服务，不会自动安排它在下一次开机时再次启动。生命周期的每一段都应有明确的配置与验证依据。

来源

systemd 252 服务单元，启动类型与重启语义，已核验 2026-09-12。
systemd 252 执行环境，输出路由与执行退出码，已核验 2026-09-12。
systemd 252 单元配置，运行时单元路径与启动速率限制，已核验 2026-09-12。
systemd 252 journalctl，按记录字段查询与日志同步，已核验 2026-09-12。

维护定时器应让其最近结果可见

Tue, 04 Aug 2026 00:00:00 +0000

cron 式语法并不是维护任务契约的全部。命令需要一个清晰的服务身份、一个有界的运行时间，以及能区分"未调度"与"运行但失败"的证据。一个 systemd 定时器与 oneshot 服务能把这些关注点分开。

定时器触发只证明发生了调度事件。用服务结果、退出状态和新的时间戳判断本次运行。

把工作定义成服务

使用显式用户与绝对命令路径：

# /etc/systemd/system/site-check.service
[Unit]
Description=Read-only public site check

[Service]
Type=oneshot
User=sitecheck
ExecStart=/usr/local/bin/check-public-site
TimeoutStartSec=2min

TimeoutStartSec 限制 oneshot 的激活过程，其中包括命令运行时间；oneshot 默认没有启动超时。超时处理之后还可能需要停止超时，且不能立即结束不可中断的内核 I/O，因此工具本身也需要有界的网络请求。当契约失败时，helper 应返回非零退出码，并且不得修改它所检查的服务。

调度该服务

# /etc/systemd/system/site-check.timer
[Unit]
Description=每小时运行公共站点检查

[Timer]
OnCalendar=hourly
Persistent=true
RandomizedDelaySec=5min
Unit=site-check.service

[Install]
WantedBy=timers.target

若至少错过一次日历事件，Persistent=true 会在定时器重新激活时触发一次补跑；它不会逐小时重放所有错过的运行。补跑仍受随机延迟限制。RandomizedDelaySec 把一个窗口内的例行工作分散开；当任务必须在精确时刻运行时它并不合适。

启用前先验证

创建两个单元文件后，先验证并重载管理器，再手动启动服务。这些是在目标测试主机上的管理操作，不是只读检查：

systemd-analyze verify /etc/systemd/system/site-check.service \
 /etc/systemd/system/site-check.timer
systemd-analyze calendar hourly
systemctl daemon-reload
systemctl start site-check.service
systemctl status site-check.service
journalctl -u site-check.service -n 50 --no-pager
systemctl show site-check.service -p Result -p ExecMainCode -p ExecMainStatus

只有当服务在预期的用户、环境、路径与网络访问下成功时才启用定时器：

systemctl enable --now site-check.timer
systemctl list-timers site-check.timer

对服务结果告警

定时器触发并不等于成功。要监控 oneshot 服务的退出状态或日志结果。保持 stdout 简洁，调试需要的详细制品写入一个有界的路径。

成功的 oneshot 通常回到 inactive (dead)；这本身不是失败，systemctl status 对非活动服务可能返回非零。应将 Result、退出状态与新的日志时间戳对应，避免把旧运行的成功误认成本次结果。不要为了显示绿色而添加 RemainAfterExit=yes：服务仍处于活动状态时，重复定时器不会启动一个新实例。日历时间默认使用主机时区，而且常规定时器精度会在随机延迟之外增加调度余量。

来源

systemd.timer(5)，日历定时器、持久化与延迟行为，已核验 2026-08-04。
systemd.time(7)，日历表达式语法，已核验 2026-08-04。
systemd.service，oneshot 服务语义，已核验 2026-08-04。
systemd.service upstream manual (v257)，Type=exec/oneshot、就绪、激活超时与重启语义，已核验 2026-10-15。
systemd.timer upstream manual (v257)，持久化会合并错过的运行；活动单元、随机延迟与精度，已核验 2026-10-15。

重启策略需要一个速率限制

Mon, 03 Aug 2026 00:00:00 +0000

对长驻服务来说，自动重启很有用，但无界的循环会把一个清晰的失败变成一个嘈杂的失败。单元文件应同时描述正常进程生命周期与可接受的恢复量。

按配置窗口统计启动次数。启动速率限制可以停止快速反复重启，但不能证明健康，也不限制生命周期重试总数。

捕获启动失败

对长驻进程，Type=exec 能在启动时暴露配置程序执行失败，而不是把一次 fork 当成功。把它与显式的 ExecStart 以及能完成工作所需最小权限的 User 搭配使用。

[Unit]
Description=Example foreground site service
StartLimitIntervalSec=60s
StartLimitBurst=5

[Service]
Type=exec
User=site
ExecStart=/srv/site/bin/server
Restart=on-failure
RestartSec=5s

Type=exec 确认程序已执行，并不确认应用已就绪。程序应保持前台运行；应用支持显式就绪通知时可用 Type=notify。Restart=on-failure 是恢复策略，不是健康检查。如果进程在提供错误响应的同时保持存活，systemd 不会知道站点坏了；外部冒烟测试仍有其职责。

限制循环

Systemd 通过 StartLimitIntervalSec= 与 StartLimitBurst= 应用启动速率限制。这两个指令放在 [Unit]，RestartSec 放在 [Service]。示例允许 60 秒内启动五次；快速失败之间只有五秒重启延迟，因此可能达到限制。更长延迟可能让循环一直低于该速率：这并不是整个生命周期的重试次数预算。应按预期故障模式选择限制。当达到限制时，日志里应包含区分"重启成功"与"重复失败后放弃"所需的证据。

在获准使用的测试主机上安装或修改单元后，先验证文件、重载管理器并检查有效配置，再重启。下列命令会改变服务状态，可能中断流量：

systemd-analyze verify /etc/systemd/system/example.service
systemctl daemon-reload
systemctl cat example.service
systemctl show example.service -p Restart -p RestartUSec \
 -p StartLimitIntervalUSec -p StartLimitBurst
systemctl restart example.service
systemctl status --no-pager example.service
journalctl -u example.service -n 80 --no-pager

不要用重启策略掩盖缺失文件、无效权限或糟糕的环境。先修复第一次失败，再测试恢复路径。

启动限制停止自动重启后，单纯等到间隔结束不会自动排定下一次尝试。修复原因后，可等待间隔结束再启动，或有意识地用 systemctl reset-failed example.service 清除计数器后启动。在隔离服务中测试可执行文件缺失与快速崩溃，并保存第一次失败日志，不要只留下最后的“达到启动限制”消息。

来源

systemd.service，服务类型、重启与启动速率限制器，已核验 2026-08-03。
systemd.unit，通用单元段与 drop-in 语义，已核验 2026-08-03。
systemd.service upstream manual (v257)，Type=exec/oneshot、就绪、激活超时与重启语义，已核验 2026-10-15。
systemd.unit upstream manual (v257)，启动限制所属配置段、速率窗口与 reset-failed 行为，已核验 2026-10-15。

用实际拒绝结果验证 systemd 服务边界

Sat, 27 Jun 2026 00:00:00 +0000

服务加固应该把一种明确不需要的操作变为被拒绝的操作，同时保留应用必须完成的工作。systemd 为文件系统视图、命名空间、权限和其他资源提供执行设置，但这些是边界各不相同的独立控制。添加四条熟悉的指令，并不意味着所有可读文件、可接触进程、继承的文件描述符或允许的系统调用都会消失。判断依据应是配置的真实语义与进程的实际行为。

坏掉的样子

ProtectSystem=strict 让服务挂载命名空间内的大部分文件系统层级变为只读。只读不代表不可读取，而且该设置有文档明确的例外，例如还需要单独控制的接口文件系统。服务仍然可能泄露它能够读取的信息，也仍然可以破坏可写目录中的数据。因此应该先使用专用服务身份，列清必要访问，再选择对应限制，而不是把一个只读开关当成覆盖所有资源的隔离墙。

PrivateTmp=yes 给服务提供私有临时目录。如果应用原本依赖另一个服务通过普通 /tmp 交换文件，这项设置可能直接打断协作。PrivateNetwork=yes 创建拥有独立回环接口的网络命名空间，因此宿主回环上的监听器不再是里面的同一个端点。需要直接连接数据库或公共接口的程序，若没有有意安排所需连接，就不适合直接套用这一设置。应先查真实调用路径，不能假定网络隔离不会影响正常功能。

NoNewPrivileges=yes 阻止执行程序时通过设置用户身份的二进制文件、文件能力等机制取得新的特权，并不删除进程已经拥有的权限。同样，单独写一条 IPAddressAllow，不意味着其他地址全部被拒绝：地址过滤有允许与拒绝的优先关系，还依赖内核功能支持。选项名称不是完整安全策略，每项控制都需要按其契约理解，尤其不能把未验证的限制写成已经成立的保证。

不同 systemd 控制拒绝选定操作，同时保留受管理状态与临时写入。

快速验证

这个实验要求一次性 Linux 系统中的 root 身份、作为 PID 1 的 systemd、可用的挂载与网络命名空间、位于 /usr/bin/python3 的 Python 3.8 或更新版本，以及用户管理工具。保持 Python 断言启用；生成的 worker 必须能被服务账号读取。早期记录报告 Debian 12、systemd 252.39；这里没有复现该次运行。脚本创建唯一命名的账号、运行时单元、状态目录与文件。前后两阶段使用同一个非 root 工作负载：

from pathlib import Path
from tempfile import mkdtemp
import grp,json,os,pwd,socket,subprocess,sys,uuid

def cleanup_steps(steps, primary):
 failures=[]
 for label, action in steps:
 try:action()
 except BaseException as error:
 failures.append(label+': '+type(error).__name__+': '+str(error))
 if failures:
 message='cleanup incomplete or uncertain: '+'; '.join(failures)
 try:print(message,file=sys.stderr)
 except (OSError,ValueError):pass
 if primary is None:raise RuntimeError(message)
 return failures

def remove_file(path):
 try:path.unlink()
 except FileNotFoundError:pass

def require_empty(value):
 if value:raise RuntimeError('residual resources: '+str(value))

suffix=uuid.uuid4().hex[:12];name='xbcatm-hardening-'+suffix
unit=name+'.service';unit_path=Path('/run/systemd/system')/unit
state=Path('/var/lib')/name;marker=Path('/tmp')/(name+'-marker');scratch=Path('/tmp')/(name+'-scratch')
assert os.geteuid()==0,'requires an explicitly prepared disposable systemd test system'
for path in [unit_path,state,marker,scratch]:assert not os.path.lexists(path),path
def account_exists():
 try:pwd.getpwnam(name);return True
 except KeyError:return False
def group_exists():
 try:grp.getgrnam(name);return True
 except KeyError:return False
assert not account_exists() and not group_exists()
def command(args):
 result=subprocess.run(args,capture_output=True,text=True,timeout=10)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def ctl(*args):return command(['systemctl',*args])
def delete_account():
 if account_exists():command(['userdel',name])
def delete_group():
 if group_exists():command(['groupdel',name])
root=None;listener=connection=None;owned_files=[];account_attempted=False;unit_attempted=False
# Reserve each ordinary file exclusively and record it before writing or chmod.
def create_file(path,text,mode):
 with path.open('x') as output:
 owned_files.append(path)
 output.write(text)
 path.chmod(mode)
print('fixture:',name,'unit:',unit_path,'state:',state,'marker:',marker,'scratch:',scratch,flush=True)
try:
 root=Path(mkdtemp(prefix=name+'-',dir='/run'));root.chmod(0o755)
 outside=root/'outside';create_file(outside,'initial\n',0o666)
 create_file(marker,'host namespace marker\n',0o644)
 create_file(scratch,'',0o666)
 listener=socket.socket();listener.settimeout(2)
 listener.bind(('127.0.0.1',0));listener.listen(2)
 worker=root/'worker.py'
 create_file(worker,r"""from pathlib import Path
import json,socket,sys
root=Path(__file__).parent;state=Path(sys.argv[1]);marker=Path(sys.argv[2]);scratch=Path(sys.argv[3]);port=int(sys.argv[4]);phase=sys.argv[5]
result={}
try:
 with (root/'outside').open('a') as output:output.write(phase+'\n')
 result['outside_write']=True
except OSError as error:result['outside_write']=False;result['outside_errno']=error.errno
result['host_tmp_visible']=marker.exists()
scratch.write_text(phase);result['tmp_write']=scratch.read_text()==phase
try:
 with socket.create_connection(('127.0.0.1',port),timeout=0.5):pass
 result['network_connect']=True
except OSError as error:result['network_connect']=False;result['network_errno']=error.errno
status=dict(line.split(':',1) for line in Path('/proc/self/status').read_text().splitlines() if ':' in line)
result['no_new_privs']=status['NoNewPrivs'].strip()
(state/'result.json').write_text(json.dumps(result))
""",0o644)
 definition=f'''[Service]
Type=oneshot
User={name}
Group={name}
StateDirectory={name}
StateDirectoryMode=0700
TimeoutStartSec=5s
TimeoutStopSec=5s
KillMode=control-group
ExecStart=/usr/bin/python3 {worker} {state} {marker} {scratch} {listener.getsockname()[1]} PHASE
'''
 account_attempted=True
 command(['useradd','--system','--no-create-home','--user-group','--shell','/usr/sbin/nologin',name])
 create_file(unit_path,definition.replace('PHASE','baseline'),0o644)
 unit_attempted=True
 ctl('daemon-reload');ctl('start',unit)
 baseline=json.loads((state/'result.json').read_text())
 assert baseline=={'outside_write':True,'host_tmp_visible':True,'tmp_write':True,'network_connect':True,'no_new_privs':'0'},baseline
 connection,_=listener.accept()
 connection.close();connection=None
 original=outside.read_text()
 settings='ProtectSystem=strict\nPrivateTmp=yes\nPrivateNetwork=yes\nNoNewPrivileges=yes\n'
 unit_path.write_text(definition.replace('PHASE','hardened')+settings)
 command(['systemd-analyze','verify',str(unit_path)])
 ctl('daemon-reload');ctl('start',unit)
 hardened=json.loads((state/'result.json').read_text())
 assert hardened['outside_write'] is False and hardened['outside_errno']==30,hardened
 assert hardened['host_tmp_visible'] is False and hardened['tmp_write'] is True
 assert hardened['network_connect'] is False and hardened['network_errno']==111,hardened
 assert hardened['no_new_privs']=='1'
 assert outside.read_text()==original and scratch.read_text()=='baseline'
 print('baseline: outside write, host tmp visibility, loopback connection permitted; NoNewPrivs=0')
 print('hardened: outside write=EROFS; host tmp hidden; host listener refused; NoNewPrivs=1')
 print('managed state directory and private temporary writes still succeed')
finally:
 primary=sys.exc_info()[1];failures=[];quiescent=not unit_attempted
 # A failed stop does not skip the independently attempted state query or socket close.
 def attempt(label,action):
 try:return action()
 except BaseException as error:
 failures.append(label+': '+type(error).__name__+': '+str(error))
 if unit_attempted:
 attempt('stop '+unit,lambda:ctl('stop',unit))
 status=attempt('unit state',lambda:ctl('show',unit,'-p','ActiveState','-p','MainPID','-p','ControlPID'))
 if status is not None:
 properties=dict(line.split('=',1) for line in status.splitlines() if '=' in line)
 quiescent=properties.get('ActiveState') in ('inactive','failed') and properties.get('MainPID')=='0' and properties.get('ControlPID')=='0'
 if connection is not None:attempt('accepted socket close',connection.close)
 if listener is not None:attempt('listener close',listener.close)
 if quiescent:
 if unit_attempted:
 attempt('reset failed state',lambda:ctl('reset-failed',unit))
 for path in reversed(owned_files):attempt('file '+str(path),lambda path=path:remove_file(path))
 if unit_attempted:attempt('daemon reload',lambda:ctl('daemon-reload'))
 if unit_attempted and os.path.lexists(state):
 if state.is_symlink():failures.append('unexpected state symlink; retained '+str(state))
 else:
 attempt('state result',lambda:remove_file(state/'result.json'))
 attempt('state directory',state.rmdir)
 if account_attempted:
 attempt('account '+name,delete_account)
 attempt('group '+name,delete_group)
 if root is not None:attempt('temporary directory '+str(root),root.rmdir)
 for path in owned_files+([state] if unit_attempted else [])+([root] if root is not None else []):
 attempt('absence '+str(path),lambda path=path:require_empty(str(path) if os.path.lexists(path) else ''))
 if account_attempted:
 attempt('account absence',lambda:require_empty(name if account_exists() else ''))
 attempt('group absence',lambda:require_empty(name if group_exists() else ''))
 else:
 failures.append('unit may still run; retain its unit, account/group, state and files for manual recovery: '+name)
 if failures:
 message='cleanup incomplete or uncertain: '+'; '.join(failures)
 try:print(message,file=sys.stderr)
 except (OSError,ValueError):pass
 if primary is None:raise RuntimeError(message)

修订后的夹具尚未运行，只能使用独占控制的一次性系统；root 身份或容器标记不证明隔离。准备前建立保护，预检 scratch、账号和组，排他创建文件，并把 worker 与目录权限设为 0644/0755；ACL 仍须核验。管理命令设十秒超时，单元启动及停止限五秒，接受连接限两秒。停止失败不会跳过状态检查或套接字关闭；服务状态不明时保留文件与账号，供人工恢复。其余删除及残留检查独立尝试；错误不替换最初异常，只有清理失败时也会失败。超时操作稳定后须检查打印出的名称。进程创建、文件系统或 NSS 停滞与突然终止仍不受时限约束。

基线阶段故意让该账号能够写入一个样本文件，同时在管理器看到的临时目录里创建标记，并在其回环接口启动监听器。尚未加限制时，工作进程能够追加文件、看到标记、连接监听器，且读取到零值的 NoNewPrivs 标志。这一步排除了普通文件权限本来就禁止写入、或者监听器根本不存在等混淆因素，之后的拒绝才有明确对照。

加固阶段加入四项执行设置，然后重复同样的探测。外部样本文件写入以 EROFS 失败，因此不是仅仅因为文件所有者不匹配而失败。原来的临时标记在新视图中不可见，连接原监听端点得到 ECONNREFUSED，而进程报告 NoNewPrivs=1。这些证据来自实际工作进程，不是只检查单元解析器是否认识几个配置名字；每个结果都对应本次改变的具体边界。

必要的写入仍然成功：StateDirectory 创建服务使用的受管理可写状态位置，私有临时目录也允许写入自己的样本文件。从管理器命名空间观察，同名临时文件仍保留基线阶段的内容，说明第二次写入发生在另一份临时目录视图中。外部样本文件同样保持此前内容，进一步确认失败操作没有悄悄改变目标文件。

脚本断言这些精确结果，并在启动前验证修改后的单元定义。它没有测试漏洞利用、系统调用过滤或基于 BPF 的地址策略。因此本实验是在配置检查之外，补上所展示几项控制的运行时证据，而不是声称所有可能的访问路径都已经被封闭。部署时如果增加其他控制，应为那些控制寻找对应的行为验证，不能借用本例结果替代。

让必要访问保持明确

限制应施加在真实部署的服务定义上，同时考虑覆盖文件和执行身份。可写路径例外改变的是挂载视图，不会授予普通 Unix 文件权限，也不能让底层本来只读的文件系统变成可写。若状态、缓存或运行时目录的生命周期和所有权契约适合应用，优先使用对应的受管理目录，减少手工建目录造成的权限和清理差异。

加固之后，应按应用实际支持的能力检查启动、正常请求、维护、重载与停止。一个命令刚运行一次成功，仍可能在稍后轮转文件或建立新连接时失败。应定位具体被拒绝的操作，调整真正必要的边界，并保留“服务完成有用工作”与“不需要的操作仍被阻止”两类检查。这样配置才能说明当前已验证的限制，而不是一份看似严格却与工作负载脱节的开关清单。

来源

systemd 252 执行环境，挂载命名空间、受管理目录、私有网络与权限控制，已核验 2026-09-12。
systemd 252 资源控制，IP 允许与拒绝规则的优先关系和实现条件，已核验 2026-09-12。
systemd 252 分析命令，单元验证及其范围，已核验 2026-09-12。

Systemd · XB 现场笔记

systemd 依赖要区分激活、顺序与就绪

坏掉的样子

快速验证

让依赖关系对应失败语义

延伸阅读

来源

socket 激活让服务按需启动

让监听器先等着

服务按需唤醒

用速度换内存

坏掉的样子

快速验证

延伸阅读

来源

systemd-tmpfiles 执行创建与年龄策略

坏掉的样子

快速验证

让维护策略匹配数据生产者

延伸阅读

来源

systemd oneshot 完成的是一次激活

坏掉的样子

快速验证

任务自身仍要保证正确性

延伸阅读

来源

Socket 激活把监听器交给兼容的服务

坏掉的样子

快速验证

同时设计交接与停止

延伸阅读

来源

systemd 重启策略要明确失败与限流规则

坏掉的样子

快速验证

恢复服务，而不是只清空计数

延伸阅读

来源

systemd journal 的保留范围需要明确约定

坏掉的样子

快速验证

按需要保留证据

延伸阅读

来源

按明确的字段与优先级规则查询 journal

坏掉的样子

快速验证

导出时保留上下文

延伸阅读

来源

systemd timer 安排服务启动，不保证任务成功

坏掉的样子

快速验证

同时迁移执行契约

延伸阅读

来源

systemd-sysusers 创建缺少的服务账号

坏掉的样子

快速验证

明确打包时点与身份规则

延伸阅读

来源

Linger 延长 systemd 用户管理器在登录之外的寿命

坏掉的样子

快速验证

有意管理无人值守账号

延伸阅读

来源

分别检查 timesyncd 服务状态与时钟证据

坏掉的样子

快速验证

建立能够验证的时间要求

延伸阅读

来源

EnvironmentFile 在 systemd 执行进程时供应取值

坏掉的样子

快速验证

有选择地暴露配置信息

延伸阅读