已建立连接在 accept 队列等待;accept() 箭头将连接移到已接受套接字区域,套接字仍可保持打开。

listen backlog 保存等待 accept 的连接

对于 Linux TCP 套接字,listen() 的 backlog 关注已经建立、等待应用接受的连接;未完成握手的队列是另一种概念。调用 accept() 会移出一条待处理连接,并返回供应用使用的已连接套接字。即使这个套接字之后长时间保持打开或忙碌,它也不再占用监听器的 accept 队列。因此,等待接受与已经接受后的活动状态需要分别计数。 backlog 限定等待空间。accept() 释放队列位置,返回的已连接套接字仍可保持活动。 坏掉的样子 如果连接到达速度超过应用接受速度,待处理队列会填满。根据内核行为和设置,新客户端可能遇到重传延迟或超时,而已经接受的请求仍可能正常。进程活着,或者部分请求成功,都不能证明监听器正足够快地接受新连接。问题发生在接受之前时,仅查看业务处理成功率可能看不到完整失败路径。 请求的 backlog 还受到 net.core.somaxconn 限制;只把应用值调得更大,不能超过这个上限。但可观察的精确队列边界与实现有关,因此不能把整数直接当成跨平台承诺,认为必定恰好有那么多同时 connect 成功。应测量实际部署内核,而不是把一个很小的实验结果推广成通用的加一或减一规则。 队列计数也需要上下文。ListenOverflows 和 ListenDrops 是网络命名空间计数,不会自动解释到某个具体服务。其他监听器也能贡献计数,客户端超时也可能来自 accept 队列之外。将生产失败归因于某个 backlog 设置,或者宣称扩大队列能修复问题之前,应结合队列占用、接受进度和计数共同判断。 快速验证 本轮复核没有重跑 Docker 套接字实验,内核参数与溢出结果仍属于此前记录。 把脚本保存为 check-listen-backlog.py,准备宿主 Python、Docker 和固定 Python 镜像后运行。真实套接字操作发生在可丢弃 Linux 容器内,网络只保留回环。记录内核为 6.12.76-linuxkit。只在另行获得授权的可丢弃虚拟机中准备镜像并保持断言开启。脚本读取设置,要求 tcp_abort_on_overflow=0;前提不符时应停止,不要为了复现实验而修改宿主配置。这个条件限定历史超时观察的适用范围: ...

十月 25, 2027 · 2 分钟 · XB Field Notes
已配置的 startup 成功前抑制 liveness 与 readiness;成功后停止当前实例的 startup,并交由分别配置的后续检查。

启动探针成功后,其他探针才开始执行

Startup 探针为容器提供单独的初始化契约。在已经配置的启动探针成功之前,Kubernetes 不会执行这个容器的 liveness 或 readiness 探针。这比“宽限期内忽略一些存活失败”更具体:另外两种检查根本还没有开始。启动检查成功之后,后续健康和就绪判断才按各自规则接管,不能把三个名称理解成同一个接口的不同标签。 阈值乘周期可辅助规划,不是精确重启时刻。启动成功不强迫就绪成功,也不保证持续健康。本轮没有重跑原文保留的 Kubernetes 集成实验。 为每个阶段定义可观察条件 应用进程必须先运行,启动探针才可能成功。因此,容器已经 Running 时,container status 中的 started 仍可能为 false,所在 Pod 也可能尚未 Ready。运行状态描述进程正在执行,启动成功则描述配置的检查条件已经满足。提前开放的 HTTP 监听端可以报告进度,但不应该因此自动声称全部准备已经完成。 启动条件应代表必要的本地准备,例如加载索引或验证初始状态。只有打开端口确实就是所需前置条件时,单纯检查端口才足够。如果监听器先出现,昂贵的初始化稍后才结束,过早成功的检查就会提前解除存活保护,再次造成原本想避免的重启循环。接口名称不会替应用定义初始化完成的真实含义。 启动检查一旦成功,kubelet 就停止当前容器实例的 startup 探针,并按独立配置运行存活与就绪检查。启动成功不是永久健康证明:应用稍后仍可能变成未就绪,或者需要重启。新的容器实例还要重新完成自己的启动检查,不能继承上一实例已经成功的结论。把实例身份和状态变化一起记录,才能解释重复启动的原因。 坏掉的样子 启动探针如果一直不成功,最终会达到失败阈值。Kubelet 随后终止容器,并根据对应重启策略处理。因此,启动保护不是允许初始化无限等待。周期、超时和失败阈值应依据真实初始化耗时设置,同时考虑环境中可能发生的资源争用与可以接受的恢复时间,避免只按开发机器的一次快速启动选择参数。 failureThreshold 与 periodSeconds 的乘积可用于规划启动预算,但不能把它写成所有实际重启都严格遵守的秒表。初始延迟、探针执行与调度、终止宽限和重启退避也影响完整时间线。排查慢发布时,应记录真实尝试和状态变化,而不是仅根据两个配置数字推断容器应该已经重启,或断定平台行为错误。 除非通过 startup 明确建立依赖,否则不应认为 liveness 会等 readiness 成功才开始。就绪与存活原本回答两个持续运行阶段的问题。反过来,启动成功也不会强迫就绪成功:后续 readiness 可能因为另一个条件拒绝流量资格,而进程仍然正常存活。把这些结果分开,才能选择正确恢复动作,避免用反复重启处理暂时不可服务。 ...

八月 22, 2027 · 3 分钟 · XB Field Notes
同一 07:30 UTC 瞬间分到柏林 09:30(窗口内)与纽约 03:30(窗口外);匹配日历不证明有人值守或已经获准。

变更窗口为人设计,不是为服务器

一次发版既是技术时刻,也是人与协作的时刻。选在什么时候,在于谁会在场看结果。 流量只是算式的一半 选在流量最低的时段发布,用户受影响的面确实最小,但它与人撞了个满怀:凌晨运维最可能不在场、或正在处理别的告警。如果发布在半夜半途失败而无人留意,静默故障可以持续数小时才被人类读取。低流量是好的起点,但它回答的是"流量"而不是"风险"。要在减少用户波及与"是否有人来得及反应"之间权衡,优先选择你确实能观察结果的那个窗口,而不是把少一千个用户看得比回滚能力更重。 尊重人的时钟 窗口要服从的不是服务器,而是人。想一想出了问题谁要行动:值班的 SRE、业务负责人、开发团队,把他们的注意力安排进时段。再想想最近还有哪些变更正在凑热闹——新发布的版本、定时任务、自动迁移——别让它们在同一窗口和你绞成一团,把一次发布变成连环事故。与其选一个"并发更小但没人在场"的时段,不如选一个相关的人清醒、可联系、且尚未超载的时段,这才是真正划算的发布时机。 让窗口成为习惯 固定且有人值守的窗口,可以帮助协调高风险变更,使观察和响应更加可预期。但这并不意味着所有发布都必须攒成一批:小型、自动化、可独立回退的变化,也可以使用持续交付流程。节奏应根据实际风险和响应覆盖决定。把构建、冒烟和金丝雀检查自动化,同时保留明确负责人以及经过演练的恢复路径;日历中的时段应当支持这些保障,而不能取代它们。 坏掉的样子 第一种坏法,是窗口之外的紧急变更没有通道。线上正在着火,值班却被告知等下个窗口,于是有人绕过流程直接推生产,无人盯盘,也无回滚说明。窗口本意是门禁,可如果没有破窗程序——谁来批准、谁来盯着、事后补什么记录——每一次例外都会变成暗箱发布。应在正常安排之外写清紧急通道,并演练到和普通发布一样熟;不能把等待下个日历窗口当作所有事故的处理方式。 第二种坏法,是窗口之内的批量堆积踩踏。四五个服务挤进同一两个小时,仪表盘信号混在一起,错误率一抬头,谁也说不清到底是谁引起的。回滚从一键按钮变成多方谈判,因为回滚其中一个,就要猜另外几个的状态。共享故障信号或依赖的变更应当错开,每个条目进入窗口前,都要写清负责人、健康信号与回退路径。排队是为了让归因清晰,值班才敢果断回滚。 第三种坏法,是跨时区窗口错位。作者写周三上午十点,心里是柏林时间,洛杉矶的同事按本地时间理解,结果在半数响应人熟睡时发布。夏令时切换还会悄悄再挪一小时。窗口必须连时区一起存、按读者本地时间展示,排班时逐一确认真有人在场,才能把这个时段算作有人值守。凡是只写钟点不写时区的窗口,迟早会在某个深夜兑现为误操作。 同一瞬间,不同人的时钟。 依据原文与明确限制静态绘制;未为本图重跑原文夹具。 快速验证 使用 Python 3.9 或更新版本,并确保 zoneinfo 能找到 IANA 时区数据;该模块本身不附带这些数据。把下面程序保存为 change_window_check.py,运行 python3 change_window_check.py。运行时不要使用 -O、-OO 或非零的 PYTHONOPTIMIZE,以免断言被跳过。它只用标准库,把每个窗口都当作时区感知的时间段,结论只有两种:allow 表示满足窗口条件,needs-approval 表示需要审批。演示表包含柏林与纽约的周三上午窗口,起止时间位于同一天。冻结日按明确选择的 UTC 政策日期解释,不取决于调用方用哪个时区表达输入瞬间。坏样本是故意留下的反例,仅作拦截演示。 ...

七月 29, 2027 · 2 分钟 · XB Field Notes
四个成员圆点位于三个分组边界内:结算服务的两个 QueueHigh 实例、结算服务的一个 DiskFull 实例,以及搜索服务的一个 QueueHigh 实例。共享分组仍保留不同实例标签。

Alertmanager 分组组织告警,静默抑制通知

一个事故可能产生很多告警,但一组告警并不能证明它们具有同一个原因。Alertmanager 根据配置的标签与路由上下文组织告警,便于一起处理通知,组内仍然保留各条告警的独立身份。静默则是另一种操作:在指定时间窗口内抑制匹配通知,并不会替应用解决故障。理解这些差异,才能准确解释告警页面与通知数量的变化。 原文接口样例预期得到三个组、四条可见告警,结算静默匹配其中三条。本轮绘图没有重跑该实验,图示是原文预期。历史实验仍受阻,未证明计时精度、抑制规则或下游送达。 分组键决定哪些细节放在一起 配置 group_by: [alertname, service] 时,两条属于结算服务的 QueueHigh 告警可以进入同组,即使实例标签不同。搜索服务的 QueueHigh 属于另一组,结算服务的 DiskFull 也因为告警名不同而单独成组。分组依据被选择的标签值,不要求所有成员具有完全相同的指纹。通知被合并后,实例级细节仍然可以从成员列表查看。 把实例加入分组键会增加组数,也可能抵消跨副本合并的目的;省略服务又可能把不同负责人或工作负载混在一起。应围绕排查方式和责任归属选择分组键,同时保留查看成员的入口。特殊值 ... 表示使用所有标签分组,实际效果接近关闭更大范围的聚合,不能把它当作自动寻找合理分组方式的通配符。 路由上下文同样重要。发往不同接收器的告警,即使所选分组标签相同,也不一定组成同一份通知。应验证路由与分组的组合行为。负责整个服务的接收器可能适合合并多个实例,另一个集成则可能需要不同分组契约。任何一种设置都不会自动证明这些告警具有相同根因,因果关系仍然需要从事件与运行证据判断。 初次等待、组内变化和重复提醒使用不同计时 group_wait 延迟新组的第一份通知,让相近时间到来的告警可以加入。某条告警若在初次等待结束前已经恢复,可能完全不产生通知。group_interval 决定之后检查组内更新的节奏,包括新增触发成员或恢复成员;它不是承诺每隔这么久无条件重发所有尚未结束的组。是否向接收端发送恢复通知,还取决于具体集成的 send_resolved 设置,不同集成的默认值并不相同。 没有新增触发或恢复的告警身份需要更新时,repeat_interval 控制重复提醒;单独改变注解文字并不一定触发新通知。是否到达重复时机是在组周期上检查的,因此应选择兼容的整数倍,而不是把它理解为完全独立且精确的闹钟。发送处理与失败还可能增加延迟。应依据响应目标设置这些参数,并将规则等待时长与通知调度分别考虑,避免只看其中一个参数就承诺发现到送达的时间。 通知历史同样存在保留边界。如果 repeat_interval 超过 Alertmanager 的数据保留时间,文档说明可能按保留边界重复发送。因此,把提醒间隔设置得很长,不保证这段时间里绝无重复消息。通知日志的保留期限,与具有明确结束时间的静默,是不同生命周期,应分别纳入运行检查。 ...

七月 27, 2027 · 3 分钟 · XB Field Notes
五列主值班/备援表让五个虚构名字轮转,每周两角色不同。重复四次覆盖 20 周;仅首周期第 2、5 周有虚构特殊标记。

排班需要连续覆盖,也需要复核实际负担

排班可以分配责任,但相同班次数量并不保证负担公平。应同时检查夜间告警、事故处理时间、恢复休息和可靠备援,而不只看每个人在表里出现了几次。 一份被共同承担的职责 值班是团队的事,不是某一位英雄的。轮班把「谁上次没睡好就谁来」变成一张明确的排班表、一套流程,让被打断分担到每个人头上,而不是让一个人独自背完一整条告警队列。而具体排班好不好,就在于「换人不换上下文」这六个字——交接若只换名字不换现状,同一个故障会在每次轮换时被重新发现一遍。所以轮班的灵魂不是「谁那天晚上在」,而是「责任与上下文如何平稳移交」。 交接是工作的一半 一次值班最容易断的,恰是交接这个环节。当接手的人从零开始、一片黑地接过来,本来该是交接的事就变成了重新破案。堵住这个缝只需要两样:一份书面交接(当前坏在哪、试过哪些、下一棒该试什么),以及一段重叠时间——让接班的人跟着旧的人一起盯岗,旧的人在正式放下前把现场讲完。一张只用来排名字的表,会一次次把同一个事故变成新事故。做出这套的难点,不在排满班,而在排完后还留得住上下文。 在铃声响起前演练 演练应安排在告警响起之前,而不是等故障发生。低峰期把 runbook 平铺地走一遍,练的是「恢复路径」而不是症状集;每一条 pager 都应映射到一份写好的计划,让雪夜里的铃声到来时,它是 checklist 而不是谜。提前练习可以增加团队在压力下的可靠选择;平静时候一遍遍过的常规动作,正是把「到时候再想」变成「按部就班照做」的地方。 坏掉的样子 单人长期值班看似省事,实则先压垮的是人。一个人连续几个月拿着寻呼机,即使没有告警也睡不踏实,看到通知就心慌,最后要么倦怠请辞,要么在一次深夜故障中彻底失手。谷歌站点可靠性工程指导强调人员配置与可持续工作负担。解法是设定单次值班上限,并保证下线周真正下线,上周的主值班不再兼任隐形备援。 升级链断裂是第二种常见死法。备援从不确认、联系方式过期,或者所谓升级到经理只是发进一个无人查看的邮箱,深夜三点主值班只能独自拆弹。升级链要像恢复流程一样演练:在工作时间实际寻呼一次备援,确认有人能在几分钟内应答,而不是只在通讯录里写个名字。 告警疲劳是第三种慢性失效。几百条噪声大、无法行动的告警教会团队寻呼机在说谎,于是唯一真实的那条也被顺手划掉。每条告警都应有负责人、有可执行的 runbook 链接、有经过上次误报调优后的阈值,无法行动的告警宁可降级为工单,也不要继续消耗信任。 交接缺失则让轮换只换名字不换上下文。周一换人时没有书面状态,周二就把周一的排查从零再做一遍。必须要求简短交接记录:当前症状、已尝试步骤、下一步动作,并在旧主值班真正下线前保留十五分钟重叠时间,把现场讲完再走。 每周都保留主值班与备援。 依据原文与明确限制静态绘制;未为本图重跑原文夹具。 快速验证 在正式发布排班前,可以先运行这个纸面模型。它为二十个连续星期安排虚构的主值班与备援,并保留两周虚构的特殊覆盖标记。标记不代表任何国家真实的公共假日,遇到标记也不会让整个服务无人负责。持续运行的服务,在某位工程师休假时仍需要明确接替,不能以节日为由直接删除那一周的覆盖。 把代码保存为空目录下的 rota_probe.py。 用 Python 3.9 或更新版本运行 python3 rota_probe.py;程序不访问网络或文件。运行时不要使用 -O、-OO 或非零的 PYTHONOPTIMIZE,以免断言被跳过。 核对逐周人员、各角色次数和最后的 PASS 行。 from collections import Counter from datetime import date, timedelta TEAM = ["ana", "ben", "cara", "dev", "elin"] # fictional names START = date(2027, 8, 2) WEEKS = 20 SPECIAL_WEEKS = {START + timedelta(weeks=1), START + timedelta(weeks=4)} rota = [(START + timedelta(weeks=i), TEAM[i % 5], TEAM[(i + 1) % 5]) for i in range(WEEKS)] assert len(rota) == WEEKS assert len({week for week, _, _ in rota}) == WEEKS assert all(primary != secondary for _, primary, secondary in rota) assert all(primary in TEAM and secondary in TEAM for _, primary, secondary in rota) assert all(b[0] - a[0] == timedelta(days=7) for a, b in zip(rota, rota[1:])) assert all(a[1] != b[1] for a, b in zip(rota, rota[1:])) primary_counts = Counter(primary for _, primary, _ in rota) secondary_counts = Counter(secondary for _, _, secondary in rota) assert set(primary_counts.values()) == {4} assert set(secondary_counts.values()) == {4} for week, primary, secondary in rota: marker = " special-coverage" if week in SPECIAL_WEEKS else "" print(f"{week}: primary={primary} secondary={secondary}{marker}") assert sum(week in SPECIAL_WEEKS for week, _, _ in rota) == 2 print("primary:", dict(sorted(primary_counts.items()))) print("secondary:", dict(sorted(secondary_counts.items()))) print("PASS: 20 covered weeks, distinct backup, four turns per role; special weeks remain staffed") 每一周都有不同的主值班与备援,包括两周特殊覆盖。每人分别获得四次主值班和四次备援,相邻两周的主值班也不同。本轮在 Python 3.12.14 中执行通过了这些断言。它们只证明表里明确检查的排班性质:星期没有缺口、两个角色不由同一人兼任,以及各角色计数相等。 ...

七月 16, 2027 · 2 分钟 · XB Field Notes
四行历史 nginx 日志格式展示三种失败选择,以及采用 JSON 转义并为可选耗时加引号的成功格式。

结构化 nginx 日志需要同时约定转义和字段类型

看起来像 JSON 的 log_format,不一定能可靠地产生结构化事件。nginx 把变量值代入文本,而变量可能包含引号、反斜杠、控制字符,也可能完全没有数据。正确字符串转义与正确字段类型是两个独立要求。用真实解析器检查输出,能发现肉眼查看配置或 nginx -t 成功无法证明的问题,避免上线后才发现部分日志无法进入查询系统。 nginx 1.28.0 历史实验,重跑仍受阻。无效 JSON 片段是有意展示的反例。空的可选耗时与零不同;编码、尝试列表语法、传送和保留仍需分别检查。 坏掉的样子 把 User-Agent 原样插入带引号的 JSON 字段,遇到请求头中的引号就会失败。关闭转义不会更安全,只会让请求字符改变外层记录语法。nginx 默认日志转义则有另一种问题:它可能使用十六进制 \xXX 序列,而这不是合法 JSON 字符串转义。日志适合人阅读,不代表它符合另一种数据格式的语法。 加入 escape=json 可以处理 JSON 字符串转义,但不会自动添加引号、提供 null,或把变量转换成数字。对于本地生成的响应,上游耗时可能根本不存在。如果没有定义可选值的表示方式,就直接不加引号输出,字段可能在语法上缺值;即使实际存在的字符全部转义正确,整个 JSON 仍然无效。 缺失值表示也取决于实测版本的转义路径。nginx 1.28.0 默认转义会为找不到的变量写入短横线,JSON 转义则不写变量文本,所以外面的双引号最终成为空字符串。解析器还必须把这种情况与变量本身确实包含短横线、或包含多次上游尝试列表的情况区分开,不能把所有形式都硬当成同一个数字。 快速验证 下文集成实验的结果保留自历史运行记录;本次修订没有重新执行该实验,不能将这些记录当成本次环境的新实测。 使用宿主 Python 和可丢弃的本地 Docker 守护进程,并确认具有构建、运行权限。历史运行报告为 Linux arm64 上的 nginx 1.28.0、Docker 29.3.1。固定镜像须兼容所用平台;构建的 --network none 不会阻止镜像仓库解析。脚本验证四种日志格式,通过宿主回环端口发送两次 HTTP 请求并解析文件。它尝试清理但没有验证成功,运行者须检查容器、镜像标签和网络是否仍然存在。不要指向远程或生产守护进程。请求头都是公开测试字符串,不读取真实凭据或业务日志: ...

七月 15, 2027 · 3 分钟 · XB Field Notes
持续运行的进程条贯穿多次健康变化:starting、unhealthy、healthy、再次 unhealthy。

Docker 健康检查报告状态,恢复动作需要明确的消费者

Docker HEALTHCHECK 在容器内运行配置的命令,并把结果记录为健康状态。它提供了主进程是否运行之外的另一项观察,但含义取决于命令检查什么:进程存在、HTTP 响应,还是应用特定的就绪条件。Docker 不会因为出现 HEALTHCHECK 指令,就自动推导出一份通用业务就绪契约,检查者必须明确这个信号能证明哪些行为。 展示原文历史样例,本次未重跑。健康状态间距不代表测得时长。原文用 CMD 启动服务,此图不声称 ENTRYPOINT 或信号转发行为。审核仍为已修订、执行受阻。 坏掉的样子 总是返回零的命令,即使应用无法提供有用工作,也会产生看起来正常的健康报告。shell 命令序列还可能因为最后一条命令成功,而掩盖前面的失败。反过来,如果探测依赖一个非必需外部服务,就可能把仍可工作的应用标成不健康,并促使消费该状态的系统执行不必要恢复。探测含义必须符合实际消费者需求。 独立 Docker 的重启策略响应容器终止,不是只要健康状态变成 unhealthy 就触发。加入 restart=always,不会让 Docker 因探测失败而重启仍然存活的应用。同样,健康检查也不会自动从所有代理的路由表中移除容器。必须有控制器或代理明确读取该状态,并实现预期动作,不能把观察配置当成恢复配置。 探测时序也容易被误解。重试阈值统计连续失败,启动宽限则改变早期哪些失败会被计数。启动期的一次成功可以结束初始宽限行为。检测耗时取决于命令持续时间、间隔、超时和配置,不能简单承诺一次请求失败就立刻停止流量。解释延迟时,应沿实际探测时间线检查,而不是只看一个 retries 数字。 快速验证 先取得固定基础镜像,再用宿主 Python 和 Docker 运行脚本。实测为 Docker 29.3.1、Linux arm64,镜像内 Python 3.11.16。它只创建一个临时镜像和容器,关闭容器外部网络,使用自身回环 HTTP 服务。被改变的状态仅是实验内部一个无害就绪文件,结束后清理自己的容器和标签: ...

七月 5, 2027 · 2 分钟 · XB Field Notes
u、g、m 声明指向创建缺少的服务用户,并建立其主组与附加组关系。

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

服务包经常需要先准备专用账号,才能拥有文件或避免以 root 身份运行。systemd-sysusers 用一份小配置声明账号及其组,核心操作是创建缺少的身份,并建立要求的成员关系。它不是通用账号迁移引擎,不负责创建所有目录,也不保证自动分配的数字标识在每台机器上都相同。把这些职责分清楚,才能判断声明已经执行究竟证明了什么。 sysusers 创建缺少的身份与要求的成员关系;不会迁移既有账号字段、保证跨主机自动 UID 一致,或创建家目录。图解基于原文;本轮没有更改账号数据库。 坏掉的样子 u 条目创建缺少的系统用户,通常也创建同名主组;g 创建组,m 添加附加组关系。ID 写成 - 表示自动分配,r 条目向分配池添加区间,多条区间合并使用;已有账号占用了某个数字,就会改变剩余可用范围。因此相同的分配池并不能建立跨机器身份一致性,尤其不能因为两边使用同一份配置,就假定共享存储里的数字所有者一定对应同一人。 更改既有账号的声明,不会自动为它重新编号,也不会自动更新家目录和描述字段。这种行为便于重复执行包初始化,但同时意味着配置差异不等于活动账号记录已经发生变化。真正迁移 UID,需要另外处理既有文件归属、正在运行的进程、共享存储和回退策略;不能只改一行声明,再把命令返回成功当作迁移完成。 家目录列设置的是账号数据库字段,不会创建实际目录。因此,一个服务可能已经拥有有效账号,却仍因为状态路径不存在或不可写而启动失败。需要目录时,应使用合适的受管理服务目录或 tmpfiles 规则,明确创建、所有权和权限。账号存在与目录可用,是两项独立条件,应沿真实服务启动路径分别验证。 快速验证 在装有 systemd-sysusers 的一次性 Linux 环境中,以管理员身份运行下面的 Python 脚本。它不修改机器正在使用的账号数据库,恢复文本记载的环境为 Debian 12、systemd 252.39,但原始运行日志不可用。本轮没有执行此样例;以下结果说明其预期断言,不能视为本轮实测。每组测试都通过 --root 指向单独的临时根目录;shadow 数据库只在内部比较内容,不会把值打印出来: from pathlib import Path from tempfile import TemporaryDirectory import subprocess definition='''r - 61000-61010 u field-worker - "Field worker" /var/lib/field-worker /usr/sbin/nologin g field-readers - m field-worker field-readers ''' def prepare(root,occupied=None): (root/'etc').mkdir(parents=True) passwd='root:x:0:0:root:/root:/bin/sh\n';group='root:x:0:\n' if occupied is not None: passwd+=f'occupied:x:{occupied}:{occupied}:Fixture:/nonexistent:/usr/sbin/nologin\n' group+=f'occupied:x:{occupied}:\n' (root/'etc/passwd').write_text(passwd);(root/'etc/group').write_text(group) directory=root/'usr/lib/sysusers.d';directory.mkdir(parents=True) (directory/'field.conf').write_text(definition) def apply(root): result=subprocess.run(['systemd-sysusers','--root='+str(root)],capture_output=True,text=True,timeout=10) assert result.returncode==0,result.stderr def entries(root,name): return {line.split(':')[0]:line.split(':') for line in (root/'etc'/name).read_text().splitlines()} with TemporaryDirectory(prefix='xbcatm-sysusers-') as directory: first=Path(directory)/'first';second=Path(directory)/'second';prepare(first);apply(first) worker=entries(first,'passwd')['field-worker'];groups=entries(first,'group') assert worker[3]==groups['field-worker'][2] assert 'field-worker' in groups['field-readers'][3].split(',') assert worker[5:]==['/var/lib/field-worker','/usr/sbin/nologin'] assert not (first/'var/lib/field-worker').exists() before={name:(first/'etc'/name).read_bytes() for name in ('passwd','group','shadow','gshadow')} apply(first) assert before=={name:(first/'etc'/name).read_bytes() for name in before} print('user, primary group, and supplementary membership created; repeat leaves databases unchanged') print('home and nologin shell recorded; home directory was not created') prepare(second,int(worker[2]));apply(second) other=entries(second,'passwd')['field-worker'] assert other[2]!=worker[2] print('same allocation range and definition choose different UIDs when existing accounts differ') changed=definition.replace('u field-worker - "Field worker" /var/lib/field-worker', 'u field-worker 62000 "Changed description" /changed-home') (first/'usr/lib/sysusers.d/field.conf').write_text(changed);apply(first) assert entries(first,'passwd')['field-worker']==worker print('changing a declaration does not renumber or rewrite an existing account') assert not (first/'changed-home').exists() print('only temporary alternate-root account databases were changed') 第一份根目录起初只有样本 root 账号。应用声明后,会生成工作用户、它的主组、读者组,以及工作用户的附加组成员关系。脚本检查数字主组关系和实际成员列表,而不是只检查配置能够解析。这样可以明确证明创建结果满足所声明的访问结构,避免把一个存在的组误认为用户已经加入其中。 ...

六月 8, 2027 · 2 分钟 · XB Field Notes