Linux · XB 现场笔记

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

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

LVM 快照既不是拷贝，也不是 reflink：它是一个挂在源逻辑卷上的、大小固定的写时复制异常存储。lvcreate -s -L 5G -n snap vg/data 从卷组里划走 5 GiB，之后 device-mapper 的 snapshot 目标会在某个源 chunk 第一次被写时，把它的原始内容记录下来。无论源卷多大，创建都是瞬时的，因为创建时什么都没复制。

这个大小就是你全部的安全余量，也正是最常被写错的参数。按“一周内没什么写入”配的存储，会被一次数据库 checkpoint 或一次 rsync 在一小时内吃光；而它填满时快照不会降级，而是直接失效并开始返回 I/O 错误。恢复点恰好在你最需要它的那一刻消失，所以存储的剩余空间该进监控面板，而不是躺在 runbook 里。

异常存储，不是副本

一个经典的 LVM 快照用到两个 device-mapper 目标：源卷被重新映射为 snapshot-origin，另有一个新的 snapshot 设备把它与 COW 设备组合起来。读未改动的 chunk 直接落到源卷；某个 chunk 第一次被写时，旧 chunk 被复制进 COW 设备，然后新数据才写下去。所以消耗量跟“发生过改动的不同 chunk 数”成正比，而不是跟写入次数成正比：fixture 往 16 个热 chunk 写了一百万次，只消耗 15 个异常，约 60 KiB。

用 lvs -a -o lv_name,lv_attr,origin,data_percent,lv_size 观察它。经典快照的 lv_attr 是 swi-a-s---：s 表示快照、w 表示可写，而状态位在存储耗尽时会变成 I。data_percent 是存储的填充度，这才是该告警的数字，阈值取 70% 或 80%；100% 不是警告，是讣告。--chunksize 决定异常存储的粒度：粒度越大，块映射表的元数据越省，但每一次改动要拷贝的旧数据也越多。快照还有效时可以用 lvextend 扩容 COW 设备；lvchange --monitor y 则让 dmeventd 自动做这件事。

耗尽即失效

内核文档说得很直白：COW 设备往往比源卷小，一旦填满，快照就变得无用并被禁用，开始返回错误。LVM 给出的容量经验是按预期写入量规划——常常取源卷的 20%——并在填满之前扩容。另外，存储里有一小块要用来存放 COW 块映射表，所以可用于数据的容量略小于 -L 的数值。

影响范围很窄，但时机很残忍：源卷照常运行，所以在读取该快照的备份任务失败之前，或者在你要用的那次回滚已经不可用之前，看不出任何异常。它没有中间状态：到了 100%，正确的心理模型是这份快照从未存在过。

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

lvconvert --merge vg/snap 把快照中改动过的 chunk 合并回源卷，合并在后台进行，期间源卷仍然可用——对尚未合并的 chunk 的写入会被推迟。约束在源卷一侧：建立合并时它必须处于非活动状态，所以要么先卸载，要么先安排合并、之后再激活源卷。合并只对持久化快照有效，临时快照走不了这条路；合并会消耗掉这份快照，所以需要的东西先拷出来。

thin 快照改变的是失败形态，而不是消除失败。当源是 thin LV 且不给大小时，创建出来的就是 thin 快照；它共享 thin 池里的块，而不拥有自己的存储，所以它自身的分岔无法让它失效。此时共享资源变成了池：池一旦耗尽，坏掉的不是一份快照，而是池里所有 thin 卷，而 LVM 明确警告池可能因此损坏、且难以甚至无法修复。thin_pool_autoextend_threshold 与 dmeventd 的存在，正是因为池耗尽是一次池级事故。

坏掉的样子

最经典的是“备份悄悄不再是备份”。任务挂载快照开始拷贝，拷贝耗时超过了存储能覆盖的时长，存储在某刻到达 100%；快照随即失效，拷贝失败——更糟的情况是，监控只看任务的退出码，而任务读的早就是一个过期的挂载点。所以要盯每一个快照 LV 的 data_percent，70% 就告警，并且按保留窗口内最忙的那一小时来定容量，而不是按平均值。

第二种是“要用的时候合并不了”。lvconvert --merge 要求源卷处于关闭状态，而团队往往是在事故当中才发现这一点。合并开始后由 snapshot-merge 目标接管源卷，dmsetup status 里的已分配扇区数会持续下降，降到只剩元数据就表示合并完成。先在一个一次性卷上演练合并，另留一份不依赖快照的真实备份，并记住：存储已满的快照根本无法合并。

快速验证

在信任这份快照之前，先看存储的填充度：

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_percent 就是 COW 存储的填充度，健康的快照应当远低于 100；lv_attr 里出现状态位 I 说明快照已经失效。对 thin 快照而言，该看的是池上的 data_percent 与 metadata_percent；dmsetup status 会给出已分配扇区与总扇区之比，可以据此实时观察一次合并把扇区数排空的过程。

来源

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。

TCP backlog 收纳还在握手中的连接

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

一个监听中的 TCP 套接字有两个队列，不是一个；而本文标题里那个 sysctl 管的，恰恰是几乎从不丢东西的那一个。传给 listen(2) 的 backlog 是 accept 队列，装的是已经完成握手、正等应用来取走的连接；SYN 队列装的才是半开请求。把两者混为一谈，就会开错药方。

这件事值得掰开，因为那句著名的建议——把 tcp_max_syn_backlog 调大——基本已经过时。tcp_syncookies 默认就是 1，而按 listen(2) 的说法，一旦启用 syncookies，SYN 队列就没有逻辑上的长度上限，这个设置会被忽略。真正会卡住你的是 accept 队列，以及应用调用 accept() 的速度。

backlog 参数管的是 accept 队列

listen(2) 明确写着，这个行为在 Linux 2.2 就变了：backlog 现在指的是「已完成建立、正等待被 accept 的套接字队列长度」，而不是半开请求的数量。半开队列由 /proc/sys/net/ipv4/tcp_max_syn_backlog 单独限制。而如果 backlog 参数超过 /proc/sys/net/core/somaxconn，它会被静默截断到那个值——Linux 5.4 之后是 4096，之前是 128。所以在默认配置的机器上写 listen(8192)，实际拿到的是 4096，而且不会有任何日志告诉你。

tcp(7) 把 tcp_max_syn_backlog 描述为「尚未收到对端确认的排队连接请求上限」：默认 256，内存达到 128 MB 及以上时升到 1024，低于 32 MB 时降到 128。ip-sysctl 补上了真正重要的限定：它是 per-listener 的限制，每个半开请求套接字大约占 304 字节，而 tcp_syncookies 默认为 1——队列溢出时发一个 cookie，而不是把请求丢掉。

syncookies 开着的时候，SYN 队列就不再是瓶颈

ip-sysctl 把 tcp_syncookies 记录为一种兜底手段，并明确说不能用它去帮一台高负载服务器扛合法的连接吞吐；它还指出 syncookies 严重违反 TCP 协议、无法使用 TCP 扩展，并可能让某些服务明显劣化。listen(2) 更进一步：启用 syncookies 时没有逻辑上的长度上限，tcp_max_syn_backlog 被忽略。而 tcp(7) 仍然把同一个旋钮描述为「超过就开始丢弃请求」——那是 syncookies 关掉时的行为。两页手册各自都说对了，只是说的是不同配置。另外 ip-sysctl 注明，syncookies 只在编译时启用了 CONFIG_SYN_COOKIES 的内核上有效，所以它并不是一个必然存在的兜底。

所以诚实的结论是：让 syncookies 保持 1，别再折腾 SYN 队列。代价是这条兜底路径救回来的连接会失去窗口缩放、SACK 这类 TCP 扩展，属于吞吐问题而不是连通性问题。如果你在合法流量下看到 SYN flood 告警，ip-sysctl 自己的建议是去调别的旋钮，而不是关掉 syncookies。

压力真正落在 accept 队列上

SYN 队列被中和之后，会满的是 accept 队列，它的容量是 min(listen(backlog), somaxconn)。溢出时的行为取决于 tcp_abort_on_overflow，默认是 FALSE：ip-sysctl 说默认值意味着「如果溢出只是突发造成的，连接会恢复」，并警告打开这个开关会伤害你的客户端。机制才是意外之处：默认情况下内核会静默丢弃最后一个 ACK，于是客户端的 connect() 成功返回，故障要等到第一个请求卡住或被重置时才浮现。之所以说默认值「能恢复」，是因为服务端随后还会按自己的节奏重传 SYN-ACK：只要在它放弃之前队列里腾出位置，这条连接就能被救回来。这也正是它无声的原因——客户端那边从头到尾都认为自己已经连上了。

更大的 backlog 是延迟线，不是容量。在模型里，listen(128) 和 listen(65535) 一秒内 accept 的连接数完全一样，都是 20,000；更大的队列只是把溢出的时刻往后推，因为 accept 速率由 worker 数量决定。

坏掉的样子

第一种故障是无声的那种，而且它就是默认行为。accept 循环太慢的服务会把 accept 队列挤满，内核丢掉最后的 ACK，客户端看到的是「连接建立了，然后就挂着」。没有任何东西被拒绝，于是客户端的连接池里堆满死套接字，报错最终出现在一个看起来无关的层面。盯住 TcpExtListenOverflows 和 TcpExtListenDrops：这两个计数器上涨而 accept 速率平稳，说明瓶颈在处理线程。

第二种故障是被丢弃的 SYN，只有在 syncookies 关掉时才会发生。SYN 队列满了就丢请求，客户端按重传时间表重试，文档给出的两个端点是「最后一次重传到 67 秒、最终超时到 131 秒」，所以用户看到的现象是一次挂了两分多钟才失败的连接。在这种配置下调大 tcp_max_syn_backlog 是真正的修法，而把 syncookies 重新打开是更好的修法——前提是你接受 TCP 扩展的损失。

快速验证

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

在 ss -lnt 里，Send-Q 是这个套接字创建时的 backlog，Recv-Q 是已经建立但还没被 accept 的连接数；Recv-Q 顶到 Send-Q 就是队列满了。nstat 的几个计数器应该为零或接近零：TcpExtListenOverflows 和 TcpExtListenDrops 属于 accept 队列事件，TcpExtTCPReqQFullDrop 是被丢掉的 SYN，TcpExtTCPReqQFullDoCookies 则是兜底机制在正常工作。sysctl 那一行显示内核真正会认的数字——如果 somaxconn 比你的 listen() 参数小，那么那个更小的值才是你真实的 backlog。

来源

内核 ip-sysctl 文档，somaxconn、tcp_max_syn_backlog、tcp_abort_on_overflow 以及 syncookies 的警告，已核验 2026-09-16。
Linux listen(2)，Linux 2.2 起的 accept 队列、somaxconn 的静默截断，以及 syncookies 如何取消 SYN 队列上限，已核验 2026-09-16。
Linux tcp(7)，tcp_max_syn_backlog 按内存大小的默认值，以及 syncookies 的注意事项，已核验 2026-09-16。

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

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

磁盘突然飙升却找不到明显的写入者时，iotop 把吞吐直接指回那个在捣乱的进程。系统级工具只给症状——await 高、util 打满——不给嫌疑人：五十个进程共享磁盘，平均值平等地怪每一个。终结调查的永远是按进程的问题——谁、多少、何时开始——iotop 从内核计数器实时回答，应用藏都没处藏。

把它放在系统级视图旁边，而不是代替。iostat 或 vmstat 说磁盘是瓶颈，iotop 点名是谁造成的。两者合起来把存储悬案压成两条命令：确认资源，锁定消费者。

逐个进程的计数器

iotop 从内核读每个进程的 IO，于是实时读写速率能对应到一个 pid，而不是一个说不清来源的负载均值。加 -o 只显示真正在做 IO 的进程，一眼看清。默认视图读写分开，还带 swap-in 百分比，把真吃磁盘的和仅仅在场的分开——DISK READ 高、写零的是在扫，写高的在产； throttle、迁移还是杀，取决于这个区分。

注意计数器量的到底是什么：穿过 IO 层的按进程字节，含还没落盘的缓冲写。进程写速率巨大、磁盘看着却闲（页缓存吸收），或速率平平、磁盘打满（大量小同步写），都可能。iotop 跟设备 util 一起读：进程侧定罪加设备侧饱和才是完整画面，任一半单独都误导。

看到谁在扫盘

按带宽排序，那个罪魁就现形了，无论是日志囤积、索引器还是失控备份。跟住这个 pid，就能定位到确切的进程（往往还有文件），再动手不迟。惯犯名单：debug 级别没轮转的日志、排在高峰的重建索引、同盘读写备份、坏镜像上循环解包的容器层。修法各不同——轮转、改期、分开、清理——杀进程治标，病因明天定时再来。

动手前把 pid 解析到完整上下文：命令行、工作目录、lsof 看开文件、父进程。一个烧写的 java 进程背后可能是一个 PID 命名空间里的十个应用；修要修对那一个。先定罪后动手——每个以遗憾收场的存储 war story 都跳过了第一步。

先看再动

iotop 只观察、不改变任何东西，所以你可以在决定节制、迁移或停掉之前先把元凶查清楚。再配 strace 或 lsof 打到这个 pid，把文件和系统调用一并钉死。组合是决定性的：iotop 说 18412 进程写 400MB/s，lsof 说写进一个膨胀的日志文件，strace 显示 4KB 的 O_APPEND 写——诊断完毕；修法（日志级别、轮转、异步 appender）不言自明，不用开会争。

健康时录基线，故障时对比才有意义。平时某天 iotop -b -n 60 落文件五分钟，就是这台机器的"正常"数字：平时谁领跑、多少速率算寻常。没有它，每次 spike 都像史无前例；有了它，多数 incident 几秒归类：“又是 indexer，提前一小时”。把 iotop 批输出和系统监控同一时段的曲线放一起看，进程侧和设备侧互相印证，结论才站得住。单看任何一边，都可能把相关当因果。告警阈值按基线设，而不是拍脑袋，基线之外的 spike 才值得半夜起床。把 Top 写入者的变化趋势也画出来，渐变比突变更早暴露问题。

基线文件要标清楚采集条件：采集时段、业务负载水位、iotop 的采样间隔与累计方式，否则下次对比就是拿苹果比橙子。建议每周固定一个低峰窗口复采一次，覆盖掉业务自然增长带来的漂移；复采后把新旧两份排名并排 diff，只看名次变化超过三位的进程，逐个确认是业务上线还是异常冒头，再决定跟进还是放行。确认结论也要回写基线备注。

坏掉的样子

最经典的元故障是权限盲：没特权跑，iotop 进程细节全问号，别用户的进程直接不显示——而真凶恰跑在别用户下，隐形到底。一开始就带够特权（root 或对应 capabilities），不然工具开脱的恰是你看不见的进程。无特权 iotop “什么都没查到”，只代表你自己的进程没事。

第二种是突发 IO 的采样幻觉：一分钟暴力一秒的进程，5 秒平均看着无辜，1 秒平均看着有罪，反之亦然。数字和症状对不上就换 delay 档；“过去一小时谁伤的盘"问累计总量（-a）不问瞬时速率。聚合方式对，问题才对；默认聚合只答它自己假设的那个问题。

快速验证

非交互地抓谁在做 IO，带上下文：

iotop -b -n 5 -o -d 2 | head -n 30
pid=$(iotop -b -n 1 -o | awk 'NR>5 {print $1}' | head -n 1); ls -l /proc/$pid/exe; cat /proc/$pid/cmdline | tr '\0' ' '
iostat -x 1 3 | grep -E "Device|sd|nvme"

batch 抓排名不占终端，pid 解析点名头号写者的二进制，iostat 确认设备侧真打满。

来源

iotop 手册，iotop 官方参考，已核验 2026-06-01。
vmstat 手册，说明系统级 CPU 与 IO 等待报告，已核验 2026-09-05。

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

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 后运行 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，或者退出前最后一次不成功调用，都不能替代理解应用控制流程。真正需要回答的是，这个返回值如何影响正在调查的操作。相同错误名在不同分支里，可能分别代表正常探测和不可继续的条件。

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

快速验证

把脚本保存为 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 对命令起点的理解就会变化。排查看似正确的五字段日历表达式之前，应先确认正在编辑的到底是哪种任务表，而不是只检查分钟和小时。

账号列改变了解析边界

传统用户记录依次填写分钟、小时、月内日期、月份、星期，再接命令正文，由 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 规则转义。调度语法、命令能否执行和应用结果是否成功，必须分别检查。

快速验证

使用全新的临时 Debian 12 Docker 容器，以 root 运行，安装 python3、cron、procps 和 passwd。确认没有活动 cron 进程、已有 root 任务表，以及名为 xbtime 的账号。将代码保存为 cron-tables.py，执行 python3 cron-tables.py。它只创建实验账号、任务文件和临时目录，最多等待七十五秒经过一个真实计划分钟，结束后会清理这些资源。

from pathlib import Path
from tempfile import TemporaryDirectory
import json
import os
import pwd
import shutil
import subprocess
import time

assert os.geteuid() == 0 and Path('/.dockerenv').exists(), 'use a disposable root Linux container'
assert subprocess.run(['pgrep', '-x', 'cron'], capture_output=True).returncode == 1
assert subprocess.run(['crontab', '-l'], capture_output=True).returncode != 0
assert shutil.which('root') is None
username = 'xbtime'
try:
 pwd.getpwnam(username)
except KeyError:
 pass
else:
 raise AssertionError('test account already exists')
system_table = Path('/etc/cron.d/xbcatm_time_test')
assert not system_table.exists()
subprocess.run(['useradd', '--create-home', '--shell', '/bin/sh', username], check=True)
account = pwd.getpwnam(username)
daemon = None
try:
 with TemporaryDirectory(prefix='cron-tables-') as directory:
 root = Path(directory)
 os.chown(root, account.pw_uid, account.pw_gid)
 worker = root / 'worker.py'
 worker.write_text('''from pathlib import Path
import json,os,sys
root=Path(__file__).parent
mode=sys.argv[1]
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()
(root/(mode+'.json')).write_text(json.dumps(data))
''')
 user_table = ('SHELL=/bin/sh\nPATH=/usr/bin:/bin\nLAB_TABLE=user\n'
 f'* * * * * /usr/bin/python3 {worker} user\n'
 f'* * * * * /usr/bin/python3 {worker} percent%first%second\n'
 f'* * * * * root /usr/bin/id >{root}/wrong-column.err 2>&1\n')
 subprocess.run(['crontab', '-'], input=user_table, text=True, check=True)
 invalid = subprocess.run(['crontab', '-'], input='* * * * * /bin/true',
 text=True, capture_output=True)
 assert invalid.returncode != 0
 assert subprocess.check_output(['crontab', '-l'], text=True) == user_table
 system_table.write_text('SHELL=/bin/sh\nPATH=/usr/bin:/bin\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)
 try:
 deadline = time.monotonic() + 75
 names = ['user.json', 'system.json', 'percent.json', 'wrong-column.err']
 while time.monotonic() < deadline:
 assert daemon.poll() is None
 if all((root/name).exists() and (root/name).stat().st_size 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 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:
 daemon.terminate()
 daemon.communicate(timeout=5)
 daemon = None
finally:
 if daemon is not None:
 daemon.terminate()
 daemon.communicate(timeout=5)
 system_table.unlink(missing_ok=True)
 subprocess.run(['crontab', '-r'], capture_output=True)
 subprocess.run(['userdel', '--remove', username], capture_output=True, check=True)

用户表任务实际以 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。

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

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

变量保存的是一个字符串，但没有引号的展开可能把它变成多个命令参数。Bash 的分词阶段使用 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。

巨型页用灵活性换更少的 TLB 缺失

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

数据库及高吞吐服务往往因此受益，但要背负需要连续内存、池子要预先算好大小的成本——这是一笔架构账，不是免费的。

为什么 4 KB 会吃亏

默认页是 4 KiB,TLB 能容纳的条目又很有限。管理百万级工作集的大型应用,很容易在访问一个页面时就 miss 掉一个 TLB 表项,于是不得不到页表里去翻。这里的成本不是页本身,而是反复的页表遍历;一旦工作集的错杀超过 TLB 回填的速度,大应用就会明显吃到痛。更大的页让每条表项覆盖更多内存,同样大小的工作集约只需要很少的表项,这正是吃内存沉重的负载最需要的缓解。

hugetlb 与 THP 的区别

想要大页有两条路。hugetlb 让你从一块预留的内存里自己分配,页的大小是确定的(常见 2 MiB 或更大),行为可预期、由你掌控;transparent(THP)则在后台自动把映射整合成大页,省心,却可能在某些负载上带来延迟尖峰、碎片与写时复制的问题。对延迟敏感的业务,hugetlb 让你自己抱住那份池和那份 trade-off,而不是把决定权丢给一个你不知道用不用得着的通用策略。选哪条路,其实是在决定「可预测性由谁掌握」——你,还是内核。

池子要提前量

大页的真正收益,建立在它被真用满、并且真的常驻内存的前提上。一页 2 MiB 若只用了很小一部分,却仍占着一个整页表项,被锁住的那块内存就等同于浪费,而池子到底定多大,才是真正的功夫。给池子只留那份最诚实、最稳定使用的内存,而不是凭感觉很轻率地划一大块,并要为「稀疏大页」附带的多占 RAM 留出余量。当这些都成立——页被用满、工作集收得小、居住集成一两个表项——大页的收益才完整兑现;要是把它喂给几乎填不满的负载,那就只是一笔平白消耗。

坏掉的样子

池子给小了，失败多在启动瞬间。数据库要的共享缓冲超过预留大页能覆盖的范围，进程会直接退出，常见报错是无法分配内存；此时系统空闲内存可能还很充足，容易误判。关键是显式大页不能自动回退到小页，缺几页就是缺几页。做法是按应用文档的需求加少量余量定池子，重启后核对总页数与已预留数，而不是只看启动参数。

启动正常、运行中分配失败，多半是碎片。大页要求物理连续的整块区间，机器跑久之后，空闲总量充足，却拼不出完整区间，新映射会被拒绝。典型信号是空闲大页数停在大于零不再下降，同时内核日志出现大页分配失败；此时重试映射没有意义，应回到启动阶段预留或用启动参数固定池子。

更隐蔽的是位置放错与自动整理。池子落在远端节点上，每次命中都要跨互联访问，省下的表项优势会被延迟吃掉，绑定前要先看分节点分布。透明大页则是另一种风险：后台整理与写时复制拆分会把平稳的尾延迟打成尖峰，从合并等待与整理线程占用能看到痕迹。延迟敏感服务建议设为按需启用，只在实测有效的地方打开。

快速验证

下面脚本只读内存信息与系统页大小，不做任何分配，也不需要特权，因此在无特权容器里同样可直接运行。若环境没有内存信息文件或不支持大页，它会打印跳过提示并继续给出页表项换算，而不是抛异常退出。

把下面代码保存为大页检查脚本并运行，即可看到本机覆盖率与固定工作集的表项对比。脚本先解析总页数、空闲数、已预留数、溢出数与单页大小，算出预留覆盖总量；再用系统调用得到的基准页大小，对比同样工作集在基准页与大页下各需多少表项，估算省下的数量。

#!/usr/bin/env python3
"""Report hugepage coverage and estimated TLB entries saved (read-only)."""
import os
import re
from pathlib import Path

WORKING_SET_BYTES = 8 * 1024**3 # 8 GiB example working set

def parse_meminfo(text):
 vals = {}
 for key in ("HugePages_Total", "HugePages_Free", "HugePages_Rsvd",
 "HugePages_Surp", "Hugepagesize"):
 m = re.search(r"^" + key + r":\s+(\d+)", text, re.M)
 if m:
 vals[key] = int(m.group(1))
 return vals

def main():
 vals = {}
 try:
 text = Path("/proc/meminfo").read_text(encoding="utf-8")
 except OSError as exc:
 print(f"SKIP: /proc/meminfo unavailable ({exc}); showing page-table math only")
 text = ""
 if text:
 try:
 vals = parse_meminfo(text)
 if "HugePages_Total" not in vals or "Hugepagesize" not in vals:
 print("SKIP: no HugePages fields in /proc/meminfo (hugepages unsupported or disabled)")
 else:
 size_kb = vals["Hugepagesize"]
 total = vals["HugePages_Total"]
 free = vals.get("HugePages_Free", 0)
 rsvd = vals.get("HugePages_Rsvd", 0)
 surp = vals.get("HugePages_Surp", 0)
 cov_mb = total * size_kb / 1024
 print(f"Hugepagesize: {size_kb} kB")
 print(f"HugePages total/free/rsvd/surp: {total}/{free}/{rsvd}/{surp}")
 print(f"Reserved coverage: {cov_mb:.1f} MiB ({cov_mb/1024:.2f} GiB)")
 except Exception as exc:
 print(f"SKIP: failed to parse /proc/meminfo ({exc})")
 try:
 base = os.sysconf("SC_PAGE_SIZE")
 except (AttributeError, ValueError, OSError):
 base = 4096
 huge = vals.get("Hugepagesize", 2048) * 1024
 base_entries = WORKING_SET_BYTES // base
 huge_entries = WORKING_SET_BYTES // huge
 print(f"Base page size (sysconf): {base} bytes")
 print(f"8 GiB needs ~{base_entries} base-page entries vs ~{huge_entries} huge-page entries")
 print(f"Estimated TLB entries saved: ~{base_entries - huge_entries}")

if __name__ == "__main__":
 main()

在支持大页的系统上，预期能看到单页大小、各类计数与预留覆盖容量，以及两种粒度各自的表项数和节省量；在笔记本或极简容器里，则先看到一行跳过提示，再看到同样的表项换算，且本地基准页可能不是常见的四千字节。该脚本已在缺少内存信息文件的环境验证通过。它只衡量预留量与潜在节省，不能证明真实缺失下降、碎片或节点距离，调池子前还要用内核日志、分节点计数与延迟分位交叉确认。

来源

内核巨型页文档，定义 hugetlb 设置与行为，已核验 2026-06-01。
内核透明巨型页文档，定义 THP 模式与后台整理行为，已核验 2026-06-01。

Linux 的 overcommit 是内核的一场豪赌

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

调整 vm.overcommit_memory，把从内核盲目乐观里让出的那部分判断交回你自己的预算，最终决定谁在 OOM 时被牺牲。

为什么 malloc 很少失败

vm.overcommit_memory 默认为 0,处在启发式模式:它几乎对每一个 mmap 和 malloc 都说好,只要系统还大概承担得起;只有当内存真正吃紧时才拒绝。因为虚拟内存的承诺本身几乎零成本,可容纳的页又是点到即给,所以绝大多数分配都会成功,普通进程以近乎免费的方式活得好好的。这份慷慨的代价是内核可以超卖远多于物理内存。它赌你不会真正写满每一页;一旦太多字节真的落到内存里,总有人要用一次 OOM kill 来买单。

那个开关

vm.overcommit_memory 让你选择由谁来拿预算。默认 0 是启发式超卖:内核只拒绝那些明显不可能兑现的请求,其余几乎照单全收,赌的是多数进程永远不会触碰自己申请的每一个字节。设为 1 表示总是允许超卖:内核几乎不再设防,适合那些映射巨大但大多保持稀疏、长期不触碰的程序,代价是所有失败都被推迟到回收路径或杀手裁决那一刻。设为 2 则是严格记账:凡是超出 CommitLimit 的申请都会在调用当场以内存不足失败,这个上限大致等于交换空间加上物理内存乘以 overcommit_ratio 的比例,当 overcommit_kbytes 非零时以后者为准。两种极端都不免费:总是超卖会把压力藏到整机停顿才爆发,严格记账则会让那些申请慷慨但实际触碰很少的程序直接启动失败,应当按你想控制的风险来选。

启发式对严格上限

当账最终要平的那天到来,真正的问题是谁来买单。启发式模式下,内核会继续超卖,并在内存压力下随机挑一个牺牲品;严格模式下,边界事先画好,失败在 malloc 这一步就浮出水面,由运维而不是调度器决定哪个进程去吞这枚 OOM kill。容器与虚拟机通常会把它调成受控值:一台代表许多 guest 一起超卖的主机,在需求同时冲高时可能把自己的底盘一起压垮。笔记本可以大方一点;而一台绝对不能悄悄丢掉某个工作进程的产线上,就应当把选择说得明明白白。

坏掉的样子

在默认启发式模式下,最让人困惑的故障是:一次巨大的 malloc 或 mmap 明明返回成功,进程却在稍后被杀掉。申请瞬间还没有触碰任何页面,看起来一切正常;等进程真正写入这些页面、内存开始吃紧,内核杀手就会挑选一个牺牲品,而它往往不是当初超额申请的那个,而是旁边体积最大的进程。日志里只剩一句内存不足杀进程,却找不到任何一次分配失败,排查很容易追错二进制文件,真正的超卖源头反而藏在身后。

1 即总是超卖模式,坏得更慢也更彻底。离谱的预留都会被照单全收,压力在暗处悄悄累积,带交换分区的机器会滑向交换风暴:每个进程理论上都活着,但整个系统不再推进任何有效工作。延迟先于回收彻底崩塌,交互式会话卡死,最后的杀手裁决看起来完全随机,因为太多进程手里都拿着系统根本无法同时兑现的承诺。

2 即严格记账,则在申请当场失败,方向完全相反。启动时就预留巨大堆的虚拟机,或者频繁分支、短暂需要按两倍常驻集记账的服务,即使永远不会触碰每一页,也会在启动时直接收到内存不足。把一台无交换笔记本上的严格比例照搬到数据库主机,健康的程序会拒绝启动。正确做法是观察 /proc/meminfo 里 CommitLimit 与 Committed_AS 之间的余量来调整比例,而不是盲目切换模式。

快速验证

把下面程序保存为 overcommit_probe.py,然后运行 python3 overcommit_probe.py。它只用标准库,只读打开超卖开关与内存记账文件,不做任何修改,不需要任何特权。在没有这些文件的系统上它会打印 SKIP 而不是报错退出。

"""Read-only overcommit audit: report mode, budget, and pressure."""

from pathlib import Path


def read_value(path):
 try:
 return Path(path).read_text(encoding="utf-8").strip()
 except FileNotFoundError:
 return None
 except OSError as exc:
 return "UNREADABLE: %s" % exc


def meminfo_kb(text):
 fields = {}
 for line in text.splitlines():
 name, _, rest = line.partition(":")
 digits = "".join(ch for ch in rest if ch.isdigit())
 if name and digits:
 fields[name.strip()] = int(digits)
 return fields


def main():
 mode = read_value("/proc/sys/vm/overcommit_memory")
 ratio = read_value("/proc/sys/vm/overcommit_ratio")
 kbytes = read_value("/proc/sys/vm/overcommit_kbytes")
 meminfo = read_value("/proc/meminfo")
 if mode is None or meminfo is None:
 print("SKIP: /proc/sys/vm/overcommit_memory or /proc/meminfo missing (non-Linux?)")
 return
 info = meminfo_kb(meminfo)
 print("overcommit_memory=%s overcommit_ratio=%s overcommit_kbytes=%s" % (mode, ratio, kbytes))
 print("MemTotal=%s kB SwapTotal=%s kB CommitLimit=%s kB Committed_AS=%s kB" % (
 info.get("MemTotal", "?"), info.get("SwapTotal", "?"),
 info.get("CommitLimit", "?"), info.get("Committed_AS", "?"),
 ))
 names = {"0": "heuristic", "1": "always overcommit", "2": "strict accounting"}
 print("mode means: %s" % names.get(mode, "unknown value"))
 limit = info.get("CommitLimit")
 committed = info.get("Committed_AS")
 if mode == "0":
 print("suggestion: heuristic default; watch Committed_AS growth, prefer mode 2 for workers that must not be OOM-killed")
 elif mode == "1":
 print("suggestion: always overcommit; expect swap storms under pressure, prefer 0 or 2 unless sparse mappings need it")
 elif mode == "2" and limit and committed:
 headroom = limit - committed
 print("commit headroom=%s kB; suggestion: enlarge ratio/kbytes if headroom is small, shrink them if headroom is huge" % headroom)
 else:
 print("suggestion: unexpected mode value; compare Committed_AS against CommitLimit before changing anything")


if __name__ == "__main__":
 main()

在默认工作站上,脚本通常报告启发式模式,并提示继续观察已提交量的增长;只有绝不能被意外杀掉的工作进程,才值得切换到严格记账。在严格模式下重点看余量:已提交接近上限,就能解释启动时的内存不足失败;余量巨大,则说明比例只是偏保守。在总是超卖模式下,建议信息会提醒交换风暴风险,正好对应上面先变慢再随机被杀的故障。

来源

内核 vm 参数文档，定义 overcommit_memory 各模式与默认值，已核验 2026-06-01。
proc 手册页，记录 /proc/meminfo 中 CommitLimit 与 Committed_AS 的记账含义，已核验 2026-06-01。

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

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

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

坏掉的样子

年龄不只是“创建文件多久了”，也不只是“多久没有修改内容”。文档中的默认规则考虑多个时间戳，包括访问与修改时间、文件状态变化时间，以及可获得的创建时间。某个参与判断的时间戳较新，就可能保留一个看起来 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 通常在命令完成后变为非活动状态，这是任务已经结束的正常表现，不是守护进程崩溃的证据。设置 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 端点，会移除另一个端点，即使对端由另一个命名空间管理。因此宿主侧清理动作可能删除容器接口。影响活跃工作负载时，应有意识地安排停止流量、调整路由和删除设备的顺序。命名空间分离了管理视图，却没有让成对设备变成两项互不影响的资源。

快速验证

将脚本保存为 check-veth.py，准备 Docker 后执行 python3 check-veth.py。固定 Linux 容器使用 Python 3.11.16、iproute2 6.1.0，以及用于嵌套命名空间的 NET_ADMIN 和 SYS_ADMIN。它只创建一次性虚拟设备。左右命名空间各获得一个端点，分别配置 192.0.2.1/30 和 192.0.2.2/30，没有移动现有宿主网卡：

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 和 NO-CARRIER，没有 LOWER_UP，因为 right0 仍关闭。单次 ping 失败。这里同时提供链路状态和实际失败交换，没有用“接口创建成功”来替代对端已经配置正确的证据。管理状态说明操作者希望设备工作，载波状态则反映配对链路当前能否成立。

启用 right0 后，两端都报告 LOWER_UP。脚本清理失败尝试留下的邻居条目，再进行正常状态比较，避免残留解析计时影响结果。新的 ping 成功，从左侧访问 192.0.2.2 的真实 HTTP 请求也收到右侧服务身份。清理动作明确可见，实验没有承诺所有已经等待中的应用请求都会在启用链路后瞬间恢复。

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

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

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

按层次检查实际路径

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

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

把删除视为同时影响两端的操作，并验证相关工作负载结果。如果吞吐量或延迟要求推动 MTU、队列或卸载配置调整，应测量相应路径，不能仅因链路是虚拟设备就推断性能。本实验验证成对交付、明确就绪、正确目的地路由以及关联删除，不代表完成了一整套容器网络，也不建立统一性能承诺。

来源

Linux veth(4)，成对传输、载波状态及命名空间使用，已核验 2026-09-12。
Linux ip-link(8)，veth 创建、状态、移动及删除，已核验 2026-09-12。
Linux network_namespaces(7)，网络边界与虚拟设备生命周期，已核验 2026-09-12。

缺页并不总是意味着读盘

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

把两类缺页一概当作慢磁盘看待会混淆差别；对内存大户调优时，‘次要还是主要’这个区分才是关键。

次缺页只用映射

缺页也分主次：缺页时如果页面其实已经常驻内存，只是进程还没有把这张页表映射，就只需补一张页表——把虚拟地址指到那块已存在的物理内存即可。这也解释了为什么「新开一页」这类动作是便宜的：它不过是在页表上多一条指针，不读磁盘、不耗内存。首次接触刚归零的区域、共享库被别的进程先行加载、或一次从 swap 换入还没有短缺时，走的都是这条路。缺页省下的成本几近于零，也几乎不构成性能问题。

主缺页要读磁盘

主缺页就完全不一样了。它意味着所需数据必须落地到磁盘（或从 swap 读出来），这一步通常几十到几百微秒、甚至毫秒级，比次缺页慢好几个量级。进程冷启动、首次读入大二进制、或又要从 swap 里找回被换出的页面，最常见的表现就是一大串主缺页。两者的差别，主要是「这数据是不是已经在本地」——主缺页多，说明缓存与前读没有把你要的那片东西预先备好。

分开统计才有意义

工具把一个数字拆成两个，不是没事找事，而是为了分清病因。ps、sar、/proc/self/stat 都会分别报 minor/major。一个健康的服务器应该是「次缺页常年不断、主缺页几乎为零」。看的是比例而非总数：主缺页密集、次缺页稀疏，多半是缓存未命中与冷启动；次缺页猛增却没什么主缺页，往往是在页面表上抖动，而不是磁盘紧张。把两者分开看，一旦主缺页冒头，第一反应是补缓存与预读，而不是去怪磁盘。

坏掉的样子

主缺页风暴看起来像延迟毛刺，本质却是缓存未命中。每次发布、容器重启或新节点上线后，所有工作进程会同时第一次触碰二进制、共享库和数据页。这时用 perf stat -e minor-faults,major-faults 观察，会看到主缺页从接近于零突然涨到每秒数千，而处理器利用率反而很低，尾延迟被拉长到数百毫秒。此时加核或加线程没有意义，正确做法是预热工作集、保持镜像常驻，或者错开重启节奏，避免所有进程同时挤兑同一批页面，否则毛刺会随实例数放大。

交换分区会让同样的信号产生共振。当常驻工作集超过物理内存，内核会把不常用的页换出到交换设备，下次访问又要从磁盘换回来。主缺页随换入一起上涨，负载攀升，每个请求都要替磁盘等待，即便代码一行没改。有人会加线程扛延迟，结果工作集更大，抖动更严重，甚至进入换入换出互相等待的恶性循环。此时应该先算内存账：让热数据真正装进内存，或者把冷数据搬出请求主路径，而不是提高并发。

第三类真实失败是误读 mmap 大文件顺序读。顺序扫描一个文件映射，第一次触碰每一页同样会缺页，主缺页很多并不代表随机读坏了，也不代表存储变慢。把所有缺页都当成磁盘寻道，就会去调预读或怪硬盘，真正该问的是这些页当初该不该映射进来。改输入输出参数之前，先用 mincore 确认常驻情况，再决定是预读、缓存还是改访问方式，避免把映射策略问题误判成存储故障。

快速验证

把下面程序保存为 fault_probe.py，运行 python3 fault_probe.py 即可。它只用标准库，不需要特权，在常见发行版和苹果系统上都能直接运行。程序用 resource.getrusage 读取进程的次缺页与主缺页计数，在全新匿名映射上做两轮逐页触碰，并用 time.perf_counter 记录每轮耗时，前后对比即可区分两类缺页，也能直观看出映射建立前后的时间差异。

import mmap
import resource
import time

PAGE = 4096
PAGES = 20000 # 约八十兆：足够看出差值，又不会给持续集成带来负担


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


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


def main():
 mapping = mmap.mmap(-1, PAGES * PAGE)
 base_min, base_maj = counters()
 start = time.perf_counter()
 touch(mapping)
 first_time = time.perf_counter() - start
 mid_min, mid_maj = counters()

 start = time.perf_counter()
 touch(mapping) # 此时页面已经映射好
 second_time = time.perf_counter() - start
 end_min, end_maj = counters()
 mapping.close()

 first_min = mid_min - base_min
 first_maj = mid_maj - base_maj
 second_min = end_min - mid_min
 second_maj = end_maj - mid_maj
 print(f"first touch: minflt={first_min} majflt={first_maj} time={first_time:.4f}s")
 print(f"second touch: minflt={second_min} majflt={second_maj} time={second_time:.4f}s")
 assert first_min > 1000, f"expected thousands of minor faults, got {first_min}"
 assert first_maj == 0, f"anonymous first touch should not cause majors, got {first_maj}"
 assert second_min < first_min // 10, f"mapped pages should barely fault: {second_min} vs {first_min}"
 assert second_maj == 0, f"unexpected major faults on second pass: {second_maj}"
 print("PASS: first touch faults as minors without disk reads; second touch is almost fault-free")


if __name__ == "__main__":
 main()

第一轮逐页写会触发大量次缺页，预期次缺页增加数千，主缺页几乎不变，而且耗时明显更长。第二轮访问已经映射好的页面，预期新增缺页接近于零，耗时也显著缩短。这个反差正是结论：匿名内存第一次触碰只产生次缺页，不需要读盘，第二次访问已经不需要建立映射。

上述断言已在苹果系统与常见发行版的解释器下运行通过。实验只覆盖匿名内存，不能证明文件映射的主缺页来自哪里，也不能替代线上用 perf stat -e minor-faults,major-faults 观察真实负载。如果两轮耗时差距太小，可以把映射调大再对比 time 结果，缺页差值会更加明显。

来源

Linux 手册 proc(5)，进程级次缺页与主缺页计数，已核验 2026-06-25。
Linux 手册 mmap(2)，按需分页与私有匿名映射，已核验 2026-09-12。
Brendan Gregg：perf 实例，用 perf 统计次缺页与主缺页，已核验 2026-09-12。
内核文档：内存管理概念，按需分页、页缓存与回收，已核验 2026-09-12。

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

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

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

坏掉的样子

应用必须理解激活协议。如果守护进程无条件再次绑定同一个端点，就可能因为管理器已经占用而失败。激活机制把绑定责任移到 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

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

坏掉的样子

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，保留先前的进程退出失败；启动限流的原因则出现在日志里。如果断言结果字段一定等于 start-limit-hit，反而会漏掉已经实际发生的这个情况。应结合单元状态、程序调用记录和相应日志判断，不要假定不同版本、不同失败路径都给出完全相同的单一诊断标签。

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

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

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

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

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

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

来源

systemd 252 服务重启规则，退出分类、固定等待时间和重启例外，已核验 2026-09-12。
systemd 252 单元启动限制，窗口限流、手动启动与计数清除，已核验 2026-09-12。
systemd 252 systemctl，停止、状态读取与失败状态重置，已核验 2026-09-12。

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

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

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

坏掉的样子

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

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

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

快速验证

把脚本保存为 procview.py，在一次性 Linux 环境中运行 python3 procview.py。实测使用 Linux 6.12.76 和 Python 3.11.2。脚本启动一个受控子进程，显式提供少量环境值，只读取自己及该子进程的 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-09-12。
proc_pid_stat(5)，字段布局、括号内命令名与启动时间，已核验 2026-09-12。
proc_pid_environ(5)，初始环境区域与空字符分隔条目，已核验 2026-09-12。
proc_pid_fd(5)，描述符链接、引用对象与权限检查，已核验 2026-09-12。
proc_pid_cmdline(5)，参数分隔符与受进程控制的命令行内容，已核验 2026-09-12。

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

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

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

坏掉的样子

默认命名空间通常使用 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、Python 3.11.2 和 ext4。样本创建 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-09-12。
inotify_add_watch(2)，监视注册与对象身份，已核验 2026-09-12。
Linux 6.12 inotify UAPI，可执行样本使用的事件结构和标志值，已核验 2026-09-12。

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

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

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

坏掉的样子

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

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

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

快速验证

把脚本保存为 hardlinks.py，在一次性 Linux 容器中以 root 运行 python3 hardlinks.py。它要求 /tmp 与 /run 可写、属于不同文件系统，并在执行时检查这一条件。实测使用两个独立 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='/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 记录任务启动，并提供更细的日志选项。命令输出可能在可用邮件链路存在时被投递，但极简容器经常没有这样的链路。应把启动、完成、失败和跳过结果写到明确目的地。启动记录只能证明任务被派发，不能证明真正的应用工作已经成功完成。

快速验证

使用全新的临时 Debian 12 Docker 容器，以 root 运行，确保没有既有 root 任务表或 cron 进程。通过 apt 安装 python3、cron 和 procps，将下面代码保存为 cron-overlap.py，再执行 python3 cron-overlap.py。需要预留约两分钟，因为程序等待的是实际日历触发，没有用模拟调度器替代 cron，也没有加速或调整宿主时钟。

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

assert os.geteuid() == 0 and Path('/.dockerenv').exists(), 'use a disposable root Linux container'
assert subprocess.run(['pgrep', '-x', 'cron'], capture_output=True).returncode == 1
assert subprocess.run(['crontab', '-l'], capture_output=True).returncode != 0

with TemporaryDirectory(prefix='cron-overlap-') as directory:
 root = Path(directory)
 events_path = root / 'events.jsonl'
 stop = root / 'stop'
 worker = root / 'worker.py'
 worker.write_text('''from pathlib import Path
import fcntl,json,os,sys,time
root=Path(__file__).parent
kind=sys.argv[1]
def record(event):
 data=json.dumps({'event':event,'kind':kind,'pid':os.getpid(),'monotonic':time.monotonic()})+'\\n'
 fd=os.open(root/'events.jsonl',os.O_WRONLY|os.O_CREAT|os.O_APPEND,0o600)
 try: os.write(fd,data.encode())
 finally: os.close(fd)
lock=None
if kind=='locked':
 lock=open(root/'job.lock','a')
 try: fcntl.flock(lock,fcntl.LOCK_EX|fcntl.LOCK_NB)
 except BlockingIOError:
 record('skip')
 raise SystemExit(0)
record('start')
try:
 until=time.monotonic()+70
 while time.monotonic()<until and not (root/'stop').exists(): time.sleep(0.1)
finally:
 record('end')
 if lock: lock.close()
''')
 table = ''.join(f'* * * * * /usr/bin/python3 {worker} {kind} >>{root}/worker.log 2>&1\n'
 for kind in ('plain', 'locked'))
 subprocess.run(['crontab', '-'], input=table, text=True, check=True)
 daemon = subprocess.Popen(['cron', '-f'], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
 def read_events():
 if not events_path.exists():
 return []
 return [json.loads(line) for line in events_path.read_text().splitlines()]
 try:
 deadline = time.monotonic() + 140
 while time.monotonic() < deadline:
 assert daemon.poll() is None, 'cron exited'
 events = read_events()
 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:
 daemon.terminate()
 stop.touch()
 daemon.communicate(timeout=5)
 subprocess.run(['crontab', '-r'], check=True)
 deadline = time.monotonic() + 5
 while time.monotonic() < deadline:
 events = read_events()
 started = {e['pid'] for e in events if e['event'] == 'start'}
 ended = {e['pid'] for e in events if e['event'] == 'end'}
 if started <= ended:
 break
 time.sleep(0.1)
 else:
 raise AssertionError('test workers did not finish')

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

在 Debian cron 3.0pl1-162 中，普通分支相隔 60.003 秒启动两次，而且第二次启动时第一次尚未结束。加锁分支只真正启动一次，另一次记录跳过。所有断言已经运行成功。清理阶段先停止 cron，再通过停止文件结束实验工作，等待结束记录，最后移除临时任务表，不留下测试后台进程。

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

来源

Debian 12: crontab(5)，日历字段、步进及两个日期字段的组合，已核验 2026-09-13。
Debian 12: cron(8)，守护进程执行、日志和时钟变化处理，已核验 2026-09-13。
Linux: flock(2)，建议锁及非阻塞获取，已核验 2026-09-13。

Linux · XB 现场笔记

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

异常存储，不是副本

耗尽即失效

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

坏掉的样子

快速验证

来源

TCP backlog 收纳还在握手中的连接

backlog 参数管的是 accept 队列

syncookies 开着的时候，SYN 队列就不再是瓶颈

压力真正落在 accept 队列上

坏掉的样子

快速验证

来源

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

逐个进程的计数器

看到谁在扫盘

先看再动

坏掉的样子

快速验证

延伸阅读

来源

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

坏掉的样子

快速验证

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

来源

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

坏掉的样子

快速验证

沿假设追踪到真实结果

延伸阅读

来源

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

账号列改变了解析边界

坏掉的样子

快速验证

来源

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

是否分词取决于上下文

坏掉的样子

快速验证

来源

巨型页用灵活性换更少的 TLB 缺失

为什么 4 KB 会吃亏

hugetlb 与 THP 的区别

池子要提前量

坏掉的样子

快速验证

延伸阅读

来源

Linux 的 overcommit 是内核的一场豪赌

为什么 malloc 很少失败

那个开关

启发式对严格上限

坏掉的样子

快速验证

延伸阅读

来源

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

坏掉的样子

快速验证

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

延伸阅读

来源

systemd oneshot 完成的是一次激活

坏掉的样子

快速验证

任务自身仍要保证正确性

延伸阅读

来源

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

坏掉的样子

快速验证

按层次检查实际路径

来源

缺页并不总是意味着读盘

次缺页只用映射

主缺页要读磁盘