Linux · XB 现场笔记

LVM 快照在时间上定格一块块设备

Mon, 10 Apr 2028 00:00:00 +0000

经典 LVM 快照是在源逻辑卷上附加写时复制异常存储。lvcreate -s -L 5G -n snap vg/data 请求五 GiB 存储，实际分配还受卷组空闲容量和分配粒度约束。创建时不需要复制整份源卷，但不代表完全没有工作或必然瞬时完成。thin 快照使用另一种共享池机制，不能把经典快照的独立异常存储套到所有 LVM 快照上。

异常存储要覆盖整个保留窗口内发生变化的不同 chunk 及其元数据，包括备份复制期间的写入。突发负载可能比安静时估算更早耗尽容量。经典存储满后快照会失效，读取开始返回错误。应提前观察有效状态和增长趋势，留下扩容或结束备份的时间；只规定一个百分比告警，而没有响应能力与空闲空间，不能形成可靠恢复计划。

异常存储，不是副本

源使用 snapshot-origin 目标，snapshot 则把未变化的源 chunk 与保存的异常组合成视图。直接写快照的数据进入它自己的 COW 设备。对已保存异常的同一 chunk 反复修改，不需要为这份快照再保存一次原始内容。原文一百万次写入、十六个热块却只有十五个异常的数字，没有找回轨迹；若十六个不同 chunk 都写过，就需十六份数据异常，另加元数据。

lvs -a -o lv_name,lv_attr,origin,data_percent,lv_size 展示类型、状态和用量。swi-a-s--- 只是示意，不是所有快照固定的属性串；第五位 I 表示无效快照。告警应覆盖实际增长速率和处理时间。lvextend 需要 VG 中有可分配空间；lvchange --monitor y 只启用监控，自动扩容还依赖 dmeventd、有效扩容策略及足够容量，并不是一个开关就能保证成功。

耗尽即失效

内核文档说明，经典 COW 存储耗尽后会禁用快照并返回错误。lvcreate 手册中按源容量百分之二十创建的命令只是例子，不是通用容量建议。规划要包含 chunk 粒度、元数据、突发变化及完整备份时长。在耗尽之前扩容才有助于维持有效快照；恢复点已经失效时，不能因为 LV 名字仍在，就把它当作内容完整的历史状态。

经典快照溢出时源卷写入通常继续，但这不保证源卷或底层设备不会同时出现其他问题。无效快照不能再作为可用恢复点，却不等于它从未存在；此前已经完成并验证的独立备份可能仍有效。当前快照是否可读，与另一处已完成副本是否完整，应分别核对。不能用夸张的比喻替代这两个不同状态，也不能以源服务还在运行推断快照健康。

合并回滚，以及 thin 如何改变失败形态

lvconvert --merge vg/snap 将持久化 COW 快照合并回源，并消耗该快照。源与快照两个 LV 都未打开时立即开始，否则延后至二者关闭时的激活机会。合并开始后源可以继续服务读写，必要的受影响写入会等待对应 chunk 完成。这里不保证回滚全程无需中断，而且源上较新的数据可能被丢弃；停用应用、关闭使用者和确认恢复目标都需要明确安排。

thin 快照与其他 thin LV 共用池的数据及元数据容量，不拥有单独定额的经典 COW 存储。数据空间满时，依策略可能先排队写入，也可能立即返回错误；元数据耗尽又是另一种失败。问题可以影响多个卷及文件系统，却不等于每个卷瞬间全毁。必须同时监控池的两种百分比、满池行为与可扩容能力，不能只观察某一份快照的虚拟大小。

坏掉的样子

块级快照不会自动成为应用一致的备份。文件系统与数据库缓冲、日志，以及跨卷存放的数据，都需要协调并在还原时正确恢复。复制过程中要检查快照有效性、传播读取错误，之后验证内容与还原结果。命令成功退出或挂载成功都不能证明备份完整；本轮没有进行 LVM 创建、耗尽、扩容或合并实验，也没有用一个内存模型替代这些系统验证。

安排合并前，应识别源与快照双方的打开者，规划应用停机或激活边界。先在一次性卷上演练，并另留独立备份。容量要覆盖整个保留窗口的不同块变化，不能只按其中最忙一小时计算。完成后还需确认实际卷及应用状态，不能仅凭分配计数下降宣布恢复成功。原来的设备名也必须绑定到测试目标，不能直接借用生产卷路径。

LVM 保留变化前的 chunk：机制图。

快速验证

以下原命令保持不变并暂缓执行。名称依赖具体环境，也需要已授权的 LVM 访问；其中 lvextend 会改变分配，因此整段不是只读诊断。本轮未执行 device-mapper、内核、逻辑卷或挂载操作，不能把这些命令列在文章里就说验证已完成：

lvs -a -o lv_name,vg_name,lv_attr,origin,data_percent,lv_size
lvs -a -o lv_name,data_percent,metadata_percent vg/thinpool
dmsetup status vg-snap
lvextend -L +2G vg/snap

经典快照的 Data% 与有效状态，不同于 thin 池的 Data% 和 Meta%。dmsetup status 格式取决于目标类型：普通快照分配不必下降，而 snapshot-merge 可向仅剩元数据的状态递减。最后一行既不证明 VG 有空闲容量，也不能使无效快照复活。完整实验需要绑定目标并逐步验证状态变化，相关可执行修改单独保留为暂缓提案。

来源

lvcreate(8)，说明 -s/--snapshot、COW 与 thin 快照的区别以及容量命令示例，已核验 2026-09-16。
lvs(8)，定义 lv_attr 状态位，含无效快照，已核验 2026-09-16。
Device-mapper snapshot 支持，异常存储、失效语义与 lvconvert --merge 行为，已核验 2026-09-16。
lvmthin(7)，thin 快照、池耗尽与自动扩容，已核验 2026-09-16。
lvconvert(8)，立即与延后合并以及卷打开状态条件，已核验 2026-10-18。
PostgreSQL filesystem backup，一致快照范围、WAL 与多卷恢复要求，已核验 2026-10-18。

SYN backlog 保存未完成握手的请求

Fri, 24 Mar 2028 00:00:00 +0000

监听中的 TCP 套接字会区分未完成握手的请求，以及已经建立、等待应用 accept() 的连接。真正的参数名是 tcp_max_syn_backlog；本文保留历史 URL 中的拼写。它约束的是内核记住的半开请求，而传给 listen() 的 backlog 约束 accept 队列。先弄清压力发生在哪个阶段，再考虑处理办法，否则调大一个数字很可能没有解决真正的问题。

SYN cookies 是无法继续保存普通握手状态时的兜底机制。它不代表服务器不会过载、不保证报文送达，也不意味着 SYN 队列从此无需关注。即使启用了 cookies，丢包、过滤、资源分配失败和 accept 侧压力仍然可能让连接失败。判断时必须把握手状态、应用接收速度与最终业务响应分开。

SYN 队列保存未完成握手的请求，accept 队列保存已建立、等待 accept() 的连接。仅当 listen backlog 配置为 8192、somaxconn 为 4096 时，accept 侧上限为 4096。增加等待容量本身不会提高处理速率；原文全文仍暂缓、待审。全文仍暂缓、待审；本图不为文中存疑论断背书。

backlog 参数管的是 accept 队列

Linux 从 2.2 起改变了 listen() backlog 的含义。配置值会受到 somaxconn 限制；只有当两者分别是 8192 和 4096 时，配置上限才是 4096。这是条件明确的配置例子，不是一次测量得到的精确接纳数量。应查看实际监听套接字与其网络命名空间，不能假定默认值，也不能根据短促突发中恰好成功的连接数反推严格容量。

内核文档将 tcp_max_syn_backlog 定义为每个监听套接字记住的 SYN_RECV 请求数限制，初始值与内存及内核实现有关。旧手册中的内存分档不能当作当前机器的实际配置。任何一个队列的长度，都不能单独说明应用每秒能完成多少请求；排队等待和处理能力是不同的观测维度。

SYN cookies 仍然只是兜底

在内核支持该功能的前提下，tcp_syncookies=1 启用溢出兜底；值 2 是无条件发送 cookies 的测试模式。listen 手册所说的取消逻辑长度限制，描述的是不为每个请求保存状态的接纳路径，并不是无限内存、CPU、带宽或已建立套接字。面对合法流量造成的压力，内核文档仍建议结合应用消化工作的能力，考虑 SYN backlog 等相关配置，而不是宣布这个参数已经过时。

也不能保证每条 cookie 连接都会失去 SACK 和窗口缩放。固定到 Linux v6.12 的实现，在协商时间戳时可以把这些选项编码进时间戳位；具体能保留什么，取决于实现和协商结果。这个限定结论既不等于保留所有 TCP 扩展，也不意味着紧急兜底可以代替容量规划。直接关闭 cookies 同样不是普遍适用的修复方案。

压力真正落在 accept 队列上

accept 侧与 SYN 侧的压力可以同时存在。在 Linux v6.12 的普通握手路径里，创建子套接字失败可能进入溢出分支；当 tcp_abort_on_overflow 关闭时，服务端可以保留请求，而不是立即复位。此时客户端可能已经认为连接建立，后续应用通信却停滞。这是一种可能出现的状态不一致，不能推导为每次 connect() 都必定成功。

更大的队列可以容纳有限突发，也可能增加等待时间，但它本身不能证明稳态处理能力提高。应一起测量到达速率、accept 等待时间和应用完成情况。本文没有实测每秒 20,000 次连接的数据，也不把未提供的模型结果当作吞吐证据。

坏掉的样子

溢出计数器增长值得调查，但不能唯一归因于某个处理线程。accept 循环的调度、资源耗尽、同一网络命名空间中的其他监听套接字，以及两次采样之间的突发，都会影响解释。历史累计值非零，不等于当前正在发生故障；仅凭一次截图也无法还原事件顺序或受影响的请求。

启用 cookies 时仍然可能丢失 SYN。客户端重试时间取决于内核版本、重试配置、套接字行为与应用截止时间，67 秒或 131 秒都不是通用超时承诺。TCP 连接成功也不等于应用请求完成，排查时需要保留两者各自的结果，而不能把连接阶段的成功当作业务层恢复。

快速验证

下面是网络状态观察练习，仅适用于已获授权的 Linux 系统：8443 端口已有监听者，且当前处于它所在的网络命名空间，ss、nstat 和 sysctl 已经安装。不要为了练习启动监听者、制造过载、修改参数或提升权限。本轮审查没有运行这些命令，也没有取得新的内核行为证据。

ss -lnt 'sport = :8443'
nstat -az TcpExtListenOverflows TcpExtListenDrops TcpExtTCPReqQFullDrop TcpExtTCPReqQFullDoCookies
sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog net.ipv4.tcp_syncookies net.ipv4.tcp_abort_on_overflow

在已经获准的普通工作负载前后各取一次快照。对监听中的 TCP 套接字，Recv-Q 表示排队等待接收的已建立连接，Send-Q 表示实际 backlog 限制。输出为空表示没有可见的匹配监听者，不表示队列长度为零。当前 sysctl 值也不能倒推已有监听者创建时的配置；应记录监听上下文，避免把别的命名空间当成目标。

nstat -az 显示包含零值的绝对计数，并可能更新本地历史；应比较同一观察区间的增量。这几个计数器提供溢出、请求丢弃和 cookie 兜底的不同线索，但它们属于整个网络命名空间，也不是彼此互斥的单监听者判决。提出调优方案前，记录内核版本、监听上下文和应用请求结果。缺少工具、访问权限或隔离测试环境时，运行时结论继续保持未决，不为补齐证据放宽安全边界。

来源

内核 ip-sysctl 文档，SYN 请求限制、cookie 模式与过载处理建议；保留早期核验日期 2026-09-16，已核验 2026-10-19。
Linux listen(2)，accept backlog 的含义及 somaxconn 配置上限；保留早期核验日期 2026-09-16，已核验 2026-10-19。
Linux tcp(7)，与版本相关的配置及重试行为；保留早期核验日期 2026-09-16，已核验 2026-10-19。
Linux v6.12 cookie 实现，利用时间戳编码 SACK 和窗口缩放，已核验 2026-10-19。
Linux v6.12 握手实现，有条件进入的 listen_overflow 分支，已核验 2026-10-19。
iproute2 nstat 手册，绝对计数与零值显示选项，已核验 2026-10-19。

iotop 能看出是哪个进程在烧磁盘

Wed, 15 Mar 2028 00:00:00 +0000

iotop 把任务级内核统计接入系统整体的存储调查，可以帮助发现报告大量 IO 或等待的任务，但这两种观察并不相同。被其他工作阻塞的任务，可能是受影响者，而不是争用的来源。内核计数器也不为每种文件系统、缓存与存储层提供完美归因，不能把一个列表直接当成责任判决。

把 iotop 与设备指标、应用延迟放在一起看。活跃写入者或较高等待值，单独都不足以证明存储瓶颈。先比较同一时段，再决定检查哪个组件；两个命令的输出可以形成线索，却不会自动结束调查。应明确自己看到的是工作量、等待时间，还是实际设备完成的操作。

逐个进程的计数器

先核对安装的实现与版本。所引用的 iotop-c 已在主进程行中汇总线程活动；-P 只是隐藏单独的线程行。其他变体应核对各自手册，不能把显示选项误写成首次发生汇总。-o 根据观察到的 IO 活动过滤，不会判断工作是否有害。读写字节速率与 IO 等待百分比单位不同，不能把它们当作同一种消耗排名，也不能只凭一列高低决定是否应终止进程。

Linux 的 read_bytes 统计存储层读取，缓存命中的读取不一定产生这类字节。write_bytes 在页面变脏时记账，不一定等到设备完成写入；取消写入与稍后的回写，会让任务总量和设备吞吐不同。延迟统计记录任务等待，包括同步块 IO 等待；CPU iowait 是另一种整体指标，不能作为可靠的逐任务归责依据。页面缓存中的活动、进程等待和设备忙碌，需要分别解释。

看到谁在扫盘

明确选择排序列，并观察足够时间，区分持续工作和短促突发。写入速率高可能来自预期的备份、索引构建或日志任务。修改调度、限额之前，要关联进程归属、应用角色与当时业务。排名靠前只说明值得进一步检查，不会直接告诉你应轮转日志、迁移任务还是终止进程，正常的批处理也可能占据榜首。

在正确的 PID 命名空间中解析任务，并确认该标识仍指向预期进程。命令行、父子关系与打开文件能够提供上下文，但打开某个文件不证明全部写入都去了那里。两次读取之间 PID 可能复用，陈旧号码可能已经属于无关任务。容器内外看到的号码也可能不同，必须把身份与观察范围一同记录，避免把一个范围中的统计匹配到另一个范围中的进程。

先看再动

观察本身有成本与访问要求。进一步的系统调用追踪可能扰动进程并暴露参数，需要另外获准且范围明确的调查。追加标志属于打开文件时的设置，不是每次 write 系统调用携带的标志。不能把虚构的吞吐、打开文件与追踪输出组合成一次已测得的诊断，也不能看到文件存在就推断写入路径已被证明。

记录基线条件：工具实现、间隔、进程或线程模式、是否累计，以及可比较的业务负载。按文档默认的一秒间隔，-b -n 60 大约是一分钟，不是五分钟，还要考虑启动与首份报告。设备 await 包含排队与服务时间；接近百分之百的利用率，并不能在所有并行 SSD 或 RAID 上证明吞吐已经饱和。

把任务与设备数据按时间对齐，再比较变化。排名变化不等于工作量变化，同一任务可能因其他任务减少而上升。基线也不应靠固定的名次差或任意周期间隔决定是否异常；应结合实际速率、持续时间和应用目标解释，保留采集条件，避免将不同窗口或不同汇总方式直接相减。

坏掉的样子

缺少权限、内核统计选项，或未启用任务延迟统计，可能导致失败或字段不可用。空白显示不能证明自己的进程没问题，更不能证明其他用户的进程无关。应记录实际限制与所需环境，不能悄悄更改能力或内核设置来让工具运行。有些延迟统计配置变化只对之后启动的任务生效，不能假定已有进程立即具有完整历史。

突发活动可能被平均值稀释，短命任务也可能逃过采样。改变间隔会改变可见范围。累计模式汇总适用生命周期内观察到的统计，不会找回没有记录的上一小时，也不保证完整覆盖已经退出的任务。每个结论都应注明观察窗口；没有采到事件与事件从未发生，不能视为同一件事。

按同一时段对照任务字节、等待与设备观察。采集与当前身份核验尚未运行；不能排除早先 PID 复用或认定责任。

快速验证

以下尚未运行的提案面向引用的 iotop-c 接口与 sysstat iostat，先确认实际安装的实现，不能假定所有同名工具支持相同选项。它完整保存报告、标准错误与两个退出状态，不从文本自动选取进程。新建配置目录可以避免原先保存的 iotop 偏好悄悄改变显示模式；临时目录需要保留，便于复查失败信息和时间范围。

(
 capture=$(mktemp -d) || exit 1
 printf 'Evidence directory: %s\n' "$capture"
 iotop --version || exit $?
 iostat -V || exit $?
 LC_ALL=C iostat -x -y -t 2 5 > "$capture/iostat.txt" 2> "$capture/iostat.err" &
 stat_pid=$!
 if LC_ALL=C XDG_CONFIG_HOME="$capture" iotop -b -P -k -t -d 2 -n 5 \
 --no-only --no-accumulated --no-accum-bw \
 > "$capture/iotop.txt" 2> "$capture/iotop.err"; then
 task_status=0
 else
 task_status=$?
 fi
 if wait "$stat_pid"; then stat_status=0; else stat_status=$?; fi
 printf 'iotop_status=%s iostat_status=%s\n' "$task_status" "$stat_status"
 cat "$capture/iotop.err" "$capture/iostat.err"
 [ "$task_status" -eq 0 ] && [ "$stat_status" -eq 0 ] || exit 1
 cat "$capture/iotop.txt" "$capture/iostat.txt"
)

iotop-c 的主进程行已经包含线程活动；-P 隐藏单独线程行，固定千字节单位与非累计模式便于比较各列。这里的批量采集不承诺按写入量降序排列；应在每份报告中比较带标签的 DISK WRITE 数值。需要交互式排名时，明确选择该列与降序方向，不能把第一行直接当成最大写入者。排名与进程身份依然是两个独立问题。

按时间戳只比较重叠间隔，两个命令并没有完全同步启动；-y 排除 iostat 开机以来的首份报告。缺少计数器、非零状态或不完整窗口都会破坏比较，不能仅凭排名认定责任进程。

将下面的辅助程序保存为 inspect_io_process.py，再从完整报告中人工选定进程 PID；读取时必须使用同一 PID 命名空间。它要求 Python 3.9 以上、内核支持 pidfd，且相关 proc 项可读。权限、进程消失或 pidfd 不可用时应停止，不能退回猜测身份：

"""Read-only Linux identity snapshot; requires Python 3.9+ and pidfd support."""
import json
import os
import re
import select
import sys


def snapshot(token, proc_root="/proc", ops=os, poll_factory=select.poll):
 if not re.fullmatch(r"[1-9][0-9]*", token):
 raise ValueError("PID must be a positive decimal process ID")
 pid = int(token)
 pidfd = ops.pidfd_open(pid, 0)
 directory = None
 try:
 directory = ops.open(f"{proc_root}/{pid}", os.O_RDONLY | os.O_DIRECTORY)
 watcher = poll_factory()
 watcher.register(pidfd, select.POLLIN)

 def read(name, limit):
 fd = ops.open(name, os.O_RDONLY, dir_fd=directory)
 with ops.fdopen(fd, "rb") as source:
 data = source.read(limit + 1)
 if len(data) > limit:
 raise ValueError(f"{name} exceeds the snapshot limit")
 return data

 def identity():
 head, tail = read("stat", 65536).rsplit(b")", 1)
 if int(head.split(b" ", 1)[0]) != pid:
 raise ValueError("stat PID mismatch")
 fields = tail.split() # field 3 is index 0; field 22 is index 19
 if fields[0] in (b"Z", b"X", b"x"):
 raise ProcessLookupError("process has exited")
 return int(fields[19])

 before = identity()
 executable = ops.readlink("exe", dir_fd=directory)
 raw_command = read("cmdline", 65536)
 # Remove one final NUL; empty input means no argument data.
 command = raw_command[:-1] if raw_command.endswith(b"\0") else raw_command
 command = command.split(b"\0") if raw_command else []
 after = identity()
 if before != after or watcher.poll(0):
 raise ProcessLookupError("identity changed or process exited")
 return {"pid": pid, "starttime_ticks": before, "executable": executable,
 "argv": [arg.decode("utf-8", "backslashreplace") for arg in command]}
 finally:
 if directory is not None:
 ops.close(directory)
 ops.close(pidfd)


if __name__ == "__main__":
 try:
 if len(sys.argv) != 2:
 raise ValueError("usage: inspect_io_process.py PID")
 print(json.dumps(snapshot(sys.argv[1]), ensure_ascii=True))
 except (OSError, ValueError, IndexError, AttributeError) as error:
 sys.exit(f"Identity snapshot failed: {error}")

python3 inspect_io_process.py "${PID:?Set PID from the reviewed process row}"

成功快照报告可执行文件、参数与前后相同的启动时间值，同时通过 pidfd 检查进程退出。获取句柄之前 PID 仍可能已经复用，因此不能证明早先采样行属于当前进程。proc 字段可以变化，也不是原子快照；任何后续动作前都需重新检查。这里没有终止进程或改变优先级，整个真实工具流程仍未运行。

来源

iotop 手册，iotop-c 手册渲染版；需核对安装的变体，已核验 2026-10-18。
vmstat 手册，说明系统级 CPU 与 IO 等待报告，已核验 2026-09-05。
Linux delay accounting，taskstats 延迟范围与启用前提，已核验 2026-10-18。
Linux proc filesystem，存储字节记账、取消写入与 CPU iowait 限制，已核验 2026-10-18。
iostat manual，首份报告、await 与并行设备利用率的限制，已核验 2026-10-18。
iotop-c upstream manual，进程汇总、批量选项、配置与交互排序，已核验 2026-10-19。
sysstat upstream iostat manual，-y 略过开机统计，-t 标记间隔报告时间，已核验 2026-10-19。
pidfd_open manual，身份或受控操作的适用契约，已核验 2026-10-19。
Python os interfaces，身份或受控操作的适用契约，已核验 2026-10-19。
proc_pid_stat manual，身份或受控操作的适用契约，已核验 2026-10-19。

网络命名空间隔离网络资源，名称并不拥有其中所有进程

Sat, 19 Feb 2028 00:00:00 +0000

Linux 网络命名空间分离接口、路由、邻居表、套接字端口和包过滤规则等网络资源。它与其他命名空间共享内核，不是独立操作系统。进程通常继承父进程的网络命名空间，工具也可以在另一个范围中执行进程。这种隔离针对网络资源，不会自动涵盖全部进程身份和文件系统访问，因此需要按实际机制说明边界。

坏掉的样子

运行 ip netns exec 不会自动获得完整容器隔离。PID、用户身份和主机名隔离属于其他机制。应用可能看到不同路由，却仍与父环境共享普通文件和主机名。如果把一个网络命名空间当成完整沙箱，就会赋予它从未配置过的保证。应区分实际改变了哪类资源，以及哪些属性仍然来自原有运行环境。

新命名空间也不会自动得到有用的外部连接。接口需要有意放置和配置，本地回环可能需要启用。移动接口会改变管理它的命名空间，原范围不再把该设备列为自己的接口。因此，从错误范围执行配置命令，可能报告接口不存在，尽管预期设备仍位于另一个命名空间。诊断前应先确认命令的执行上下文。

名称还有独立生命周期。ip netns 按约定在 /run/netns 暴露引用，通常也能通过 /var/run/netns 访问。删除名称会移除这项引用，但进程或其他引用仍可维持命名空间存活。如果清理流程把名称列表中消失，直接等同于所有服务终止，就可能留下网络资源和运行中的进程。名称只是管理入口，不是进程所有权的完整表达。

网络范围不同，而选定上下文仍共享。删除名称后，自有进程引用仍可存活；当前运行仍待验证。

快速验证

文中结果属于历史文章报告；保留验证文件中未找到原始集成日志，本轮没有重新执行特权操作。

将脚本保存为 check-network-namespace.py，只在获准的一次性虚拟机中准备 Docker，并启用 Python 断言运行 python3 check-network-namespace.py。固定的 Python 3.11.16 与 iproute2 6.1.0 软件包仍需可取得。NET_ADMIN 与 SYS_ADMIN 是前提，不保证越过其他安全限制；不要削弱宿主保护。临时 proc 挂载支持其中的网络参数设置，不移动宿主接口，也不发布宿主端口：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid
recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends iproute2=6.1.0-3 iputils-ping=3:20221126-1+deb12u1 nftables=1.0.6-2+deb12u2 tcpdump=4.99.3-1 traceroute=1:2.1.2-1 procps=2:4.0.2-3 && rm -rf /var/lib/apt/lists/*\nCMD ["python3"]\n'
program=r"""
from contextlib import ExitStack,contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import json,os,select,signal,subprocess,time

def run(*args,check=True,input=None,timeout=8):
 result=subprocess.run(args,input=input,capture_output=True,text=True,timeout=timeout)
 if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr)
 return result
def ns(name,*args,**kwargs):return run('ip','netns','exec',name,*args,**kwargs)
def ip(name,*args,**kwargs):return ns(name,'ip',*args,**kwargs)
def stop(process):
 if process.poll() is None:
 process.terminate()
 try:process.wait(timeout=2)
 except subprocess.TimeoutExpired:process.kill();process.wait(timeout=2)
def line(process,timeout=3):
 assert select.select([process.stdout],[],[],timeout)[0],'child response deadline exceeded'
 value=process.stdout.readline();assert value,'child exited without a response'
 return value
def spawn(stack,command):
 process=subprocess.Popen(command,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True)
 stack.callback(stop,process);return process
@contextmanager
def lab(names):
 with TemporaryDirectory(prefix='net-path-') as directory,ExitStack() as stack:
 root=Path(directory);proc=root/'proc';proc.mkdir();run('mount','-t','proc','proc',str(proc))
 stack.callback(run,'umount',str(proc))
 for name in names:
 run('ip','netns','add',name);stack.callback(run,'ip','netns','delete',name,check=False)
 ip(name,'link','set','lo','up')
 def setting(name,key,value):
 assert name in names
 path=proc/'sys'/key.replace('.','/')
 return ns(name,'python3','-c',f'from pathlib import Path; p=Path({str(path)!r}); p.write_text({str(value)!r}); print(p.read_text().strip())').stdout.strip()
 yield root,stack,setting
def wire(left,left_if,right,right_if,left_addresses,right_addresses):
 run('ip','link','add',left_if,'type','veth','peer','name',right_if)
 for name,interface,addresses in [(left,left_if,left_addresses),(right,right_if,right_addresses)]:
 run('ip','link','set',interface,'netns',name)
 for address in addresses:ip(name,'address','add',address,'dev',interface,*(['nodad'] if ':' in address else []))
 ip(name,'link','set',interface,'up')
def nft(name,script):return ns(name,'nft','-f','-',input=script)
def counters(name):
 data=json.loads(ns(name,'nft','-j','list','ruleset').stdout);found={}
 for entry in data['nftables']:
 rule=entry.get('rule',{})
 if 'comment' in rule:
 for expression in rule['expr']:
 if 'counter' in expression:found[rule['comment']]=expression['counter']['packets']
 return found

def server(stack,name,address,port=18080,label='server'):
 code=r'''
from http.server import BaseHTTPRequestHandler,ThreadingHTTPServer
import json,socket,sys
address,port,label=sys.argv[1],int(sys.argv[2]),sys.argv[3]
class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 body=json.dumps({'server':label,'peer':self.client_address,'path':self.path}).encode()
 self.send_response(200);self.send_header('Content-Length',str(len(body)));self.end_headers();self.wfile.write(body)
 def log_message(self,*args):pass
class Server(ThreadingHTTPServer):
 address_family=socket.AF_INET6 if ':' in address else socket.AF_INET
 def server_bind(self):
 if self.address_family==socket.AF_INET6:self.socket.setsockopt(socket.IPPROTO_IPV6,socket.IPV6_V6ONLY,1)
 super().server_bind()
service=Server((address,port),Handler);print('ready',flush=True);service.serve_forever()
'''
 process=spawn(stack,['ip','netns','exec',name,'python3','-u','-c',code,address,str(port),label])
 assert line(process).strip()=='ready';return process
def request(name,address,port=18080):
 code=r'''
import http.client,json,sys
client=http.client.HTTPConnection(sys.argv[1],int(sys.argv[2]),timeout=.7)
try:
 client.request('GET','/lab-visible-message');response=client.getresponse();body=json.loads(response.read())
 assert response.status==200;print(json.dumps({'ok':True,'status':response.status,'body':body}))
except OSError as error:print(json.dumps({'ok':False,'type':type(error).__name__,'errno':error.errno}))
finally:client.close()
'''
 return json.loads(ns(name,'python3','-c',code,address,str(port)).stdout)

with lab(['blue','green']) as (root,stack,setting):
 probe='import json,os,socket;print(json.dumps({"net":os.readlink("/proc/self/ns/net"),"pid":os.readlink("/proc/self/ns/pid"),"hostname":socket.gethostname()}))'
 parent=json.loads(run('python3','-c',probe).stdout)
 views={name:json.loads(ns(name,'python3','-c',probe).stdout) for name in ['blue','green']}
 assert len({parent['net'],views['blue']['net'],views['green']['net']})==3
 assert all(v['pid']==parent['pid'] and v['hostname']==parent['hostname'] for v in views.values())
 for name in ['blue','green']:
 ip(name,'link','add','dummy0','type','dummy');ip(name,'addr','add','192.0.2.10/24','dev','dummy0');ip(name,'link','set','dummy0','up')
 ip('blue','route','add','203.0.113.0/24','dev','dummy0')
 assert json.loads(ip('blue','-j','route','show','203.0.113.0/24').stdout)
 assert not json.loads(ip('green','-j','route','show','203.0.113.0/24').stdout)
 setting('blue','net.ipv4.ip_forward',0);setting('green','net.ipv4.ip_forward',1)
 forwarding={name:ns(name,'sysctl','-n','net.ipv4.ip_forward').stdout.strip() for name in ['blue','green']};assert forwarding=={'blue':'0','green':'1'}
 marker=root/'shared.txt';marker.write_text('shared filesystem')
 assert ns('blue','cat',str(marker)).stdout==ns('green','cat',str(marker)).stdout=='shared filesystem'
 daemon=server(stack,'blue','192.0.2.10',label='blue')
 named=request('blue','192.0.2.10');assert named['ok'] and named['body']['server']=='blue'
 run('ip','netns','delete','blue');assert not Path('/run/netns/blue').exists()
 assert daemon.poll() is None and os.readlink(f'/proc/{daemon.pid}/ns/net')==views['blue']['net']
 by_pid=run('nsenter','-t',str(daemon.pid),'-n','python3','-c',
 'import http.client,json; c=http.client.HTTPConnection("192.0.2.10",18080,timeout=1);c.request("GET","/");r=c.getresponse();print(json.dumps({"status":r.status,"body":json.loads(r.read())}));c.close()')
 surviving=json.loads(by_pid.stdout);assert surviving['status']==200 and surviving['body']['server']=='blue'
 print(json.dumps({'parent':parent,'namespace_views':views,'blue_only_route':True,'forwarding':forwarding,
 'same_file_visible':True,'before_name_deleted':named,'name_deleted_process_alive':True,'after_name_deleted':surviving}))
"""
name='xbcatm-netpath-'+uuid.uuid4().hex[:10]
def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs)
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'Dockerfile').write_text(recipe)
 build=docker('build','-t',name,str(root));assert build.returncode==0,build.stderr
 result=docker('run','--rm','-i','--name',name,'--network','none','--cap-add','NET_ADMIN','--cap-add','SYS_ADMIN',
 '--memory','256m','--pids-limit','128',name,'python3','-',input=program)
 assert result.returncode==0,result.stderr
 print(json.dumps(json.loads(result.stdout),sort_keys=True))
finally:
 docker('rm','-f',name);docker('image','rm',name)

父环境、blue 和 green 报告三个不同网络命名空间标识，但 PID 命名空间标识与主机名保持相同。父进程创建的标记文件，也能被两个子范围读取。这些正向观察明确了本例边界：网络范围改变了，而所检查的这些进程和文件系统属性仍然共享。不能由网络标识不同，推导其他所有隔离也已经建立。

两个子范围各自创建 dummy0，都使用 192.0.2.10/24。相同名称和地址能够共存，因为它们属于不同网络上下文。只有 blue 增加到 203.0.113.0/24 的路由，查询 green 确认没有对应条目。实验检查生效的独立路由表，不是只打印两个名称就宣布隔离成功，也没有要求地址文本必须跨所有命名空间唯一。

程序明确把 blue 的 IPv4 转发设为零、green 设为一，再分别读取确认。这验证参数作用范围，没有演示真实报文转发。dummy 接口没有物理对端，配置地址和路由也不表示能够访问外部服务。应保留“参数已经不同”和“某条通信路径实际可用”之间的区别，避免把管理状态当成应用交付结果。

真实 HTTP 服务器在 blue 的 192.0.2.10 启动。通过命名空间名称执行客户端，得到状态二百和身份 blue。脚本随后删除 blue 名称，确认引用路径消失，但服务器进程和它的网络命名空间标识仍存在。移除命名引用没有杀死进程，也没有令监听立即消失，这是清理和故障恢复中很重要的生命周期差异。

利用这个明确属于实验的服务器 PID，nsenter 在仍存活的网络命名空间执行另一个客户端，再次得到状态二百与身份 blue。这证明删除名称后应用仍在工作，而不只是 proc 中还有一个条目。最后，清理栈尝试停止自己启动的进程并移除其他命名资源；中断可能留下未完成清理，不能仅凭清理代码存在就保证资源已经收回。

分开管理名称、进程归属与通信配置

记录服务的进程归属，以及运维命令实际使用的网络范围。命名空间标识适合比较当前活跃上下文，不应把短暂标识当作永久资产身份。名称意外消失时，先检查相关自有进程，再判断网络状态是否已经释放。不能仅凭列表为空，就假定可以在没有旧状态和旧服务的前提下创建替代环境。

对普通配置文件，ip netns exec 可以创建挂载命名空间，将按网络名称准备的文件绑定到惯常位置，例如使用独立解析器配置。这不等于复制了全部私有文件系统。重现客户端环境时，应记录这些额外选择，避免混淆 DNS 配置差异与路由隔离。某个共享标记文件可见，也不代表所有配置路径都必然使用相同视图。

需要通信时，应明确建立虚拟链路、路由、转发和过滤。网络命名空间提供资源边界，真正配置决定哪些数据能够通过。拆除时，应先停止服务拥有的进程并释放相关引用，再期待范围完全消失。删除名称是生命周期中的一项管理动作，不是通用的进程终止命令，也不能代替对残留服务和资源的实际检查。

来源

Linux network_namespaces(7)，网络命名空间隔离的资源，已核验 2026-09-12。
Linux ip-netns(8)，名称引用、命令执行及进程存活时的删除语义，已核验 2026-09-12。
Linux ip-link(8)，接口创建与命名空间归属，已核验 2026-09-12。

strace 解释选定的系统调用边界

Mon, 14 Feb 2028 00:00:00 +0000

strace 在选定 Linux 进程与内核之间的边界上观察系统调用和信号，不需要重新构建程序，就能展示尝试访问的路径、参数、返回值和错误。应用日志漏掉操作时，这些证据很有帮助；但它不会暴露每个用户态决定，也不会自动指出哪次失败调用导致最终结果。正确诊断仍需把边界行为与程序控制流程联系起来。

这里展示原文样例的两组受控结果，并非新采集的追踪。同一错误在不同控制流程中意义不同。图中仅展示选定进程与系统调用边界，不代表全部应用工作或完整因果链。当前审核仍为已修订、执行受阻；本次未尝试追踪。

坏掉的样子

父进程可能启动子进程执行真正工作。只追踪父进程，会看到等待和退出，却漏掉子进程中的文件打开失败。使用 -f 跟随新建进程可以扩大范围，但不会自动追踪所有既有兄弟进程或请求涉及的外部服务。被选中的进程集合，本身就是证据范围的一部分，不能只看到主命令被追踪就认定全部参与者都在视野内。

错误返回不一定是根因。程序经常尝试可选文件、搜索多个位置，并从预期失败中恢复。找到第一条 ENOENT，或者退出前最后一次不成功调用，都不能替代理解应用控制流程。真正需要回答的是，这个返回值如何影响正在调查的操作。相同错误名在不同分支里，可能分别代表正常探测和不可继续的条件。

过滤与计时也会改变解释。把输出限制为文件打开，就有意排除了网络及其他活动。追踪还可能改变调度和延迟，尤其影响系统调用频繁的工作负载，没有通用固定降速倍数。过滤后的记录看起来正常，不能证明被排除操作成功，也不能证明没有追踪器时会出现完全相同的竞争时序。

快速验证

本轮复核没有重复追踪集成。所述结果来自此前环境，不证明每个容器都允许 ptrace。

把脚本保存为 straceprobe.py，在安装 strace 的一次性 Linux 环境中运行 python3 straceprobe.py。实测使用 Linux 6.12.76、Python 3.11.2 和 strace 6.1。样本启动自己的无害程序，使用临时配置路径，并要求环境允许追踪新启动子进程：

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

child=r'''
from pathlib import Path
import sys
try:Path(sys.argv[1]).read_bytes()
except FileNotFoundError:pass
try:content=Path(sys.argv[2]).read_bytes()
except FileNotFoundError:sys.exit(7)
assert content==b'configured'
'''
parent='import subprocess,sys\nchild='+repr(child)+'\nsys.exit(subprocess.run([sys.executable,"-c",child,*sys.argv[1:]]).returncode)'
with TemporaryDirectory(prefix='xbcatm-strace-') as directory:
 root=Path(directory);optional=root/'optional.conf';required=root/'required.conf'
 command=[sys.executable,'-c',parent,str(optional),str(required)]
 def trace(name,follow):
 output=root/(name+'.trace')
 args=['strace']+(['-f'] if follow else [])+['-tt','-T','-yy','-s','200','-e','trace=openat,close','-o',str(output),'--',*command]
 result=subprocess.run(args,capture_output=True,text=True,timeout=10)
 return result.returncode,output.read_text(),result.stderr
 code,unfollowed,error=trace('parent-only',False)
 assert code==7 and str(required) not in unfollowed,(code,error)
 code,followed,error=trace('with-children',True)
 assert code==7,(code,error)
 def calls(text,path):return [line for line in text.splitlines() if 'openat(' in line and '"'+str(path)+'"' in line]
 for path in [optional,required]:
 lines=calls(followed,path);assert len(lines)==1 and 'ENOENT' in lines[0],lines
 print('failing run:',lines[0])
 print('without -f the parent trace misses the child opens; following the child exposes both missing paths')
 required.write_bytes(b'configured')
 code,recovered,error=trace('recovered',True);assert code==0,(code,error)
 assert 'ENOENT' in calls(recovered,optional)[0]
 assert ' = -1 ' not in calls(recovered,required)[0]
 print('successful run:',calls(recovered,optional)[0])
 print('successful run:',calls(recovered,required)[0])
 print('a successful application can contain ENOENT; the fixture distinguishes optional lookup from required configuration')
 summary=root/'summary'
 result=subprocess.run(['strace','-f','-c','-e','trace=openat','-o',str(summary),'--',*command],capture_output=True,text=True,timeout=10)
 assert result.returncode==0,result.stderr
 text=summary.read_text();assert 'openat' in text and 'total' in text
 print('syscall summary:\n'+text)

应用子进程先尝试可选配置文件，允许它不存在；随后读取第二份必需配置，缺失时以状态七退出。父进程返回子进程状态。这构成一份完整失败案例，原因可以直接从样本代码查明，不依赖工作区中根本不存在的占位应用。判断追踪结果时，已知控制流程提供了可以比较的依据。

第一次追踪不启用 -f。命令返回七，但父进程的打开记录没有必需路径。启用跟随后重跑，能看到子进程对可选和必需路径的打开，两者都返回 ENOENT。这个对照证明，即使命令整体失败已经可见，错误选择进程范围仍会隐藏关键操作，不能据父进程记录缺少某路径就断言没有访问尝试。

随后只创建必需文件，并写入正确内容。下一轮返回零，必需路径打开成功，可选查询却仍然返回 ENOENT。这个成功案例刻意反驳“任何错误行都证明应用失败”的判断：两次相同错误在程序逻辑里承担不同角色。修复后保留的正常失败，比单独列出错误日志更能说明真正的恢复条件。

追踪包含 -tt 时间戳、-T 调用经过时间和 -yy 描述符上下文；有限字符串长度足以显示受控路径，-o 则把追踪输出与应用输出分开。脚本断言真实返回码和目标打开结果，没有仅凭追踪文件存在就视为验证完成。记录生成、预期行为出现与最终任务成功，是需要分别检查的结果。

最后使用 -c 汇总恢复后应用的选定 openat 调用和错误，计数也包含运行时启动工作。因此总数不是业务请求数量，默认汇总计时也不能等同应用完整墙钟时间。精确次数和时长会随运行时及环境变化。理解样本时应关注必需路径恢复与返回状态的关系，而不是把本次汇总数字当成所有环境的固定常量。

沿假设追踪到真实结果

应从具体操作出发，确定哪些进程执行它，再选择能够保留所需证据的过滤条件。文件、网络和进程追踪回答不同问题；依赖位于当前视野之外时，再扩大选择范围，同时保持工作负载足够小，便于解释。记录越多并不自动越有价值，关键在于证据能否支持或否定当前假设。

使用 -p 附加时，需要核对进程身份和追踪权限。即使 PID 存在，凭据、安全策略、命名空间关系或容器配置，也可能拒绝访问。本样本在没有额外容器能力的情况下追踪新建子进程，不代表已经证明可以附加其他系统上的任意既有服务。环境许可与工具参数正确，是不同的前提。

捕获的参数和数据应适合当前调查。追踪可能包含路径、请求内容或凭据，因此应使用受控输入，并限制保留材料。把追踪与应用行为对应起来，复现拟议修复，再检查最终结果。本例中可选错误仍存在而应用恢复成功，正好提供了这种因果对照，避免把日志里最醒目的一行误当成结论。

来源

strace(1)，跟随过滤选项、返回值、计时、汇总与解码，已核验 2026-09-12。
ptrace(2)，追踪关系、停止点与访问限制，已核验 2026-09-12。

Cron 系统任务表与用户任务表有不同契约

Wed, 12 Jan 2028 00:00:00 +0000

Cron 可以从不止一种任务表读取计划。用户任务表属于某个账号，而系统任务表能够为每一条记录指定运行账号。把一行原样复制到另一种表中，如果没有调整字段，cron 对命令起点的理解就会变化。排查看似正确的五字段日历表达式之前，应先确认正在编辑的到底是哪种任务表，而不是只检查分钟和小时。

Debian 用户表在五个字段后开始命令，系统表则先增加用户名。未转义百分号先于 shell 引号处理，并分离标准输入。本图为示意图；没有执行需要特权的示例。

账号列改变了解析边界

传统用户记录依次填写分钟、小时、月内日期、月份、星期，再接命令正文，由 crontab 命令安装给选定用户。Debian 的 /etc/crontab 和 /etc/cron.d 下文件，则在五个日历字段之后额外增加用户名。这个用户名属于系统表格式，并不是可以随意放进用户任务表的说明性字段；多写或少写都会改变后续解释。

月份限制仍然必须满足。当月内日期与星期都受到限制时，Debian/Vixie 的日期规则允许满足其中之一，但月份与星期并不是二选一。把表达式迁移到带秒字段或采用其他日期组合方式的调度产品前，应核对具体方言。表面上相似的空格布局，不能证明两个调度器提供相同语义。

系统任务文件还受所有权、权限、名称及末尾换行要求约束。Debian 中应采用 root 所有、组和其他用户不可写且名称被接受的文件，不要把任意备份后缀当成有效任务名。/etc/cron.daily 等周期目录通常通过发行版安排和 run-parts 被调用，不是每份脚本都独立当作 crontab 解析。实际运行时间需要查看本机已安装的调度安排。

坏掉的样子

在 root 用户自己的任务表中，五字段后再写 root，意味着让 shell 执行一个名为 root 的命令。任务表安装成功，不证明这个命令存在。反过来，系统表漏掉账号列，就会把命令文字当成用户名。审阅时需要同时检查解析边界与最终身份，尤其是任务会写文件或读取受保护数据时，不能仅凭“都是 root 配置的”推断执行账号。

任务环境同样是一份契约。不要默认交互别名、shell 启动文件或启动 cron 的父进程环境都会传给任务。需要的值应明确配置，同时选择合适的 PATH 和解释器。cron.d 文件中的环境也不应被认为自动继承 /etc/crontab 中的设置。验证时要采用真正的运行账号检查权限与输出，避免管理员手工执行成功掩盖低权限任务失败。

百分号在完整命令交给 shell 之前就有特殊含义。未转义的百分号会划分标准输入，后续百分号再变成换行。仅用 shell 引号包围内容，并不能取消 cron 的这一步解释。复杂逻辑适合放进脚本；确实需要把字面百分号写在表中时，应按 cron 规则转义。调度语法、命令能否执行和应用结果是否成功，必须分别检查。

快速验证

2026-10-19 修复草案：此版本只进行了静态检查与离线命令／文件状态替身测试，没有执行守护进程、账号或任务表变更。技术与实际运行验证仍然受阻。下文版本限定的结果属于原始示例。

未来运行需要另行授权的新建一次性 Debian 12 环境，预装 Python 3.11+、cron 3.0pl1-162、procps 与 passwd，并允许执行 /tmp 中的包装 shell 脚本；不得挂载宿主目录，不得已有 cron 进程、root 任务表、xbtime 账号或实验任务文件，/etc/crontab、/etc/cron.d 与任何用户任务表也不得启用其他计划（包括周期目录的派发），并且不得有并发管理操作。保存为 cron-tables.py，只有独立核实这些条件后才能使用 python3 cron-tables.py --isolated-disposable-lab。该参数和 root 身份都不能证明隔离。脚本仍会修改实验环境范围的账号文件和 cron 状态，结束后必须丢弃整个环境。

临时系统账号使用既有 nogroup，并把既有私有工作目录作为主目录，不新建主目录或私有组，也不初始化 lastlog；实际读取其 UID，不再假定为一千。从首次尝试修改起，账号创建、查询、任务表安装与进程启动都处于清理范围内。两份实验任务表都用 MAILTO 禁用邮件；准确的固定版本“不存在”诊断与权限或命令失败分开处理。工作进程通过同目录替换发布完整 JSON，故意错误的条目仍在五个字段后直接写 root。仅该条目选择一个简短的 SHELL 包装脚本：持共享锁核对许可，使锁描述符跨 exec 保留，再将原始命令交给 /bin/sh；诊断通过改名发布。正向运行许可与共享生命周期锁用于约束已获准工作的清理。每项清理独立尝试，进程和工作等待都有期限；错误会保留原始失败并跳过私有文件删除，但删除失败也可能只留下部分文件。撤销许可可避免延迟工作把停止文件消失误当成允许运行。屏障不能证明每个 cron 包装进程都已退出，因此仍须丢弃整个环境。

from pathlib import Path
from tempfile import mkdtemp
import fcntl
import json
import os
import pwd
import shutil
import subprocess
import sys
import time


def command(arguments, **options):
 return subprocess.run(arguments, capture_output=True, text=True, timeout=5,
 env={**os.environ, 'LC_ALL': 'C'}, **options)


def table_absent(result):
 # Debian cron 3.0pl1-162: other listing failures must abort.
 return (result.returncode == 1 and result.stdout == ''
 and result.stderr == 'no crontab for root\n')


def remove_table():
 current = command(['crontab', '-l'])
 if table_absent(current):
 return
 current.check_returncode()
 command(['crontab', '-r']).check_returncode()
 if not table_absent(command(['crontab', '-l'])):
 raise RuntimeError('could not verify table removal')


def attempt(errors, name, operation):
 try:
 operation()
 except Exception as error:
 errors.append(f'{name}: {error!r}')


def stop_daemon(daemon, errors):
 if daemon is None:
 return
 attempt(errors, 'terminate cron', daemon.terminate)
 try:
 daemon.wait(timeout=5)
 except subprocess.TimeoutExpired:
 attempt(errors, 'kill owned cron', daemon.kill)
 attempt(errors, 'reap cron', lambda: daemon.wait(timeout=5))
 except Exception as error:
 errors.append(f'wait cron: {error!r}')


def remove_account(username):
 try:
 pwd.getpwnam(username)
 except KeyError:
 return
 command(['userdel', username]).check_returncode()
 try:
 pwd.getpwnam(username)
 except KeyError:
 return
 raise RuntimeError('account removal not verified')


def wait_workers(root):
 with (root / 'lifetime.lock').open() as gate:
 deadline = time.monotonic() + 5
 while True:
 try:
 fcntl.flock(gate, fcntl.LOCK_EX | fcntl.LOCK_NB)
 return
 except BlockingIOError:
 if time.monotonic() >= deadline:
 raise TimeoutError('workers did not release lifetime lock')
 time.sleep(0.1)


worker_source = r'''from pathlib import Path
import fcntl,json,os,sys
root=Path(__file__).parent
mode=sys.argv[1]
with (root/'lifetime.lock').open() as gate:
 fcntl.flock(gate,fcntl.LOCK_SH)
 if not (root/'run-permit').exists(): raise SystemExit(0)
 data={'uid':os.getuid(),'table':os.environ.get('LAB_TABLE'),
 'path':os.environ.get('PATH'),'shell':os.environ.get('SHELL'),
 'parent_only':os.environ.get('PARENT_ONLY')}
 if mode=='percent': data['stdin']=sys.stdin.read()
 destination=root/(mode+'.json')
 temporary=root/f'{mode}-{os.getpid()}.tmp'
 temporary.write_text(json.dumps(data))
 temporary.replace(destination)
'''


shell_source = r'''#!/usr/bin/python3
from pathlib import Path
import fcntl,os,sys
root=Path(__file__).parent
with (root/'lifetime.lock').open() as gate:
 fcntl.flock(gate,fcntl.LOCK_SH)
 if not (root/'run-permit').exists(): raise SystemExit(0)
 os.set_inheritable(gate.fileno(),True)
 os.execv('/bin/sh',['/bin/sh',*sys.argv[1:]])
'''


def main():
 if sys.argv[1:] != ['--isolated-disposable-lab']:
 raise SystemExit('requires a separately verified disposable Debian 12 lab')
 if os.geteuid() != 0:
 raise RuntimeError('root is required, but does not prove isolation')
 probe = command(['pgrep', '-x', 'cron'])
 if probe.returncode != 1 or probe.stdout or probe.stderr:
 raise RuntimeError(f'cron absence not established: {probe!r}')
 if not table_absent(command(['crontab', '-l'])):
 raise RuntimeError('expected absent root table; existing table or listing error')
 if shutil.which('root', path='/usr/bin:/bin') is not None:
 raise RuntimeError('the deliberately invalid command exists')
 username = 'xbtime'
 try:
 pwd.getpwnam(username)
 except KeyError:
 pass
 else:
 raise RuntimeError('test account already exists')
 system_table = Path('/etc/cron.d/xbcatm_time_test')
 if system_table.exists() or system_table.is_symlink():
 raise RuntimeError('system test table already exists')
 root = Path(mkdtemp(prefix='cron-tables-', dir='/tmp'))
 daemon = None
 account_attempted = account_created = table_attempted = system_owned = False
 try:
 (root / 'lifetime.lock').touch(mode=0o644)
 (root / 'run-permit').touch()
 account_attempted = True
 command(['useradd', '--system', '--no-create-home', '--no-user-group',
 '--gid', 'nogroup', '--home-dir', str(root), '--no-log-init', '--shell', '/bin/sh', username]).check_returncode()
 account_created = True
 account = pwd.getpwnam(username)
 os.chown(root, account.pw_uid, account.pw_gid)
 worker = root / 'worker.py'
 worker.write_text(worker_source)
 # The account must read both files even under a restrictive parent umask.
 worker.chmod(0o644)
 guarded_shell = root / 'guarded-shell'
 guarded_shell.write_text(shell_source)
 guarded_shell.chmod(0o755)
 (root / 'lifetime.lock').chmod(0o644)
 user_table = ('SHELL=/bin/sh\nPATH=/usr/bin:/bin\nLC_ALL=C\nMAILTO=""\nLAB_TABLE=user\n'
 f'* * * * * /usr/bin/python3 {worker} user\n'
 f'* * * * * /usr/bin/python3 {worker} percent%first%second\n'
 f'SHELL={guarded_shell}\n'
 f'* * * * * root /usr/bin/id >{root}/wrong-column.tmp 2>&1; '
 f'/bin/mv {root}/wrong-column.tmp {root}/wrong-column.err\n')
 table_attempted = True
 command(['crontab', '-'], input=user_table).check_returncode()
 invalid = command(['crontab', '-'], input='* * * * * /bin/true')
 assert invalid.returncode != 0
 listed = command(['crontab', '-l'])
 listed.check_returncode()
 assert listed.stdout == user_table
 with system_table.open('x') as handle:
 system_owned = True
 handle.write('SHELL=/bin/sh\nPATH=/usr/bin:/bin\nLC_ALL=C\nMAILTO=""\nLAB_TABLE=system\n'
 f'* * * * * {username} /usr/bin/python3 {worker} system\n')
 system_table.chmod(0o644)
 daemon = subprocess.Popen(['cron', '-f'], env={**os.environ, 'PARENT_ONLY': 'parent-demo'},
 stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
 deadline = time.monotonic() + 75
 names = ['user.json', 'system.json', 'percent.json', 'wrong-column.err']
 while time.monotonic() < deadline:
 if daemon.poll() is not None:
 raise RuntimeError('cron exited')
 if all((root / name).exists() for name in names):
 break
 time.sleep(0.2)
 else:
 raise AssertionError('scheduled table outputs were not produced')
 user = json.loads((root / 'user.json').read_text())
 system = json.loads((root / 'system.json').read_text())
 percent = json.loads((root / 'percent.json').read_text())
 wrong = (root / 'wrong-column.err').read_text()
 assert user['uid'] == 0 and user['table'] == 'user'
 assert system['uid'] == account.pw_uid and system['table'] == 'system'
 assert all(value['parent_only'] is None for value in (user, system))
 assert all(value['path'] == '/usr/bin:/bin' for value in (user, system))
 assert all(value['shell'] == '/bin/sh' for value in (user, system))
 assert percent['stdin'] == 'first\nsecond\n'
 assert 'root: not found' in wrong
 print(json.dumps({'user_table': user, 'system_table': system,
 'missing_final_newline_rejected': invalid.returncode,
 'previous_table_preserved': True, 'percent_stdin': percent['stdin'],
 'username_in_user_table_fails': wrong.strip()}), flush=True)
 finally:
 original = sys.exc_info()[1]
 errors = []
 attempt(errors, 'revoke run permit', lambda: (root / 'run-permit').unlink(missing_ok=True))
 if system_owned:
 attempt(errors, 'remove system table', lambda: system_table.unlink(missing_ok=True))
 if table_attempted:
 attempt(errors, 'remove root table', remove_table)
 stop_daemon(daemon, errors)
 attempt(errors, 'wait for workers', lambda: wait_workers(root))
 if account_attempted:
 attempt(errors, 'remove account', lambda: remove_account(username))
 if not account_created:
 errors.append('account creation failed partway; database state needs lab disposal')
 if not errors:
 attempt(errors, 'remove private files', lambda: shutil.rmtree(root))
 if errors:
 message = 'cleanup incomplete; discard lab: ' + '; '.join(errors)
 if original is not None:
 original.add_note(message)
 else:
 raise RuntimeError(message)


if __name__ == '__main__':
 main()

原始历史运行中，用户表任务以 UID 零执行，系统表任务使用当时分配 UID 一千的新建账号。本次修订改为创建系统账号，并核对实际查询到的 UID。两者分别得到自己的 LAB_TABLE 值和明确配置的 PATH，都没有继承启动守护进程的父环境变量 PARENT_ONLY。包含百分号的记录把 first\nsecond\n 传入标准输入。错误加入用户名的用户记录则输出 root: not found，即使它所在的任务表此前已经成功安装。

程序还尝试用没有末尾换行的新内容替换任务表，该操作以退出码一被拒绝，原表保持不变。原始示例曾报告全部断言在 cron 3.0pl1-162 上通过；修订版本尚无真实守护进程结果。额外探测发现，这个软件包即使使用检查选项，也接受了错误的分钟文字，因此这里不会从退出码零推导出所有字段都已经有效；记录的是版本限定的实际观察，而不是猜测其他版本必然相同。

实验验证账号、环境、百分号解析及安装失败后的保留行为，没有测试邮件投递、夏令时处理或实际业务成功。部署真正任务时，应把这些额外要求继续列为可验证条件，并检查最终运行结果，不能以文件存在或安装命令成功替代完成证据。

来源

Debian 12: crontab(5)，用户与系统任务表格式、环境及百分号处理，已核验 2026-09-13。
Debian 12: cron(8)，系统任务文件、所有权和执行环境，已核验 2026-09-13。
Debian 12: crontab(1)，任务表安装、检查选项和末尾换行要求，已核验 2026-09-13。
Python 3.11 subprocess，超时与子进程清理语义，已核验 2026-10-19。
Debian cron 3.0pl1-162 crontab.c，区分不存在任务表的诊断与其他失败，已核验 2026-10-19。
Python 3.11 os.replace，同文件系统原子发布，已核验 2026-10-19。
Debian cron 3.0pl1-162 do_command.c，所选 shell 接收 -c 与命令，已核验 2026-10-19。
Python 3.11 os，描述符继承与 exec，已核验 2026-10-19。
Linux flock(2)，跨 exec 的锁生命周期，已核验 2026-10-19。
Debian 12 useradd(8)，系统账号、组、主目录与日志初始化选项，已核验 2026-10-19。

Shell 的字段拆分把未加引号的变量拆成多个参数

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

变量保存的是一个字符串，但没有引号的展开可能把它变成多个命令参数。Bash 的分词阶段使用 IFS 指定的分隔字符检查展开结果，因此，手动引用后能正常使用的路径，放入变量再传递时却可能突然找不到文件。排查时首先应观察接收命令实际拿到的参数数量和每个参数的内容，也要区分空字符串与完全没有参数，不能仅凭终端上看起来相同的一行文本判断输入一致。

IFS 控制分词，而引用还能阻止文件名展开。空参数和没有参数仍是不同情况。

是否分词取决于上下文

默认 IFS 包含空格、制表符和换行符，它们的连续组合会分隔字段，开头和结尾的这类空白也会被忽略。未引用变量里有两个单词时，命令通常收到两个参数；变量为空时，则通常连一个参数都没有。使用 "$value" 会保留一个参数，即使值是空字符串。对于命令行接口，显式传入空值和省略选项值可能触发完全不同的行为。

分词针对适用上下文中的未引用参数展开、命令替换和算术展开结果，并不是重新解析整条命令。普通赋值语句 copy=$value 会保留原字符串，不执行分词和文件名展开。但随后把 $copy 不加引号地作为命令参数使用，仍会重新引入两个问题。Bash 双方括号条件表达式也具有不同于普通命令参数的展开规则，所以赋值或条件判断成功，不能证明后面的外部程序调用也安全。

IFS 是一组分隔字符，不是多字符分隔串，也不是正则表达式。非空白分隔符和空白的处理并不相同，例如连续两个冒号可以产生一个空字段，而连续默认空白通常只是一个字段边界。把 IFS 设为空字符串会关闭分词，但不会把未引用的空展开变成显式空参数。若数据格式有引号、转义或嵌套结构，应使用理解该格式的解析器，不能把调整 IFS 当作通用解析方法。

坏掉的样子

关闭分词并没有关闭随后的文件名展开。即使 IFS 为空，变量里的星号仍可能匹配当前目录下的文件；目录里刚增加一个文件，同一条命令的参数数量就会改变。引用变量能够同时阻止这两种转换，而修改 IFS 只处理了其中一个阶段。控制通配符的 shell 选项也独立存在，不能把它们和分词配置混为一谈。

另一个常见问题是用一个字符串保存整组参数，然后往字符串内部塞引号。Bash 不会在变量展开后把这些字符重新当作 shell 源码里的引号，因此它们不能恢复原有参数边界。不要用 eval 补救：它会增加一次 shell 解析，让原本的数据获得执行命令的机会。需要在 Bash 中逐步组装命令时，使用数组保存各项，并通过 "${args[@]}" 传递，每项内容和空值都能独立保留。

有些协议确实规定了分隔符，此时主动分词可以合理使用，但必须先明确格式、空字段含义和有效字符范围，并把 IFS 的修改限制在所需操作范围。任意文件名和带引号的逗号分隔记录都不适合直接按空白切开。本文实验明确使用 Bash；其他 shell 的默认行为可能不同，例如通常配置下的 zsh 不会以相同方式拆分普通标量展开，不能把一个终端的观察直接推广到所有 shell。

例如，变量展开产生的分号不会自动升级为 shell 的命令分隔符。它仍然属于参数数据，尽管周围文本仍可能被分词破坏。参数构造错误与主动把字符串重新解释成代码是两个不同问题，修复时应定位实际发生转换的阶段。

快速验证

下面的完整 Bash 实验直接断言参数数量，不使用会掩盖边界差异的 echo。它自行创建两个匹配文件，检查带空格的值、空值、空 IFS 下的通配符，以及连续冒号生成的空字段。测试目录退出时自动删除，不需要读者准备目录内容。

bash --noprofile --norc <<'BASH'
set -e
set +f
unset GLOBIGNORE
shopt -u nullglob failglob dotglob
work=$(mktemp -d)
trap 'rm -rf -- "$work"' EXIT
cd "$work"
IFS=$' \t\n'
value='report final.md'
set -- $value
[[ $# -eq 2 ]]
set -- "$value"
[[ $# -eq 1 && $1 == 'report final.md' ]]
value=''
set -- $value
[[ $# -eq 0 ]]
set -- "$value"
[[ $# -eq 1 && $1 == '' ]]
touch a.txt 'two words.txt'
IFS=''
pattern='*.txt'
set -- $pattern
[[ $# -eq 2 ]]
set -- "$pattern"
[[ $# -eq 1 && $1 == '*.txt' ]]
IFS=:
record='red::blue'
set -- $record
[[ $# -eq 3 && $2 == '' ]]
printf 'colon field <%s>\n' "$@"
args=('report final.md' '' '*.txt')
set -- "${args[@]}"
[[ $# -eq 3 && $2 == '' && $3 == '*.txt' ]]
printf 'PASS: boundaries, empty values, globbing, delimiters\n'
BASH

预期输出三行冒号字段，中间一行的尖括号内为空，随后输出通过信息。前面的断言还验证了零参数和一个空参数确实不同，以及 IFS 为空时通配仍然执行。如果真实脚本仅在特定文件名下失败，可以在函数或外部命令的调用边界临时加入参数计数，并使用 Bash 的 printf %q 格式逐项显示。这个输出有助于观察换行、空格和字面星号，但调试日志不是可随意重新执行的命令格式，不应再交给 eval 处理。

来源

GNU Bash：分词，IFS 和空字段规则，已核验 2026-09-06。
GNU Bash：Shell 展开，分词先于文件名展开的顺序，已核验 2026-09-06。
GNU Bash：数组，保留参数列表边界，已核验 2026-09-06。

巨型页在分配灵活性与翻译覆盖之间取舍

Tue, 21 Dec 2027 00:00:00 +0000

巨型页可以增加每条地址翻译缓存能够覆盖的内存范围，在合适负载下减少翻译开销。但效果取决于访问模式和硬件，不能仅因为申请了很大一块内存，就断定程序频繁发生 TLB 缺失。描述工作集需要的页数减少，也不表示所有翻译能够同时装入处理器的 TLB；页数算术、硬件容量与真实性能是三个不同问题。

页大小是一项输入

x86 常见基准页为 4 KiB，但 Linux 的页大小依赖架构与配置，应读取运行系统而不是把四千多字节当作普遍常量。支持的巨型页尺寸同样会变化；2 MiB 与 1 GiB 是常见例子，不是所有处理器的完整列表。跨机器比较时，应先确认单位和实际尺寸，再比较统计数字。

对理想化的连续 8 GiB 范围，4 KiB 粒度需要 2,097,152 个页面，2 MiB 粒度只需 4,096 个。这只是映射覆盖率计算，没有测量硬件 TLB 容量、缺失率、页表遍历延迟，或同时驻留的翻译数量。不同页面大小对应的翻译缓存结构还可能具有不同容量，因此不能把两种页数之差直接称为实际节省的 TLB 项。

显式池与透明分配

Hugetlb 提供显式申请的大页，并由内核维护相应池。持久池中的页面不能同时用于普通分配，也不能在内存压力下换出。池可以在启动时准备，也能在运行中调整，还可能允许额外的 surplus 页面。启动较早时通常更容易获得连续内存，但这并不表示大页只能一次性在开机前决定数量，之后永远无法改变。

透明巨型页采用另一套机制。依内核支持和政策，较大的匿名内存分配既可能发生在缺页时，也可能由后续合并产生。THP 不只是后台线程，也不要求管理员先准备 hugetlb 池。现代内核还可以支持多种 THP 尺寸，不能把每次透明分配都等同于一个两兆字节映射，更不能用 hugetlb 总数代替 THP 使用量。

灵活性也不同。THP 可以退回较小页面，并可为回收等操作拆分。显式 hugetlb 映射不会自动变成普通页映射，但应用在自身配置允许时，可以在失败后另行选择普通页分配。应区分内核映射契约与应用的回退策略，否则会把“必须使用大页”的应用和“优先尝试大页”的应用误写成同一种启动行为。

分别预算容量与位置

在 /proc/meminfo 中，HugePages_Total 表示默认尺寸池的页数，HugePages_Free 是尚未分配的页数，HugePages_Rsvd 是已作出承诺但还没有在缺页时分配的页数。总页数乘页大小得到池容量，不是 Rsvd 所表达的已承诺容量。看起来空闲的池中可能已有一部分被预订，不能把 Free 全部当成任何新申请都能使用的余量。Hugetlb 则统计各种尺寸池占用的总内存，细节应查看分尺寸 sysfs 目录。

稀疏映射可能消耗超过有用数据的常驻内存，池也会与普通内存需求竞争。应按应用文档估算容量，核对实际映射，并给其他分配保留空间。收益需要通过代表性吞吐、延迟及翻译相关测量建立，不能因为配置的大页池足够大就宣布优化已经生效；申请、映射、使用与性能改善是不同阶段。

坏掉的样子

扩大池时，内核可能找不到足够连续的物理内存，因而失败。但已经存在的空闲巨型页本来就是连续页，Free 大于零本身并不是碎片证据。页尺寸不匹配、已有预订、权限、NUMA 位置或 cgroup 限制，也可能解释为什么某个应用用不到看似可用的容量。应按具体失败路径调查，而不是看到内存不足就统一建议重启或重复 mmap。

NUMA 政策可能使页面远离使用它们的 CPU，或者只允许从部分节点分配。应检查分节点分布和访问局部性，再判断是否为地址翻译瓶颈。TLB 改善可以与更差的内存访问延迟同时存在；全局空闲数正常、应用能够启动，都不能证明放置策略合适，也不能推导每次访问一定走本地内存。

THP 分配、合并、整理和拆分会以不同方式影响延迟。thp_collapse_alloc 是合并过程中成功分配的计数，不是停顿时间计数。应将合适的计数增量与延迟共同观察。选择 madvise、always 或当前内核支持的分尺寸政策，需要真实负载依据，不能给所有数据库套用同一个模式，再把模式名称当作性能保证。

8 GiB 页数比较属于算术；hugetlb 预留与 THP 行为须分别解释。

快速验证

保存为 hugepage_check.py，运行 python3 hugepage_check.py。程序只读取计数和基准页大小，不创建大页工作负载，也不修改内核设置。缺少数据时明确打印跳过信息，并把假设值标成仅供算术演示。解析与边界断言使用合成字符串，既检查正常输入，也检查单位错误和零页大小，不会把无效数据悄悄解释为真实容量。

import os
import re
from pathlib import Path

WORKING_SET = 8 * 1024**3
FIELDS = ("HugePages_Total", "HugePages_Free", "HugePages_Rsvd",
 "HugePages_Surp", "Hugepagesize")


def parse_meminfo(text):
 values = {}
 for key in FIELDS:
 unit = r"\s+kB" if key == "Hugepagesize" else ""
 match = re.search(r"^" + key + r":\s+(\d+)" + unit + r"\s*$", text, re.M)
 if match:
 values[key] = int(match.group(1))
 return values


def pages_for(size, page):
 if size < 0 or page <= 0:
 raise ValueError("invalid byte count or page size")
 return (size + page - 1) // page


assert pages_for(4097, 4096) == 2
assert parse_meminfo("HugePages_Total: 8\nHugepagesize: 2048 kB\n")["Hugepagesize"] == 2048
assert parse_meminfo("HugePages_Total: bad\nHugepagesize: 2 MB\n") == {}
try:
 pages_for(1, 0)
except ValueError:
 pass
else:
 raise AssertionError("zero page size accepted")

try:
 values = parse_meminfo(Path("/proc/meminfo").read_text())
except OSError as error:
 values = {}
 print("SKIP live hugetlb counters:", type(error).__name__)
try:
 base = os.sysconf("SC_PAGE_SIZE")
 assert base > 0
 print("Observed base page size:", base, "bytes")
except (AttributeError, ValueError, OSError):
 base = 4096
 print("Assumed illustration base page size:", base, "bytes")

if all(key in values for key in FIELDS) and values["Hugepagesize"] > 0:
 huge = values["Hugepagesize"] * 1024
 print("Default-size hugetlb pool counters:", values)
 print("Total pool capacity:", values["HugePages_Total"] * huge, "bytes")
 print("Reserved but not allocated:", values["HugePages_Rsvd"] * huge, "bytes")
else:
 huge = 2 * 1024**2
 print("SKIP complete pool report; assuming 2 MiB for arithmetic only")
print("8 GiB page-count illustration:", pages_for(WORKING_SET, base),
 "base pages versus", pages_for(WORKING_SET, huge), "large pages")
print("No TLB miss rate, THP coverage, allocation success, or latency was measured")

若基准页为 4 KiB、默认大页为 2 MiB，预期看到前述两组页数。池总数为零是一种有效观察，不证明内核不支持大页。修订脚本已在 Linux、Python 3.12.14 下执行通过。它没有测量 THP 覆盖率、真实分配成功率或性能；这些结论需要另外设计与工作负载对应的实验，不能从一份只读容量报告直接推出。

来源

内核巨型页文档，定义 hugetlb 设置与行为，已核验 2026-06-01。
内核透明巨型页文档，定义 THP 模式与后台整理行为，已核验 2026-06-01。
proc_meminfo：大页计数，核对内存承诺、大页计数与单位，已核验 2026-10-15。

Linux overcommit 为虚拟内存承诺设定政策

Sat, 18 Dec 2027 00:00:00 +0000

Linux 的 overcommit 政策控制某些虚拟内存承诺是否可以获准，和分配常驻物理页、选择 OOM 牺牲进程、执行容器内存限制并不是同一件事。一次成功申请可能早于实际物理需求，但这不表示所有分配都没有成本，也不保证后续访问在任何资源约束下都能成功。分析时应把承诺、驻留和故障处理分别记录，而不是都称为“剩余内存”。

虚拟承诺不同于实际驻留

malloc 等分配器可能通过 brk 或 mmap 取得内存，也可能直接复用已有内存区，不发起新的系统调用。匿名页通常按需填入，但地址空间元数据、页表以及实际缺页过程仍然消耗资源。具体成本取决于应用申请什么、访问什么，不能把延迟分配简化成近乎免费地运行整个进程。

Committed_AS 是记账数量，不是所有进程常驻集之和，也不是当前内存压力读数。映射类型会影响成本：私有可写映射可能在页面尚未全部驻留时就形成承诺，普通共享或只读文件映射则采用不同规则。因此，虚拟大小很大的进程未必就是物理内存短缺的责任方，应同时查看实际使用和对应记账范围。

三种准入政策

模式零是默认启发式政策，拒绝明显超额的申请，同时允许超过简单常驻内存预算的分配。它的判断不等于为每个获准字节准备专属 RAM。模式一跳过 overcommit 准入检查，有助于某些稀疏工作负载，但地址空间上限、映射数量以及其他分配失败仍然存在，不能描述成任何荒谬请求都会被无条件接受。

模式二执行更严格的承诺记账。名义 CommitLimit 来自交换空间加上配置的内存额度：比例计算会扣除预留给 hugetlb 的内存，非零 overcommit_kbytes 则用绝对额度代替比例。内核保留量与调用上下文还会影响实际准入。因此，CommitLimit 与 Committed_AS 的差值是有用背景，不是保证任意调用者都能一次申请成功的最大值，也不是当前可用物理内存。

需要记账的分配如果无法纳入预算，可能立即返回 ENOMEM，使部分容量问题更早暴露，包括 fork 和后续改变映射权限所需的承诺。fork 记账与具体映射及写时复制义务有关，并不是简单把父进程常驻集乘二。有些应用有意保留稀疏地址空间，因此政策变化可能影响启动，即使它们预计不会触碰所有页面。

严格记账不是 OOM 免疫

模式二降低一类超额承诺风险，却不会覆盖 cgroup 内存限制、NUMA 约束、其他内核分配以及所有后续需求。任务仍可能遇到内存分配失败或 OOM 事件。不能承诺选了模式二，某个业务工作进程就绝不会被杀，更不能把这个模式当成服务可靠性的单一开关。

OOM 牺牲者选择属于另一套政策，要结合事件范围与候选资格理解，并非随机惩罚，也不是 CPU 调度器决定谁来买单。被杀进程不一定是最后申请内存的任务。判断原因之前，应查看事件属于宿主还是某个 cgroup，并结合相关压力与分配证据，不能只凭日志里的进程名称就完成责任归因。

容器共享宿主内核，不应假定每个容器都有自己独立的 vm.overcommit_memory 政策；容器内存控制又增加另一条边界。虚拟机有自己的客户机内核记账，但宿主后备内存和气球等机制还可能增加约束。比较预算前，应先标明每个读数属于哪一层，避免拿宿主 CommitLimit 去解释某个容器的完整可用额度。

坏掉的样子

工作负载可以成功保留内存，随后随着真实需求增长进入回收、交换或 OOM。模式零和模式一都不保证故障一定慢慢发生，不保证有交换空间，也不保证由某个固定进程被杀。应把业务需求和延迟与真实回收、内存压力证据对齐，而不是由模式编号直接猜测故障形态。

相反，模式二可能在物理内存看似仍有空闲时拒绝申请，因为承诺预算已经占满。这是 ENOMEM 的一个可能原因，不是仅凭错误就得出的诊断；进程资源限制、映射过多和应用配置也需要检查。一次启动失败与一次运行中被杀代表不同观察，不应混成同一条调参建议。

名义余量很大，不证明比例太保守；余量很小，也不自动意味着应增大额度。预算变大会放行更多未来可能竞争真实资源的需求。应根据业务要求与恢复余量做规划，保留配置上下文，并先在非生产环境验证变化。只读报告可以帮助提出问题，但不应擅自替操作者决定扩大或缩小系统承诺。

overcommit 控制承诺准入；获准申请仍面对后续物理资源及 cgroup 约束。

快速验证

保存为 overcommit_probe.py，运行 python3 overcommit_probe.py。程序只读取列出的 proc 文件，打印实际模式和记账字段，同时执行合成解析检查。它不保留巨大内存、不触发 OOM，也不自动建议修改参数。读不到必要文件时明确跳过，而不是把权限错误文本里的数字当作有效内存数据。

from pathlib import Path
import re


def read_value(path):
 try:
 return Path(path).read_text(encoding="utf-8").strip()
 except OSError as error:
 print("SKIP", path, type(error).__name__)
 return None


def meminfo_kb(text):
 return {name: int(value) for name, value in re.findall(
 r"^(MemTotal|SwapTotal|CommitLimit|Committed_AS):\s+(\d+)\s+kB\s*$",
 text, re.M)}


def report(mode, info):
 names = {"0": "heuristic", "1": "always overcommit", "2": "strict accounting"}
 lines = ["mode: " + names.get(mode, "unknown or unreadable")]
 limit, committed = info.get("CommitLimit"), info.get("Committed_AS")
 if limit is not None and committed is not None:
 lines.append("nominal commit headroom: %s kB" % (limit - committed))
 else:
 lines.append("commit headroom unavailable")
 if mode == "2":
 lines.append("Commit accounting can reject chargeable requests; other limits still apply")
 else:
 lines.append("CommitLimit is not the enforced mode-2 ceiling in this mode")
 lines.append("This snapshot is not available RAM, a cgroup budget, or OOM immunity")
 return lines


fixture = meminfo_kb("CommitLimit: 100 kB\nCommitted_AS: 0 kB\n")
assert "nominal commit headroom: 100 kB" in report("2", fixture)
assert meminfo_kb("CommitLimit: bad kB\nCommitted_AS: 7 MB\n") == {}
assert "commit headroom unavailable" in report("2", {})
assert report("9", {})[0] == "mode: unknown or unreadable"
for mode in ("0", "1", "2"):
 assert "OOM immunity" in report(mode, fixture)[-1]

mode = read_value("/proc/sys/vm/overcommit_memory")
ratio = read_value("/proc/sys/vm/overcommit_ratio")
kbytes = read_value("/proc/sys/vm/overcommit_kbytes")
text = read_value("/proc/meminfo")
if mode is None or text is None:
 print("SKIP live overcommit report; synthetic checks passed")
else:
 info = meminfo_kb(text)
 print("overcommit_memory=%s overcommit_ratio=%s overcommit_kbytes=%s" % (mode, ratio, kbytes))
 print("Observed kB fields:", info)
 for line in report(mode, info):
 print(line)

预期得到实时快照，或明确的 SKIP 信息；已提交量为零仍是有效值。修订后的示例已在 Linux、Python 3.12.14 下通过，合成断言覆盖错误格式、缺失字段和三种模式的解释。读取计数没有验证真实分配拒绝或恢复行为；这些仍需要另外设计受控实验，不能为了检查政策而在共享机器上制造内存耗尽。

来源

内核 vm 参数文档，定义 overcommit_memory 各模式与默认值，已核验 2026-06-01。
proc 手册页，记录 /proc/meminfo 中 CommitLimit 与 Committed_AS 的记账含义，已核验 2026-06-01。
内核 overcommit 记账规则，核对策略模式与纳入承诺记账的映射，已核验 2026-10-15。
proc_meminfo：CommitLimit 与 Committed_AS，核对内存承诺、大页计数与单位，已核验 2026-10-15。
内核 cgroup v2 内存控制，核对局部内存限制与 OOM 边界，已核验 2026-10-15。

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。

veth 对在两个端点之间搬运帧，路由决定这些帧承载的路径

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

veth 对由两个互联的虚拟以太网设备组成。从一端发送的帧到达另一端，再由接收网络栈或网桥处理。两端可以放在不同 Linux 网络命名空间，因此常用于容器网络。创建这一对设备只提供链路，地址、路由、桥接关系、转发和访问策略都需要另外配置。不能把接口已经出现，等同于完整网络已经准备好。

坏掉的样子

接口显示管理状态 UP，仍可能因为 veth 对端关闭而没有载波。只读取 UP 标志，会让尚未完成的配置看起来已经就绪。应检查两个端点，并区分管理状态与 LOWER_UP。路由也可能已经指向这个接口，但链路仍无法承载有效流量，所以路由列表本身不是连通性检查，更不能代替一次真实应用交换。

veth 对不会把 IP 载荷限制为对端接口自身地址。路由选择报文经过哪个链路，随后以太网转发或接收网络栈决定下一步处理。发往容器直接邻居之外的流量，也可以通过这一对设备到达路由器或网桥。声称“不发给对端的包都会留在本地”，混淆了链路交付与 IP 目的地选择，容易误导容器出口排障。

两端生命周期也相互关联。删除一个 veth 端点，会移除另一个端点，即使对端由另一个命名空间管理。因此宿主侧清理动作可能删除容器接口。影响活跃工作负载时，应有意识地安排停止流量、调整路由和删除设备的顺序。命名空间分离了管理视图，却没有让成对设备变成两项互不影响的资源。

veth：跨命名空间设备对：概念机制与预期检查，不是新增运行证据。

快速验证

将脚本保存为 check-veth.py，仅在已获授权的一次性 Linux 实验环境中，使用核实为本地的 Docker daemon，并保留 Python 断言。配方注明 Python 3.11.16、iproute2 6.1.0，但镜像架构、包与宿主内核仍需核对。NET_ADMIN、SYS_ADMIN 无法覆盖强制策略的挂载拒绝，Docker 默认 AppArmor 配置即存在此限制。应使用兼容且获批的实验环境，不应为运行示例削弱宿主保护。嵌套命名空间与 proc 挂载需要实际内核权限，运行时隔离不代表拉取镜像和构建离线；清理命令仅尝试执行，未全部核对退出码。

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid
recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends iproute2=6.1.0-3 iputils-ping=3:20221126-1+deb12u1 nftables=1.0.6-2+deb12u2 tcpdump=4.99.3-1 traceroute=1:2.1.2-1 procps=2:4.0.2-3 && rm -rf /var/lib/apt/lists/*\nCMD ["python3"]\n'
program=r"""
from contextlib import ExitStack,contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import json,os,select,signal,subprocess,time

def run(*args,check=True,input=None,timeout=8):
 result=subprocess.run(args,input=input,capture_output=True,text=True,timeout=timeout)
 if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr)
 return result
def ns(name,*args,**kwargs):return run('ip','netns','exec',name,*args,**kwargs)
def ip(name,*args,**kwargs):return ns(name,'ip',*args,**kwargs)
def stop(process):
 if process.poll() is None:
 process.terminate()
 try:process.wait(timeout=2)
 except subprocess.TimeoutExpired:process.kill();process.wait(timeout=2)
def line(process,timeout=3):
 assert select.select([process.stdout],[],[],timeout)[0],'child response deadline exceeded'
 value=process.stdout.readline();assert value,'child exited without a response'
 return value
def spawn(stack,command):
 process=subprocess.Popen(command,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True)
 stack.callback(stop,process);return process
@contextmanager
def lab(names):
 with TemporaryDirectory(prefix='net-path-') as directory,ExitStack() as stack:
 root=Path(directory);proc=root/'proc';proc.mkdir();run('mount','-t','proc','proc',str(proc))
 stack.callback(run,'umount',str(proc))
 for name in names:
 run('ip','netns','add',name);stack.callback(run,'ip','netns','delete',name,check=False)
 ip(name,'link','set','lo','up')
 def setting(name,key,value):
 assert name in names
 path=proc/'sys'/key.replace('.','/')
 return ns(name,'python3','-c',f'from pathlib import Path; p=Path({str(path)!r}); p.write_text({str(value)!r}); print(p.read_text().strip())').stdout.strip()
 yield root,stack,setting
def wire(left,left_if,right,right_if,left_addresses,right_addresses):
 run('ip','link','add',left_if,'type','veth','peer','name',right_if)
 for name,interface,addresses in [(left,left_if,left_addresses),(right,right_if,right_addresses)]:
 run('ip','link','set',interface,'netns',name)
 for address in addresses:ip(name,'address','add',address,'dev',interface,*(['nodad'] if ':' in address else []))
 ip(name,'link','set',interface,'up')
def nft(name,script):return ns(name,'nft','-f','-',input=script)
def counters(name):
 data=json.loads(ns(name,'nft','-j','list','ruleset').stdout);found={}
 for entry in data['nftables']:
 rule=entry.get('rule',{})
 if 'comment' in rule:
 for expression in rule['expr']:
 if 'counter' in expression:found[rule['comment']]=expression['counter']['packets']
 return found

def server(stack,name,address,port=18080,label='server'):
 code=r'''
from http.server import BaseHTTPRequestHandler,ThreadingHTTPServer
import json,socket,sys
address,port,label=sys.argv[1],int(sys.argv[2]),sys.argv[3]
class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 body=json.dumps({'server':label,'peer':self.client_address,'path':self.path}).encode()
 self.send_response(200);self.send_header('Content-Length',str(len(body)));self.end_headers();self.wfile.write(body)
 def log_message(self,*args):pass
class Server(ThreadingHTTPServer):
 address_family=socket.AF_INET6 if ':' in address else socket.AF_INET
 def server_bind(self):
 if self.address_family==socket.AF_INET6:self.socket.setsockopt(socket.IPPROTO_IPV6,socket.IPV6_V6ONLY,1)
 super().server_bind()
service=Server((address,port),Handler);print('ready',flush=True);service.serve_forever()
'''
 process=spawn(stack,['ip','netns','exec',name,'python3','-u','-c',code,address,str(port),label])
 assert line(process).strip()=='ready';return process
def request(name,address,port=18080):
 code=r'''
import http.client,json,sys
client=http.client.HTTPConnection(sys.argv[1],int(sys.argv[2]),timeout=.7)
try:
 client.request('GET','/lab-visible-message');response=client.getresponse();body=json.loads(response.read())
 assert response.status==200;print(json.dumps({'ok':True,'status':response.status,'body':body}))
except OSError as error:print(json.dumps({'ok':False,'type':type(error).__name__,'errno':error.errno}))
finally:client.close()
'''
 return json.loads(ns(name,'python3','-c',code,address,str(port)).stdout)

with lab(['left','right']) as (root,stack,setting):
 run('ip','link','add','left0','type','veth','peer','name','right0')
 run('ip','link','set','left0','netns','left');run('ip','link','set','right0','netns','right')
 ip('left','addr','add','192.0.2.1/30','dev','left0');ip('right','addr','add','192.0.2.2/30','dev','right0')
 ip('left','link','set','left0','up')
 before=json.loads(ip('left','-j','link','show','left0').stdout)[0]
 assert 'LOWER_UP' not in before['flags']
 failed=ns('left','ping','-n','-c','1','-W','1','192.0.2.2',check=False);assert failed.returncode!=0
 ip('right','link','set','right0','up')
 after={name:json.loads(ip(name,'-j','link','show',interface).stdout)[0] for name,interface in [('left','left0'),('right','right0')]}
 assert all('LOWER_UP' in v['flags'] for v in after.values())
 ip('left','neigh','flush','dev','left0');ip('right','neigh','flush','dev','right0')
 successful=ns('left','ping','-n','-c','1','-W','1','192.0.2.2');assert successful.returncode==0
 daemon=server(stack,'right','192.0.2.2',label='right');response=request('left','192.0.2.2');assert response['ok']
 ip('right','addr','add','203.0.113.9/32','dev','lo');ip('left','route','add','203.0.113.9/32','via','192.0.2.2')
 server(stack,'right','203.0.113.9',label='beyond-link-address');routed_response=request('left','203.0.113.9');assert routed_response['ok']
 ip('left','link','delete','left0');gone=ip('right','link','show','right0',check=False);assert gone.returncode!=0 and 'does not exist' in gone.stderr
 print(json.dumps({'one_end_up_flags':before['flags'],'one_end_up_ping_exit':failed.returncode,
 'both_up_flags':{n:v['flags'] for n,v in after.items()},'both_up_ping_exit':successful.returncode,'http':response,'other_ip_destination':routed_response,
 'deleting_one_removes_peer':True,'peer_absent_diagnostic':gone.stderr.strip()}))
"""
name='xbcatm-netpath-'+uuid.uuid4().hex[:10]
def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs)
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'Dockerfile').write_text(recipe)
 build=docker('build','-t',name,str(root));assert build.returncode==0,build.stderr
 result=docker('run','--rm','-i','--name',name,'--network','none','--cap-add','NET_ADMIN','--cap-add','SYS_ADMIN',
 '--memory','256m','--pids-limit','128',name,'python3','-',input=program)
 assert result.returncode==0,result.stderr
 print(json.dumps(json.loads(result.stdout),sort_keys=True))
finally:
 docker('rm','-f',name);docker('image','rm',name)

预期顺序起初只启用 left0：管理状态 UP、没有 LOWER_UP，对端 right0 仍关闭，单次 ping 失败；随后两端应都报告 LOWER_UP。这些是需要真实 Linux 环境支持的预期观察，不是模型输出，也不是本次审阅取得的测量。管理状态与成对链路是否就绪仍应分别核对。

启用 right0 后，脚本清理失败尝试留下的邻居条目，再测试 ping 和到 192.0.2.2 的 HTTP。程序打印返回身份，但只断言客户端 ok 标志，没有单独核对身份字段的精确值。清理旧状态不能证明所有已经等待中的请求都会瞬间恢复，身份显示与身份断言也应区分。

随后右侧在回环接口配置 203.0.113.9/32，左侧添加经 192.0.2.2 到该地址的主机路由。第二个绑定 203.0.113.9 的 HTTP 监听，仍通过同一 veth 对成功响应。报文的 IP 目的地不同于对端链路地址，但所选路径依然使用这条虚拟以太网链路。这个对照直接检验地址与传输路径的区别。

第二个目的地属于右侧命名空间本地，因此本例没有声称继续经过另一个路由器转发。它只隔离链路邻居地址与最终 IP 目的地之间的差异。更大拓扑可以把接收端接入网桥或路由网络，但这些额外组件需要独立配置和验证。不能由这次成功，就推导容器已经自动获得公网出口或任意跨网段访问能力。

最后删除 left0，右侧执行 ip link show right0 得到设备不存在的诊断。对端是被移除了，而不只是进入管理关闭状态；两个命名空间本身在清理之前仍存在。这个结果区分成对设备生命周期与容纳某一端的命名空间生命周期。清理日志需要反映真正被删除的资源，不能把所有变化都写成同一种“断网”。

按层次检查实际路径

先确认两端归属的命名空间及运行时赋予的名称，再查看管理状态、载波、地址、邻居解析和失败目的地的路由。链路变化后，旧邻居状态可能延迟恢复；缺失路由则可能让报文根本没有发上链路。即使高层客户端都只显示超时，这些原因也需要不同修复。应保留各层直接证据，而不是只围绕一个接口标志反复修改。

一对设备不是多端口交换机。网桥可以在以太网层连接多个此类链路，路由器则在 IP 网络之间转发。启用端点不会自动建立这些行为，也不会自动添加互联网路由。文档应记录真实连接关系与过滤位置，尤其当容器运行时创建设备，而其他组件管理路由或防火墙时，不能假定其中一方已经完成了所有配置。

把删除视为同时影响两端，并验证相关工作负载。没有恢复到这份 fence 的精确运行证据，本次也没有执行报文交换或特权设置。以上预期序列不能证明吞吐量、延迟、卸载行为或完整容器网络。未来运行仍须绑定源码并核对清理；概念审阅与静态编译不是 Linux 网络隔离、实际送达及设备关联删除的运行证明。

来源

Linux veth(4)，成对传输、载波状态及命名空间使用，已核验 2026-09-12。
Linux ip-link(8)，veth 创建、状态、移动及删除，已核验 2026-09-12。
Linux network_namespaces(7)，网络边界与虚拟设备生命周期，已核验 2026-09-12。
Moby default AppArmor template，默认配置明确拒绝挂载，已核验 2026-10-18。
Docker AppArmor，强制策略与挂载限制，已核验 2026-10-18。
Docker run reference，能力及随能力调整的默认 seccomp 策略，已核验 2026-10-18。
Python 3.14: assert statements，优化模式会移除断言检查，已核验 2026-10-18。

缺页并不总是意味着存储读取

Sat, 13 Nov 2027 00:00:00 +0000

缺页表示处理器无法依据当前映射或权限完成一次访问。它不等于存储读取，有些缺页还代表非法访问，而不是可以恢复的按需分页。Linux 的次缺页与主缺页计数，区分处理过程中是否需要页面换入输入输出。解释时应结合映射类型与工作负载，不能把任意一个计数直接当作应用全部存储流量，更不能仅凭名字中的“主”“次”判断问题严重程度。

次缺页不代表没有成本

次缺页可能为已有文件缓存页建立映射，也可能为匿名内存分配并清零物理页，或在写时复制时复制一页内容。内核可能需要分配内存、维护页表、复制数据和同步。把它说成只增加一个指针，会遗漏这些真实成本。即使完全没有存储读取，密集次缺页仍然可以消耗可观处理器时间，影响请求延迟，不能因为分类是 minor 就无条件忽略。

应用第一次访问，并不保证每个基本页都产生一次新的缺页。预先建立映射、已存在的映射、预读相关处理和大页都可能改变计数。系统页大小也不是处处都等于四千零九十六字节。示例应读取本机值，不能从循环次数直接承诺精确缺页数量；否则换一台机器或启用不同内存策略，实验就可能因为错误前提而失败。

主缺页描述另一条处理路径

主缺页意味着处理涉及页面换入输入输出，常见于文件映射或已换出的内存。背后可能是存储设备，也可能是远程文件系统，因此这个分类不是物理磁盘延迟基准。一次缺页还可能触发预读，让后续访问直接获益，计数与页数或磁盘请求数并不一一对应。反过来，普通文件读取也可能产生输入输出，却不在应用里形成对应的主缺页。

文件页已经在主机缓存中时，新进程即使从未访问过它，也可能只产生次缺页。重启进程不等于清空整台机器的页缓存。匿名内存首次写入通常通过分配零填充页面完成，不必从存储读回旧载荷，但压力和同时发生的活动仍会影响测量。“匿名”不能保证整个进程的主缺页计数在任何环境都保持不变；应以本次实际计数为准。

坏掉的样子

冷启动延迟可能与主缺页同时出现，但在查清缺少什么之前，不应一律建议预热。提前触碰不需要的页面会消耗内存，甚至挤掉有用缓存。错开启动也许能缓解已确认的共享瓶颈，另一个负载却可能需要更小映射、不同访问模式或更多容量余量。单靠缺页数无法在这些方案之间作出可靠选择，需要把变化与业务延迟联系起来。

持续交换会让被逐出的页面反复进入工作集，并拉长等待。增加工作者可能扩大内存需求，使情况更差。应关联缺页、换入换出、回收、存储等待和请求延迟，而不是一看到主缺页上升就宣布存储设备损坏，或认定所有缓存缺失都本来可以避免。对顺序扫描和随机访问，也应分别理解预读与局部性的作用。

进程级计数还包含测量代码之外的工作。解释器、启动过程和其他线程都可能贡献变化。常驻情况查询只是一个时刻的快照，紧接着访问时状态可能已经改变。不要为了得到更明显的图表就清空全局缓存，或不断扩大分配直到影响其他任务。诊断实验应该有明确资源预算，并保留失败时的原始观察，而不是只保留符合预期的数字。

次缺页、主缺页与非法访问走不同路径；匿名内存示例并未覆盖所有路径。

快速验证

保存为 fault_probe.py，在有足够空闲内存的 Linux 上使用 Python 3.9 或更新版本执行 python3 fault_probe.py。程序创建十六 MiB 的私有匿名映射，按本机页大小每页写一个字节，再重复一轮。结束时自动关闭映射，不操作文件、不修改全局缓存设置，也不改变任何内存限制。

import mmap
import resource
import sys
import time

if not sys.platform.startswith("linux"):
 raise SystemExit("This exercise requires Linux getrusage semantics")
PAGE = mmap.PAGESIZE
SIZE = 16 * 1024 * 1024

def counters():
 value = resource.getrusage(resource.RUSAGE_SELF)
 return value.ru_minflt, value.ru_majflt

def touch(region):
 for offset in range(0, len(region), PAGE):
 region[offset] = 1

with mmap.mmap(-1, SIZE, flags=mmap.MAP_PRIVATE | mmap.MAP_ANONYMOUS,
 prot=mmap.PROT_READ | mmap.PROT_WRITE) as region:
 before = counters()
 start = time.perf_counter()
 touch(region)
 first_seconds = time.perf_counter() - start
 middle = counters()
 start = time.perf_counter()
 touch(region)
 second_seconds = time.perf_counter() - start
 after = counters()
first = tuple(b - a for a, b in zip(before, middle))
second = tuple(b - a for a, b in zip(middle, after))
print(f"page_size={PAGE} mapping_bytes={SIZE}")
print(f"first: minor={first[0]} major={first[1]} seconds={first_seconds:.6f}")
print(f"second: minor={second[0]} major={second[1]} seconds={second_seconds:.6f}")
assert first[0] > 0, "expected demand-fault activity"
assert second[0] < first[0], "repeat pass did not show reduced minor faults"
assert first[1] == second[1] == 0, "observed major faults: this run is not a no-major example"
print("PASS: this run had fewer second-pass minor faults and no measured major faults")

本实验预期第一轮出现按需缺页，第二轮次缺页减少，并且这次运行没有测得主缺页。本轮两种语言的完整示例均通过这些断言。计数与耗时只是观察，不是固定目标。脚本没有断言第二轮一定更快，因为计时、调度和机器负载会变化。使用本机页大小，也避免把某种平台常见值误当成通用常量。

如果断言失败，说明当前运行没有建立预期对照，应检查内存条件和计数，不能悄悄删除检查。通过结果展示的是一个匿名内存案例：发生了缺页活动，却没有测得页面换入输入输出。它没有演示文件映射主缺页，没有给出通用缺页延迟，也不能替代真实应用在代表性压力下的测量。把这个局部结论保持在实验范围内，才不会从可重复现象跳到错误的生产诊断。

来源

Linux getrusage，次缺页和主缺页计数语义，已核验 2026-10-15。
Linux mmap，私有匿名映射与预先填充行为，已核验 2026-10-15。
Linux memory concepts，按需分页、页缓存、回收和大页，已核验 2026-10-15。
Linux process stat，进程缺页计数与范围，已核验 2026-10-15。

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。

按文档读取不断变化的进程 procfs 视图

Fri, 29 Oct 2027 00:00:00 +0000

Linux procfs 通过文件系统接口暴露进程和内核信息。许多入口在读取时生成内容，而不是保存普通磁盘文件字节；每个入口都有具体含义、权限模型和格式。连续读取多个入口，不会冻结进程，也不会得到事务一致快照。因此，有用的观察必须对应正确进程实例和正确解释，不能因为内容都来自 proc，就假定它们是同一时刻的完整状态。

成功读取链接文本，不保证能够通过链接打开对象。Linux 还会单独检查被引用 inode 的权限。反过来，只读取描述符链接文字也不等于消费了持有者的数据。应分清查看元数据、打开引用对象以及读取对象内容，尤其是管道等带状态的数据流，不能把本例普通文件的结果泛化到所有描述符。

每个 procfs 入口都是有文档定义且受权限检查的视图。读取时刻、进程身份、专用解析方式和对象寿命，共同决定观察能够证明什么。

坏掉的样子

普通文件假设可能立刻失效。proc 条目报告大小为零，却仍然返回有用内容；逐进程目录可能随着进程退出消失，数字 PID 之后也可能指向另一个实例。读取失败不一定表示系统安装损坏，某个编号也不会永久代表同一工作负载。生命周期变化本来就是观测需要处理的条件，应避免把正常退出当成异常环境。

不同入口需要按各自格式解析。status 包含有标签字段，stat 则使用固定字段顺序，其中括号包住的命令名可以包含空格和右括号。直接把整行按空白拆分，会让预期字段错位。cmdline 与 environ 使用空字符分隔，普通按行或空格切分，会破坏参数和值的边界。解析方式必须来自接口文档，而不是文件看起来像文本这一点。

视图本身也有语义边界。environ 描述程序执行时建立的环境区域，不保证是所有后续环境修改的实时字典；命令行内容也可以被进程修改。描述符链接以 deleted 结尾，不表示打开对象已经消失。这些入口提供具体状态证据，却不是可以互相替代的身份凭据或访问保证，需要先明确每项观察到底回答什么问题。

快速验证

把脚本保存为 procview.py，在一次性 Linux 环境中运行 python3 procview.py。2026-10-15 的复核记录了该样本在 Linux 6.18.44 和 Python 3.12.14 上通过；此次未重跑。脚本启动一个受控子进程，显式提供少量环境值，只读取自己及该子进程的 proc 条目，不写入内核调节接口：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,os,subprocess,sys

worker=r'''
from pathlib import Path
import ctypes,json,os,sys
assert ctypes.CDLL(None).prctl(15,b'worker ) sample',0,0,0)==0
os.environ['XB_PROC_TEST']='changed-after-start'
path=Path(sys.argv[1]);path.write_bytes(b'fixture-data')
with path.open('rb') as handle:
 info=os.fstat(handle.fileno());path.unlink()
 print(json.dumps({'fd':handle.fileno(),'device':info.st_dev,'inode':info.st_ino,'current_environment':os.environ['XB_PROC_TEST']}),flush=True)
 assert sys.stdin.readline()=='done\n'
'''
with TemporaryDirectory(prefix='xbcatm-proc-') as directory:
 path=Path(directory)/'data'
 process=subprocess.Popen([sys.executable,'-c',worker,str(path),'argument with spaces'],stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True,env={'PATH':'/usr/bin:/bin','XB_PROC_TEST':'fixture-value'})
 try:
 metadata=json.loads(process.stdout.readline());root=Path('/proc')/str(process.pid)
 status_path=root/'status';status_text=status_path.read_text()
 assert status_path.stat().st_size==0 and len(status_text)>0
 status=dict(line.split(':',1) for line in status_text.splitlines() if ':' in line)
 assert int(status['Pid'])==process.pid and int(status['PPid'])==os.getpid()
 raw=(root/'stat').read_text();pid_text,rest=raw.split(' (',1);comm,fields=rest.rsplit(') ',1)
 fields=fields.split();assert int(pid_text)==process.pid and comm=='worker ) sample'
 assert int(fields[1])==os.getpid() and int(fields[19])>0
 assert raw.split()[2] not in ('R','S','D','T','Z')
 print('proc files can have size zero but readable data; stat comm can contain spaces and a closing parenthesis')
 args=(root/'cmdline').read_bytes().rstrip(b'\0').split(b'\0')
 environment=(root/'environ').read_bytes().rstrip(b'\0').split(b'\0')
 assert args[-1]==b'argument with spaces' and b'XB_PROC_TEST=fixture-value' in environment
 assert metadata['current_environment']=='changed-after-start'
 assert os.readlink('/proc/self')==str(os.getpid())
 print('cmdline and environ use NUL separators; environ retains the initial value here; self resolves for the reader')
 entry=root/'fd'/str(metadata['fd']);target=os.readlink(entry);actual=entry.stat()
 assert target==str(path)+' (deleted)' and not path.exists()
 assert (actual.st_dev,actual.st_ino)==(metadata['device'],metadata['inode'])
 assert entry.read_bytes()==b'fixture-data'
 print('a deleted pathname remains inspectable through an open descriptor subject to access checks')
 output,error=process.communicate('done\n',timeout=5)
 assert process.returncode==0,error
 assert not root.exists()
 print('after the controlled child exits and is reaped, its proc directory disappears')
 finally:
 if process.poll() is None:process.kill();process.wait()

子进程把短名称设为带空格和右括号的 worker ) sample，打开临时文件，再删除路径但保持描述符打开。随后它仅报告样本元数据并等待，让控制进程拥有一份已知存活对象。这个名称刻意触发 stat 格式边界，使解析验证不依赖“进程名碰巧没有空格”的理想情况。

控制进程发现 status 报告大小为零，却能读到非空内容，并按标签检查 PID 与父 PID。对于 stat，先分离 PID 和括号内名称，再解释其余位置字段，确认父 PID 和正的启动时间值。简单空白拆分会把名字的一部分误当作后续字段，因此不能直接以普通单词序号套用文档中的字段编号。

最后一个命令行参数含空格，按空字符拆分后仍然保持为一个参数。初始环境包含实验值 fixture-value，即使子进程在启动后已把应用环境改成另一个值。两项观察只使用无害样本数据，分别说明空白解析和实时环境字典假设为什么会出错。它们验证的是具体区域的实际内容，不是根据程序配置推测结果。

控制进程读取 /proc/self，得到自己的 PID。子进程的描述符链接显示带 deleted 后缀的已删除路径，但在实验权限下，跟随 proc 描述符入口仍能看到预期设备、inode 和样本字节。普通路径缺失与打开对象存活，是两个同时成立的事实，不能仅凭其中一项推断文件已经不再被任何进程使用。

收到控制进程消息后，子进程关闭句柄并退出。控制进程等待完成，再确认该子进程的 proc 目录消失。这个样本建立了受控的前后生命周期对照，没有保证繁忙应用不断变化时，任意多个 proc 读取之间都具有原子一致性。实际采集需要根据接口和对象寿命解释不同时刻的数据。

让视图对应实际问题

应使用入口文档规定的解析方式和单位。只有正确处理命令名之后，stat 字段编号才有意义；status 标签也不应绑定假定行号。关联多次样本时，可按需要记录进程启动时间和开机上下文，避免把重复使用的数字 PID 当成同一实例。一个看起来稳定的路径字符串，不能单独保证观察期间对象身份没有变化。

访问权限和命名空间同样影响结果。proc 挂载选项、凭据和 ptrace 相关检查，可以限制可见性。/proc/net 反映相应网络命名空间，容器看到的 proc 数据也不自动等于它配置的资源预算。给观察贴上整机或容器标签之前，应确认实际命名空间，以及哪一个资源接口真正回答当前运维问题。

部分 proc 条目确实接受控制写入，但作用范围不同。/proc/sys 暴露调节参数，/proc/PID/oom_score_adj 调整具体进程的 OOM 偏好；向 status 写整数不是完成后一任务的接口。应把观察与有意配置变更分开，并在写入前核对真实目标和文档权限，不能把所有可见条目都当作同一种可写配置文件。

来源

proc(5)，procfs 结构、逐进程可见性与挂载选项，已核验 2026-10-15。
proc_pid_stat(5)，字段布局、括号内命令名与启动时间，已核验 2026-10-15。
proc_pid_environ(5)，初始环境区域与空字符分隔条目，已核验 2026-10-15。
proc_pid_fd(5)，描述符链接、引用对象与权限检查，已核验 2026-10-15。
proc_pid_cmdline(5)，参数分隔符与受进程控制的命令行内容，已核验 2026-10-15。

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。

inotify 报告变化，但不是完整历史记录

Wed, 13 Oct 2027 00:00:00 +0000

inotify 通过一个带注册监视项和可读事件队列的实例，投递 Linux 文件系统通知。每条记录包含监视编号、事件掩码，也可能包含名字和移动 cookie。这能减少对未变化路径的反复检查，但事件流不是无限审计日志。正确消费者应把通知理解为相关状态可能需要重新检查的证据，而不能默认它保存了文件发生过的每一次操作。

通知是有边界的变化证据。覆盖范围、对象替换与队列丢失，都要求重新核对文件系统当前状态；重扫不能补回缺失的事件历史。

坏掉的样子

监视目录不会递归监视后代。它报告直接目录项上的相关活动，因此需要观察更深变化时，新子目录也需要独立监视。目录树监视器必须处理初次枚举和之后加入的目录。假定只注册根目录就覆盖整棵树，会悄悄漏掉更深层变化；能收到子目录被创建，并不代表能收到它内部之后的全部操作。

文件监视跟随具体对象，不会永久绑定路径。编辑器可以先写完并关闭临时文件，再用 rename 替换目标。父目录会报告替换，旧文件监视却不会转移到新 inode。如果消费者等待目标名字之后再出现 close-write，可能永远等不到，因为替代文件在发布前已经关闭。不能把一种编辑器保存顺序当成所有更新方式的固定流程。

连续产生且尚未读取的相同事件可以合并，队列满后会丢弃事件并报告 IN_Q_OVERFLOW。因此，事件数量不是可靠写入计数。溢出后，消费者无法仅靠剩余记录重建全部缺失操作，必须重新核对当前监视状态，不能继续假定根据事件维护的模型完整。历史丢失与当前状态仍可读取，是需要分别理解的两件事。

快速验证

把脚本保存为 inotify-events.py，在一次性 Linux 环境中运行 python3 inotify-events.py。此前记录使用 Linux 6.12.76 和 ext4；2026-10-15 的复核记录了两种语言样本在 Linux 6.18.44、Python 3.12.14 上通过。该记录属于历史执行，此次未重跑。样本创建 ASCII 名称的临时条目，并有意填满自己的队列。配置的队列上限必须不超过三万二千七百六十八；脚本只读取上限，不修改任何 sysctl：

from pathlib import Path
from tempfile import TemporaryDirectory
import ctypes,os,struct

MODIFY=0x2;ATTRIB=0x4;CLOSE_WRITE=0x8;MOVED_FROM=0x40;MOVED_TO=0x80
CREATE=0x100;DELETE=0x200;DELETE_SELF=0x400;MOVE_SELF=0x800;OVERFLOW=0x4000;IGNORED=0x8000
libc=ctypes.CDLL(None,use_errno=True)
libc.inotify_init1.argtypes=[ctypes.c_int];libc.inotify_init1.restype=ctypes.c_int
libc.inotify_add_watch.argtypes=[ctypes.c_int,ctypes.c_char_p,ctypes.c_uint32];libc.inotify_add_watch.restype=ctypes.c_int
header=struct.Struct('iIII')
with TemporaryDirectory(prefix='xbcatm-inotify-') as directory:
 root=Path(directory);fd=libc.inotify_init1(os.O_NONBLOCK|os.O_CLOEXEC);assert fd>=0,os.strerror(ctypes.get_errno())
 def watch(path,mask):
 wd=libc.inotify_add_watch(fd,os.fsencode(path),mask);assert wd>=0,os.strerror(ctypes.get_errno());return wd
 def drain():
 events=[]
 while True:
 try:data=os.read(fd,65536)
 except BlockingIOError:return events
 offset=0
 while offset<len(data):
 wd,mask,cookie,length=header.unpack_from(data,offset);offset+=header.size
 name=data[offset:offset+length].split(b'\0',1)[0].decode();offset+=length
 events.append((wd,mask,cookie,name))
 try:
 parent=watch(root,MODIFY|CLOSE_WRITE|CREATE|DELETE|MOVED_FROM|MOVED_TO)
 sub=root/'sub';sub.mkdir();drain();(sub/'unwatched').touch();assert drain()==[]
 nested=watch(sub,CREATE);(sub/'watched').touch();assert any(wd==nested and mask&CREATE and name=='watched' for wd,mask,_,name in drain())
 print('a directory watch is not recursive; adding a child-directory watch observes its new entries')
 counter=root/'counter';stream=os.open(counter,os.O_CREAT|os.O_WRONLY,0o600);drain()
 try:
 for _ in range(3):os.write(stream,b'x')
 finally:os.close(stream)
 events=drain();assert sum(wd==parent and bool(mask&MODIFY) and name=='counter' for wd,mask,_,name in events)==1
 moved=root/'moved';counter.rename(moved);events=drain()
 before=next(e for e in events if e[1]&MOVED_FROM and e[3]=='counter');after=next(e for e in events if e[1]&MOVED_TO and e[3]=='moved')
 assert before[2]==after[2]!=0
 print('three unread identical modifications coalesce; rename FROM/TO events share a nonzero cookie')
 target=root/'target';target.write_bytes(b'old');file_watch=watch(target,MODIFY|ATTRIB|DELETE_SELF|MOVE_SELF);drain()
 replacement=root/'replacement';replacement.write_bytes(b'new');drain();replacement.replace(target);events=drain()
 assert any(wd==file_watch and mask&IGNORED for wd,mask,_,_ in events)
 assert any(wd==parent and mask&MOVED_TO and name=='target' for wd,mask,_,name in events)
 assert not any(wd==parent and mask&CLOSE_WRITE and name=='target' for wd,mask,_,name in events)
 target.write_bytes(b'newer');events=drain()
 assert any(wd==parent and mask&MODIFY and name=='target' for wd,mask,_,name in events)
 assert all(wd!=file_watch for wd,_,_,_ in events)
 print('replacement invalidates the old file watch; the parent-directory watch continues to observe the pathname')
 burst=root/'burst';burst.mkdir();drain();watch(burst,CREATE)
 limit=int(Path('/proc/sys/fs/inotify/max_queued_events').read_text());assert 0<limit<=32768,'use a disposable environment with a bounded queue limit'
 for number in range(limit+8):(burst/str(number)).touch()
 events=drain();assert any(wd==-1 and mask&OVERFLOW for wd,mask,_,_ in events)
 current=len(list(burst.iterdir()));assert current==limit+8
 print('actual queue overflow:',len(events),'events retained for',current,'creates; rescan sees the current entries')
 finally:os.close(fd)

第一组监视父目录，创建子目录，并读走父级事件。随后在子目录内部创建文件，不会向父监视项产生事件；显式增加子目录监视后，下一次创建才被看到。这在同一个 inotify 实例中区分直接目录项覆盖和递归监视，避免只检查注册调用成功就以为整棵树都已进入观察范围。

对同一文件连续写三次，期间不读取队列，最终只观察到一条对应 modify 事件。随后重命名该文件，得到 cookie 相同且非零的 FROM 与 TO 记录。前者证明合并，而非每次写入都有独立通知；后者帮助关联这两条移动记录，却不是文件整个后续生命周期的持久身份，不能把它当作不会变化的对象编号。

接着监视一个文件，再用已经写完并关闭的文件替换其路径。旧对象被删除时，原监视项收到 ignored；父目录监视收到目标名字的 MOVED_TO，这次发布没有伴随目标 close-write。之后写入替代文件，父目录监视能看到，已经移除的旧文件监视不能。这正好验证路径替换时两种监视范围的不同结果。

溢出实验在队列上限一万六千三百八十四时，创建一万六千三百九十二个不同条目。得到一万六千三百八十五条记录，其中包含监视编号为负一的溢出通知；重新扫描目录，则找到全部当前条目。这同时展示缺失的事件历史，以及恢复当前状态知识的实际方法，不能把两者混称为完整历史恢复。

全部监视都属于一个由样本拥有的实例，清理临时目录树前会先关闭它。实验没有制造系统级监视项短缺，也没有修改其他应用队列。有界突发验证了真实溢出行为，不需要让应用长期过载，更没有把从未观察到的丢失信号当成已经验证。环境前提不满足时会明确失败。

协调路径和对象寿命

两侧移动都可见时，可以按 cookie 配对，但要处理移入、移出观察集合，以及中间穿插其他记录的情况。行动前还应检查相关路径。事件里的名字描述被报告的变化，不保证消费者稍后打开时，那里仍然是同一对象。通知与读取之间的变化窗口，需要由应用当前状态校验来处理。

监视目录树时，应在建立监视与核对目录内容之间考虑枚举期间发生的活动。溢出后，要从文件系统重建受影响状态，并恢复必要的监视覆盖。溢出记录不会指定一个缺失文件名，因此不能按普通逐监视项事件处理它，也不能仅重读某个碰巧出现在队列末尾的路径就声称完整恢复。

适合由通知触发的工作，应能容忍重复或合并变化，例如校验当前内容后重新加载整份配置。如果每一次状态转换都必须保留，则需要应用日志或具有相应历史契约的接口。inotify 的价值建立在它的覆盖和丢失规则与需求相匹配，而不是把事件队列想象成不会漏项的永久记录。

来源

inotify(7)，事件格式、合并、溢出、重命名与非递归监视，已核验 2026-10-15。
inotify_add_watch(2)，监视注册与对象身份，已核验 2026-10-15。
Linux 6.12 inotify UAPI，可执行样本使用的事件结构和标志值，已核验 2026-10-15。

硬链接共享 inode，替换名字后关系会改变

Sun, 10 Oct 2027 00:00:00 +0000

硬链接为已有文件增加另一个目录项。两个名字都指向同一文件系统里的同一个 inode，其中没有哪个天然具有“原件”地位。内容、所有者、权限和链接数属于这个共享对象，文件名只是到达它的入口。因此，需要把目录项的变化与文件对象本身的变化分开理解，才能判断修改、删除和替换到底影响了哪些访问路径。

名字与打开引用的寿命不同。应跟踪 inode，并检查实际更新方式。

坏掉的样子

把硬链接当成独立备份，会产生错误的恢复边界。通过任意名字写入或截断共享 inode，另一名字读到的内容也会改变；修改模式位，同样改变的是一个对象的权限。第二个路径可以在第一个路径被删除后继续存在，却不能抵御针对共享文件的普通原地修改，也不会自动保留先前历史版本。

许多编辑器和部署工具采用另一种更新方式：先创建替代文件，再通过 rename 覆盖某个路径。该目录项此时指向新 inode，其他硬链接仍然到达旧对象。两个名字是否一起显示新内容，取决于实际更新方法。因此不能仅凭它们昨天建立过硬链接，就断言今天仍共享身份；应检查当前对象以及写入工具的真实行为。

硬链接还受文件系统挂载边界约束。即使两个目录在统一路径树里看起来相邻，link 也不能随意把不同挂载中的对象连接起来。Linux 还禁止普通目录硬链接。这些限制意味着，硬链接不能作为跨目录层次、跨挂载符号链接的通用替代品；使用前必须先确认目标对象和边界，而不是只看路径字符串。

快速验证

把脚本保存为 hardlinks.py，在有权创建临时目录的 Linux 环境运行 python3 hardlinks.py。它要求 /tmp 与 /run 可写且属于不同文件系统；需要时可将 CROSS_ROOT 设为另一文件系统上的可写目录。实验不要求 root，也不创建挂载，并会明确检查跨文件系统前提。实测使用两个独立 tmpfs 挂载、Linux 6.12.76 和 Python 3.11.2，所有新建条目都位于临时目录中：

from pathlib import Path
from tempfile import TemporaryDirectory
import errno,os

with TemporaryDirectory(prefix='xbcatm-hardlinks-',dir='/tmp') as directory, TemporaryDirectory(prefix='xbcatm-crosslink-',dir=os.environ.get('CROSS_ROOT','/run')) as other:
 root=Path(directory);source=root/'source';alias=root/'alias'
 source.write_bytes(b'original');os.link(source,alias)
 before=source.stat();linked=alias.stat()
 assert (before.st_dev,before.st_ino)==(linked.st_dev,linked.st_ino)
 assert before.st_nlink==linked.st_nlink==2 and before.st_size==linked.st_size==8
 alias.write_bytes(b'changed')
 assert source.read_bytes()==b'changed'
 print('two names share device/inode, size, and link count; in-place write changes both views')
 replacement=root/'replacement';replacement.write_bytes(b'new file');replacement.replace(source)
 assert source.stat().st_ino!=alias.stat().st_ino
 assert source.read_bytes()==b'new file' and alias.read_bytes()==b'changed'
 assert source.stat().st_nlink==alias.stat().st_nlink==1
 print('atomic replacement changes one name to a new inode; the other name retains the old file')
 with alias.open('rb') as opened:
 alias.unlink()
 assert os.fstat(opened.fileno()).st_nlink==0 and opened.read()==b'changed'
 print('last unlink removes the final name but an existing open descriptor still reads the old data')
 assert root.stat().st_dev!=Path(other).stat().st_dev,'exercise requires two filesystem mounts'
 try:os.link(source,Path(other)/'cross-filesystem')
 except OSError as error:assert error.errno==errno.EXDEV,error
 else:raise AssertionError('cross-filesystem hard link unexpectedly succeeded')
 child=root/'directory';child.mkdir()
 try:os.link(child,root/'directory-link')
 except OSError as error:assert error.errno==errno.EPERM,error
 else:raise AssertionError('directory hard link unexpectedly succeeded')
 print('cross-filesystem link fails with EXDEV; directory hard link fails with EPERM on Linux')

样本先创建 source，写入八字节内容，再通过 os.link 添加 alias。两个名字报告相同的设备与 inode 组合、八字节大小，以及值为二的链接数。比较时必须包含设备身份，因为 inode 编号并不跨文件系统全局唯一；仅仅比较内容相同，也无法证明两个入口共享对象，独立副本同样可能有相同字节。

通过 alias 写入 changed，会修改现有 inode，因此读取 source 得到相同新内容。这次操作是普通截断写入，没有替换路径。结果直接解释了为什么第二个名字不能作为保护旧内容的独立副本：只要写者能够修改共享对象，两条访问路径就一起看到变化，即使另一条路径从来没有被该写者直接打开。

随后，包含 new file 的独立文件通过 rename 替换 source。两个名字此时报告不同 inode，链接数分别变成一。source 读到替代文件，alias 则保留 changed。替换只改变选中的目录项，不会搜索旧 inode 的其他名字，更不会把所有硬链接统一改指向新对象。更新行为由对象身份决定，而不是由哪个名字被称作原件决定。

样本打开 alias，再删除它最后的目录项。通过已打开描述符读取状态，链接数为零，但仍能读到 changed。打开引用在关闭前继续保留访问能力。链接数为零，表示没有硬链接名字留下，并不表示每个进程都立即失去现有引用；因此路径消失与所有使用者结束，是需要分别观察的状态。

最后，向第二个文件系统建立硬链接得到 EXDEV，尝试硬链接目录得到 EPERM。脚本检查具体错误。如果两个临时根目录实际位于同一文件系统，前提检查会明确失败，不会假装已经验证跨文件系统限制。这样得到的失败证据对应真实边界，而不是依据目录名字推测挂载关系。

检查身份和实际更新方式

依赖共享存储之前，应检查目标路径当前的设备与 inode 组合及链接数。链接数说明有多少硬链接目录项指向对象，但不会列出这些名字位于哪里。遍历目录寻找匹配 inode 是另一个操作，会受访问权限和扫描期间变化影响。不能把一个计数当成完整路径清单，也不能忽略检查之后对象仍可能被替换。

如果使用硬链接构建类似快照的目录树，应确保更新采用替换文件方式，并控制所有能够触及共享 inode 的写者。文件系统快照与独立复制具有不同契约。节省空间的链接树，应按照真实更新方式和保留能力描述，而不能仅凭多个目录看起来各有一份文件，就声称已经建立独立备份。

unlink 和 rename 主要影响命名空间可见性。本实验验证身份与打开引用行为，没有验证断电后的持久性。如果发布结果必须可靠落盘，还应另外核对文件系统同步要求与应用恢复流程。多保留一个名字，或者观察到原子替换成功，都不足以单独证明预期数据能够经历崩溃并完整保留。

来源

link(2)，共享 inode 身份、跨文件系统限制与目录链接错误，已核验 2026-09-12。
unlink(2)，链接数减少与已取消链接文件的打开寿命，已核验 2026-09-12。
rename(2)，替换一个路径而不改变其他硬链接，已核验 2026-09-12。

Cron 按日历重复触发任务

Thu, 30 Sep 2027 00:00:00 +0000

Cron 按日历字段匹配时间，并在匹配时启动命令。它不会天然等待同一个命令的上一次执行结束。如果每分钟触发的任务要运行七十秒，下一分钟就可能再启动一份。因此，触发规则、并发规则和成功完成状态必须分别设计，不能因为写好了一个周期表达式，就认为重复工作的所有行为都已经确定。

示意轨道展示七十秒工作结束前，下一次日历触发已到来。共享非阻塞锁使后来实例记录跳过，但不保证业务效果恰好一次。原文此前的计时结果未在本轮重跑。

把字段理解为日历选择

传统用户 crontab 一行依次包含分钟、小时、月内日期、月份、星期，然后是命令。星号表示该字段的全部取值。分钟位置的 */15 是在每个小时内选择相应分钟值，不是从上次任务结束之后再计时十五分钟。步长如果不能均匀划分字段范围，跨过边界时就可能出现不同长度的间隔，不能把它当作连续经过时长。

Debian/Vixie 格式对于两个日期字段有特殊规则：当月内日期和星期都受到限制时，满足其中一个日期条件就可能运行，而分钟、小时和月份限制仍然必须满足。这不是月份与星期之间的“或”关系。安装简短表达式之前，应列出具有代表性的实际日期核对意图，避免以为“每月某日恰好是周五”却写成两个日期条件各自都能触发。

时区、夏令时变化和停机都会影响日历调度，不同实现对跳过或重复时段的处理并不完全相同。Debian 文档为部分小幅时钟调整和固定时间任务定义了特殊行为，从其他调度器复制结论可能不适用。本实验没有修改时钟，也没有覆盖这些切换情况。日历触发同样不等于持久队列，不能自动保证停机期间错过的每次任务都会补跑。

坏掉的样子

重叠任务可能重复产生副作用、争夺资源或相互覆盖文件。如果要求同一时刻只有一个实例，就要明确实现这一政策。非阻塞建议锁可以让后来的实例记录跳过；阻塞锁则可能留下等待进程。两种选择都不自动提供业务效果恰好一次，也不能修复已经执行了一半的操作。是否允许跳过，应来自任务自己的业务要求。

本地文件锁只协调使用同一相关锁机制的参与者，不会自动串行化无关主机上的工作。网络文件系统的锁语义也需要单独确认。锁必须覆盖实际工作生命周期，跳过结果则应能被观察。如果一个实例永久卡住，后来每次触发都静默丢弃，表面上调度器还在工作，但业务可能早已停止推进，因此还要监控最近成功完成距今多久。

Cron 也并非一律没有日志。Debian 默认通过 syslog 记录任务启动，并提供更细的日志选项。命令输出可能在可用邮件链路存在时被投递，但极简容器经常没有这样的链路。应把启动、完成、失败和跳过结果写到明确目的地。启动记录只能证明任务被派发，不能证明真正的应用工作已经成功完成。

快速验证

2026-10-19 修复草案：此版本只进行了静态检查与离线命令／文件状态替身测试，没有执行 cron、crontab、账号或信号操作。技术与实际运行验证仍然受阻；下文测量值属于原始示例，不能视为修订版的执行结果。

未来执行必须另行获得授权，并使用新建的一次性 Debian 12 实验环境，预装 Python 3.11+、cron 3.0pl1-162 和 procps。环境不得挂载宿主目录，不得已有 root 任务表、cron 进程、/etc/crontab、/etc/cron.d 或其他用户任务表中启用的无关计划（包括周期目录的派发），也不得有并发管理员操作。root 只是权限前提，不能证明隔离。保存为 cron-overlap.py，未来命令为 python3 cron-overlap.py --isolated-disposable-lab。此参数仅确认由外部核实的前提，不能建立隔离。应预留约两分钟等待真实日历触发，并在结束后丢弃整个环境。

实验任务表用 MAILTO 禁用邮件。任务表安装与守护进程启动都位于清理保护范围内。只有所固定版本的准确英文“不存在任务表”诊断才被接受为不存在；权限或命令错误会中止。工作进程先完整写入临时 JSON，再在同一目录替换发布每条事件。清理先撤销正向运行许可，再移除计划并停止所拥有的守护进程，最多等待五秒取得工作生命周期锁并核对完成记录。各项清理独立尝试并保留原始异常；前序清理失败时跳过私有文件删除，但删除本身也可能只完成一部分。这只约束已获准的工作，不证明每个 cron 包装进程或延迟启动进程都已退出，也不证明隔离或崩溃持久性。

from pathlib import Path
from tempfile import mkdtemp
import fcntl
import json
import os
import shutil
import subprocess
import sys
import time


def command(arguments, **options):
 return subprocess.run(arguments, capture_output=True, text=True, timeout=5,
 env={**os.environ, 'LC_ALL': 'C'}, **options)


def table_absent(result):
 # Debian cron 3.0pl1-162: other listing failures must abort.
 return (result.returncode == 1 and result.stdout == ''
 and result.stderr == 'no crontab for root\n')


def remove_table():
 current = command(['crontab', '-l'])
 if table_absent(current):
 return
 current.check_returncode()
 command(['crontab', '-r']).check_returncode()
 if not table_absent(command(['crontab', '-l'])):
 raise RuntimeError('could not verify table removal')


def attempt(errors, name, operation):
 try:
 operation()
 except Exception as error:
 errors.append(f'{name}: {error!r}')


def stop_daemon(daemon, errors):
 if daemon is None:
 return
 attempt(errors, 'terminate cron', daemon.terminate)
 try:
 daemon.wait(timeout=5)
 except subprocess.TimeoutExpired:
 attempt(errors, 'kill owned cron', daemon.kill)
 attempt(errors, 'reap cron', lambda: daemon.wait(timeout=5))
 except Exception as error:
 errors.append(f'wait cron: {error!r}')


def read_events(root):
 return sorted((json.loads(path.read_text()) for path in root.glob('*.json')),
 key=lambda event: event['monotonic'])


def wait_workers(root):
 # Workers hold a shared lifetime lock before checking the run permit or publishing.
 with (root / 'lifetime.lock').open() as gate:
 deadline = time.monotonic() + 5
 while True:
 try:
 fcntl.flock(gate, fcntl.LOCK_EX | fcntl.LOCK_NB)
 break
 except BlockingIOError:
 if time.monotonic() >= deadline:
 raise TimeoutError('workers did not release lifetime lock')
 time.sleep(0.1)
 events = read_events(root)
 started = {e['pid'] for e in events if e['event'] == 'start'}
 ended = {e['pid'] for e in events if e['event'] == 'end'}
 if not started <= ended:
 raise RuntimeError('a started worker has no completion record')


worker_source = r'''from pathlib import Path
import fcntl,json,os,sys,time
root=Path(__file__).parent
kind=sys.argv[1]
def record(event):
 destination=root/f'{os.getpid()}-{event}.json'
 temporary=destination.with_suffix('.tmp')
 temporary.write_text(json.dumps({'event':event,'kind':kind,
 'pid':os.getpid(),'monotonic':time.monotonic()}))
 temporary.replace(destination)
def main():
 with (root/'lifetime.lock').open() as gate:
 fcntl.flock(gate,fcntl.LOCK_SH)
 if not (root/'run-permit').exists(): return
 lock=None
 try:
 if kind=='locked':
 lock=open(root/'job.lock','a')
 try: fcntl.flock(lock,fcntl.LOCK_EX|fcntl.LOCK_NB)
 except BlockingIOError:
 record('skip')
 return
 record('start')
 try:
 until=time.monotonic()+70
 while time.monotonic()<until and (root/'run-permit').exists():
 time.sleep(0.1)
 finally: record('end')
 finally:
 if lock is not None: lock.close()
main()
'''


def main():
 # This flag is an operator prerequisite, NOT evidence of containment.
 if sys.argv[1:] != ['--isolated-disposable-lab']:
 raise SystemExit('requires a separately verified disposable Debian 12 lab')
 if os.geteuid() != 0:
 raise RuntimeError('root is required, but does not prove isolation')
 probe = command(['pgrep', '-x', 'cron'])
 if probe.returncode != 1 or probe.stdout or probe.stderr:
 raise RuntimeError(f'cron absence not established: {probe!r}')
 if not table_absent(command(['crontab', '-l'])):
 raise RuntimeError('expected absent root table; existing table or listing error')
 root = Path(mkdtemp(prefix='cron-overlap-', dir='/tmp'))
 daemon = None
 table_attempted = False
 try:
 (root / 'lifetime.lock').touch()
 (root / 'run-permit').touch()
 worker = root / 'worker.py'
 worker.write_text(worker_source)
 table = 'MAILTO=""\n' + ''.join(f'* * * * * /usr/bin/python3 {worker} {kind} >>{root}/worker.log 2>&1\n'
 for kind in ('plain', 'locked'))
 table_attempted = True
 command(['crontab', '-'], input=table).check_returncode()
 daemon = subprocess.Popen(['cron', '-f'], stdout=subprocess.DEVNULL,
 stderr=subprocess.DEVNULL)
 deadline = time.monotonic() + 140
 while time.monotonic() < deadline:
 if daemon.poll() is not None:
 raise RuntimeError('cron exited')
 events = read_events(root)
 plain = [e for e in events if (e['kind'], e['event']) == ('plain', 'start')]
 locked = [e for e in events if (e['kind'], e['event']) == ('locked', 'start')]
 skipped = [e for e in events if (e['kind'], e['event']) == ('locked', 'skip')]
 if len(plain) >= 2 and skipped:
 break
 time.sleep(0.2)
 else:
 raise AssertionError('two real cron ticks were not observed')
 assert len(plain) == 2 and len(locked) == 1 and len(skipped) == 1
 assert plain[1]['monotonic'] - plain[0]['monotonic'] < 70
 assert not any(e['event'] == 'end' and e['pid'] == plain[0]['pid'] for e in events)
 print(json.dumps({'actual_cron_starts': len(plain), 'overlap_observed': True,
 'seconds_between_starts': round(plain[1]['monotonic']-plain[0]['monotonic'], 3),
 'locked_starts': len(locked), 'locked_skips': len(skipped)}), flush=True)
 finally:
 original = sys.exc_info()[1]
 errors = []
 attempt(errors, 'revoke run permit', lambda: (root / 'run-permit').unlink(missing_ok=True))
 if table_attempted:
 attempt(errors, 'remove root table', remove_table)
 stop_daemon(daemon, errors)
 attempt(errors, 'wait for workers', lambda: wait_workers(root))
 # Retain private files after failed cleanup; discard the whole lab.
 if not errors:
 attempt(errors, 'remove private files', lambda: shutil.rmtree(root))
 if errors:
 message = 'cleanup incomplete; discard lab: ' + '; '.join(errors)
 if original is not None:
 original.add_note(message)
 else:
 raise RuntimeError(message)


if __name__ == '__main__':
 main()

两条每分钟执行的记录会运行原本持续七十秒的工作进程。plain 分支没有工作互斥锁，两分支只共享用于清理的生命周期锁；locked 分支使用共享文件和非阻塞独占 flock，未取得锁时记录 skip 并退出。每个事件包含进程标识和单调时间，能够直接区分不同实例，并检查第二次启动发生时第一次是否仍在执行，而不是仅根据配置推测并发。

原始示例的历史 Debian cron 3.0pl1-162 运行中，普通分支相隔 60.003 秒启动两次，而且第二次启动时第一次尚未结束。加锁分支只真正启动一次，另一次记录跳过。原始运行报告断言通过，并通过停止文件进行清理。本次修订改为撤销正向许可，尚未复现这些实际运行结果，也不能声称所有后台进程均已退出。

这个实验验证本机的重叠执行与显式互斥，没有实现持久重试、分布式锁、重启后恢复或业务效果恰好一次。真实任务需要这些能力时，应按当前业务契约选择并验证相应机制，不能认为日历表达式已经隐含提供了全部保障。

来源

Debian 12: crontab(5)，日历字段、步进及两个日期字段的组合，已核验 2026-09-13。
Debian 12: cron(8)，守护进程执行、日志和时钟变化处理，已核验 2026-09-13。
Linux: flock(2)，建议锁及非阻塞获取，已核验 2026-09-13。
Python 3.11 subprocess，超时与子进程清理语义，已核验 2026-10-19。
Debian cron 3.0pl1-162 crontab.c，区分不存在任务表的诊断与其他失败，已核验 2026-10-19。
Python 3.11 os.replace，同文件系统原子发布，已核验 2026-10-19。

Linux · XB 现场笔记

LVM 快照在时间上定格一块块设备

异常存储，不是副本

耗尽即失效

合并回滚，以及 thin 如何改变失败形态

坏掉的样子

快速验证

来源

SYN backlog 保存未完成握手的请求

backlog 参数管的是 accept 队列

SYN cookies 仍然只是兜底

压力真正落在 accept 队列上

坏掉的样子

快速验证

来源

iotop 能看出是哪个进程在烧磁盘

逐个进程的计数器

看到谁在扫盘

先看再动

坏掉的样子

快速验证

延伸阅读

来源

网络命名空间隔离网络资源，名称并不拥有其中所有进程

坏掉的样子

快速验证

分开管理名称、进程归属与通信配置

来源

strace 解释选定的系统调用边界

坏掉的样子

快速验证

沿假设追踪到真实结果

延伸阅读

来源

Cron 系统任务表与用户任务表有不同契约

账号列改变了解析边界

坏掉的样子

快速验证

来源

Shell 的字段拆分把未加引号的变量拆成多个参数

是否分词取决于上下文

坏掉的样子

快速验证

来源

巨型页在分配灵活性与翻译覆盖之间取舍

页大小是一项输入

显式池与透明分配

分别预算容量与位置

坏掉的样子

快速验证

延伸阅读

来源

Linux overcommit 为虚拟内存承诺设定政策

虚拟承诺不同于实际驻留

三种准入政策

严格记账不是 OOM 免疫

坏掉的样子

快速验证

延伸阅读

来源

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

坏掉的样子

快速验证

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

延伸阅读

来源

systemd oneshot 完成的是一次激活

坏掉的样子

快速验证

任务自身仍要保证正确性

延伸阅读

来源

veth 对在两个端点之间搬运帧，路由决定这些帧承载的路径

坏掉的样子

快速验证

按层次检查实际路径

来源

缺页并不总是意味着存储读取

次缺页不代表没有成本

主缺页描述另一条处理路径