Unix · XB 现场笔记

fork 创建进程，exec 替换其中的程序

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

fork 后接 exec，是 Unix 常见的进程启动模型之一。fork 创建子进程，成功的 execve 则替换调用进程中的程序映像。它们解决不同问题，也具有不同继承规则。在一个程序为另一个命令安排输入、输出、环境和生命周期管理时，必须分清这两个动作，否则很容易把创建新身份与替换运行内容混为一谈。

坏掉的样子

fork 不会让之后所有状态都相互独立。普通私有内存通常通过写时复制逐渐分离，但共享映射仍然共享。继承描述符也继续引用父进程对应的同一份打开文件描述，因此任一侧读取普通文件，都可能改变另一侧观察到的偏移。复制描述符表，不等于为每个文件重新独立执行 open；进程不同，也不能证明资源状态完全不同。

exec 同样不会简单保留全部启动设置。带 close-on-exec 的描述符在成功执行时关闭，其他符合条件的描述符可以继续存在。execve 接收显式环境数组，不是自动复制调用者当前环境。被捕获信号的处理方式会重置，旧内存映射也会消失，即使进程身份和若干其他属性仍然保留。需要逐项理解哪些状态跨越了替换边界。

多线程进程执行 fork 时尤其需要注意。子进程只包含发起调用的线程，却可能继承由其他、已经不在子进程中的线程持有的锁。在 exec 之前任意调用库函数，就可能死锁，因此这段间隔里的可用操作受到约束。方便理解的单线程演示，不能直接变成在线多线程服务器 fork 后随意处理业务状态的方案。

快速验证

把脚本保存为 forkexec.py，在一次性 Linux 环境中运行 python3 forkexec.py。实测使用 Linux 6.12.76 和 Python 3.11.2。样本刻意保持单线程，包含一个私有 Python 值、一份显式共享匿名映射、临时数据文件，以及传递少量结果的管道：

from pathlib import Path
from tempfile import TemporaryDirectory
import errno,json,mmap,os,sys

program=r'''
import errno,json,os,sys
original_pid,kept,dropped,report=map(int,sys.argv[1:])
assert os.getpid()==original_pid
try:os.fstat(dropped)
except OSError as error:assert error.errno==errno.EBADF
else:raise AssertionError('close-on-exec descriptor survived')
assert os.read(kept,2)==b'ef'
assert os.environ['XB_FORK_VALUE']=='child-value'
os.write(report,json.dumps({'pid_unchanged':True,'kept_descriptor':'ef','close_on_exec':'closed','explicit_environment':'child-value'}).encode())
'''
with TemporaryDirectory(prefix='xbcatm-fork-') as directory:
 data=Path(directory)/'data';data.write_bytes(b'abcdef')
 descriptor=os.open(data,os.O_RDONLY);dropped=os.dup(descriptor)
 read_end,write_end=os.pipe();os.set_inheritable(descriptor,True);os.set_inheritable(write_end,True)
 assert not os.get_inheritable(dropped)
 private=['parent'];shared=mmap.mmap(-1,8,flags=mmap.MAP_SHARED);shared[:]=b'parent!!'
 assert os.read(descriptor,2)==b'ab'
 sys.stdout.flush();pid=os.fork()
 if pid==0:
 try:
 os.close(read_end);private[0]='child';shared[:]=b'child!!!'
 assert os.read(descriptor,2)==b'cd'
 try:os.execve(str(Path(directory)/'missing-program'),['missing-program'],{})
 except FileNotFoundError:pass
 else:raise AssertionError('missing exec unexpectedly succeeded')
 os.execve(sys.executable,[sys.executable,'-c',program,str(os.getpid()),str(descriptor),str(dropped),str(write_end)],{'XB_FORK_VALUE':'child-value'})
 except BaseException as error:
 os.write(write_end,('ERROR '+repr(error)).encode());os._exit(1)
 os.close(write_end)
 try:
 waited,status=os.waitpid(pid,0);report=os.read(read_end,4096)
 assert waited==pid and os.WIFEXITED(status) and os.WEXITSTATUS(status)==0,report
 result=json.loads(report);assert result['pid_unchanged']
 assert private==['parent'] and shared[:]==b'child!!!'
 assert os.lseek(descriptor,0,os.SEEK_CUR)==6
 print('fork: private Python state diverges, MAP_SHARED changes and open-description offsets remain shared')
 print('missing exec returns to the child; successful exec keeps its PID, honors close-on-exec, and receives an explicit environment')
 print('parent reaped a successful exit with waitpid and retained its original private value')
 finally:
 shared.close()
 for fd in [descriptor,dropped,read_end]:os.close(fd)

fork 之前，父进程从 abcdef 读取 ab。子进程修改自己的 Python 列表和共享映射，再通过继承描述符读取 cd。子进程结束后，父进程列表仍为原值，共享映射却包含子进程写入的字节。这两个结果需要共同解释，才能准确描述内存继承：只展示普通变量不同，无法证明不存在共享映射。

子进程先尝试执行不存在的文件。这种普通路径缺失错误抛出 FileNotFoundError，子进程继续运行原有程序。随后它通过指定程序和显式环境，再次成功执行 Python。样本验证的是这一可恢复错误，不能把所有罕见执行失败都概括成相同恢复行为；错误发生位置和系统状态仍可能影响真实后果。

替代程序把当前 PID 与 exec 前传入的子进程 PID 比较，两者一致。exec 在子进程内部替换了代码，没有创建第三个进程。它还直接读取显式传入的实验环境值，不依赖登录 shell，也不依赖配置文件自动加载。这些检查分别验证进程身份与环境输入，避免只看到新程序输出就猜测继承方式。

保留下来的数据描述符读取 ef，说明父进程最初读取、子进程读取、替代程序读取，持续推进同一份打开描述的偏移。与此同时，被保留为不可继承的描述符，在替代程序中检查得到 EBADF。脚本只把 exec 后确实需要的描述符设为可继承，因此关闭和保留的结果都对应明确选择。新程序可能复用描述符编号；这里的 EBADF 检查假定启动期间没有其他持续打开的资源占用该编号，关闭原引用并不意味着编号永远保留为空。

父进程使用 waitpid 收集子进程状态，确认正常零退出，再通过自己的描述符观察到偏移六，随后关闭资源。等待既取得生命周期结果，也回收退出子进程。单独知道一个数字 PID，不能替代收集完成状态，更不能证明某次启动已经成功；需要把具体启动对象和实际退出结果对应起来。

明确启动时的资源所有权

应定义子进程需要哪些描述符、关闭不用的管道端，并明确选择环境值。额外继承的管道写端，即使不再实际写入，也可能在预期生产者退出后阻止读取者看到 EOF。因此描述符寿命属于通信协议本身，不能只当作程序启动后再考虑的清理细节。继承关系会直接改变另一个进程等待完成的条件。

当运行时提供的 subprocess 或 spawn 接口能够表达需求时，应优先使用受支持的启动方式。它们内部可能采用字面 fork/exec 之外的机制。对于应用而言，相关契约是接口文档中的描述符、环境和设置行为；假定所有启动器内部都遵循相同步骤，可能得出错误的可移植性或安全结论。

还要区分启动失败、程序运行失败，以及未能观察到完成。成功 exec 不会返回旧程序，但替代程序之后仍然可能以非零状态退出。应记录真实子进程结果，并保留足以识别尝试命令的上下文，同时避免记录机密环境值。这样启动监督才能给出可验证结论，而不是根据一个中间动作成功推断整个工作已完成。

来源

fork(2)，私有内存、共享映射、继承的打开描述与线程限制，已核验 2026-09-12。
execve(2)，映像替换、显式环境、保留 PID 与 close-on-exec，已核验 2026-09-12。
waitpid(2)，收集子进程状态并回收已退出子进程，已核验 2026-09-12。

Setuid 在 exec 时改变有效身份

Sat, 02 Oct 2027 00:00:00 +0000

Linux 可执行文件上的 setuid 位，可以在 exec 成功时把进程的有效用户 ID 改为文件属主的 ID。它不会把进程全部凭据都替换成属主的登录身份。特权辅助程序因此能够代表另一个账户完成受控操作，但输入处理和特权持续时间都会成为安全边界的一部分。模式位本身既不能证明身份转换已经发生，也不能证明这个辅助程序安全。

文件位与进程凭据分开观察

通常的 set-user-ID 转换会改变有效 UID，再将结果复制到保存的 set-user-ID；真实 UID 保持不变。组凭据是另一套状态：setuid 不会自动装入文件属主的附加组。Linux 还存在文件系统身份和能力集合，因此真实、有效与保存 UID 是有用的观察，却不是权限的完整描述。不能看到有效身份变成某个账户，就假设已经拥有该账户登录会话的全部上下文。

应检查实际部署的文件，不要推断整个发行版都采用同一权限。用于修改密码的特权程序，在容器或定制镜像里可能有不同安装方式。属主执行位位置的小写 s 表示同时具备 setuid 和属主执行位，大写 S 则表示存在 setuid 但没有那个执行位。两种显示都不能替代属主核验、目标文件核验，以及对真实启动上下文的检查。

执行环境可以抑制转换

Linux 文档列出了 no_new_privs、nosuid 挂载和被跟踪等条件，它们可能抑制特权转换；某些文档记录的组合也可能直接让执行失败。文件能力同样受到执行约束。不能为了让演示成功，就关闭这些保护。应确定目标路径与调用进程实际适用哪些政策，如实说明限制，而不是把受保护环境当作必须修复的故障。

Linux 忽略解释器脚本上的 set-user-ID 与 set-group-ID 位。因此，把原生辅助程序改成脚本并保留模式，不会保留原先的提权行为。给通用解释器增加特权也不是安全替代方案。特权程序另外启动的可执行文件，还可能主动重置凭据，所以运行独立的 id 命令，不一定忠实显示原辅助程序内部的身份。观测点必须与要验证的进程一致。

降权需要完整设计

setuid 系统调用不同于文件上的模式位。具有足够权限的调用者可以改变真实、有效和保存 UID；非特权调用者能够进行的转换范围更窄。若仍保留允许恢复的保存身份，seteuid 可以支持有效 UID 的可逆切换。无论哪种调用，都必须先检查返回值，再确认状态，不能因为进程原来拥有高权限，就假设降权调用不会失败。

去掉保存 UID 只是永久放弃权限的一部分。附加组、保留能力、已经打开的特权描述符、命名空间和后续执行路径，同样需要考虑。一条 setuid 调用不是通用降权配方，正确顺序取决于程序原有的凭据和资源。安全敏感的辅助程序需要针对设计进行审查，不能把文章里的身份概念直接复制成未经验证的安全实现。

坏掉的样子

带有 s 的模式显示可能掩盖被抑制的转换；另一方面，权限过大的辅助程序也可能通过不安全的路径搜索、用户选择的配置文件等接口泄露真实能力。动态加载器在安全执行模式下会限制危险环境变量，却不会替应用验证输入。应避免用 shell 字符串拼接命令，并明确辅助程序允许访问哪些文件、接收哪些参数和执行哪些操作。

能力机制可以缩小某项授予，例如只允许绑定特权端口，但不会让其他权限全部消失。账户已有的访问权和其他能力仍然存在，能力边界集合与 securebits 还会限制 root 行为。同样，命名空间内部的 root 不等于宿主 root，但映射到普通用户的权限仍然有实际作用。套接字激活可以交付已经打开的监听描述符，却不能免除接收请求的服务本身应承担的安全要求。

快速验证

在具备 Bash、GNU stat、util-linux findmnt、libcap getcap 和 Python 3 的 Linux 环境运行下面完整代码。它只读取一个已安装文件的元数据，以及新 Python 进程自己的凭据状态，不执行 passwd，不改变权限或身份，不挂载文件系统，也不创建命名空间。明确写出目标路径，是为了避免搜索结果意外选中另一个程序；缺少依赖时应补齐正常测试环境，而不是删掉失败检查继续宣称完成。

BASH_ENV= bash --noprofile --norc <<'BASH'
set -eu
target=/usr/bin/passwd
test -f "$target"
stat -c 'mode=%A numeric=%a owner=%u group=%g path=%n' "$target"
findmnt --noheadings --output TARGET,VFS-OPTIONS --target "$target"
getcap -v "$target"
python3 - <<'PYTHON'
import os
from pathlib import Path

status = dict(line.split(':', 1) for line in
 Path('/proc/self/status').read_text().splitlines() if ':' in line)
uids = tuple(map(int, status['Uid'].split()))
gids = tuple(map(int, status['Gid'].split()))
assert uids[:3] == os.getresuid()
assert gids[:3] == os.getresgid()
assert len(uids) == len(gids) == 4
for key in ['Uid', 'Gid', 'Groups', 'NoNewPrivs', 'CapEff', 'CapBnd']:
 print(f'{key}:{status[key]}')
print('PASS: inspected metadata and current credentials; target not executed')
PYTHON
BASH

输出应包含实际模式、数字属主和属组、所在文件系统的挂载选项，以及目标的文件能力列表。没有文件能力，不等于没有 setuid 位；有 setuid 位，也不代表一定存在文件能力。Python 断言把 UID 与 GID 的前三个状态字段分别和对应系统调用结果比较；第四个字段代表文件系统身份。观察当前检查进程的状态，也不能推导尚未运行目标的执行结果。

最后的通过提示只证明这项只读检查完成。不同主机上的值可以不同，实验没有硬编码预期 root 身份，也没有演示提权、不可逆降权或抗攻击能力。这些结论需要另外获准的临时安全测试，以及真实辅助程序内部的观察，不能通过削弱宿主保护来取得一个看起来成功的结果。

来源

Linux execve，有效身份变化、保持不变的凭据及抑制条件，已核验 2026-10-15。
Linux credentials，附加组与文件系统身份，已核验 2026-10-15。
Linux setuid，特权与非特权转换及错误检查要求，已核验 2026-10-15。
Linux seteuid，允许的有效身份转换，已核验 2026-10-15。
Linux capabilities，能力限制与凭据交互，已核验 2026-10-15。
Linux 动态加载器，安全执行模式的环境限制，已核验 2026-10-15。
Linux proc_pid_status，凭据与能力状态字段，已核验 2026-10-15。

sticky bit 限制共享目录中的删除操作

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

Linux 目录上的 sticky bit，为删除或重命名目录项增加所有权限制。它常与宽松的目录写入、搜索权限一起使用，让多个用户能够创建临时文件，又不能任意删除彼此的条目。普通目录权限检查和 sticky 所有权检查都需要满足；sticky 是额外条件，不会替代正常访问控制，也不能只凭这一位判断整个目录里的数据是否安全。

坏掉的样子

没有 sticky 时，用户只要具备目录所需的写入与搜索权限，通常就能删除另一个用户的文件，即使文件模式完全不允许内容访问。unlink 改变的是目录里的名字与对象关系，不要求调用者能够读取或覆盖文件内容。因此，在广泛可写目录中把文件设为 000，并不能单独保护该路径不被他人删除；应分别检查父目录和文件自身的规则。

启用 sticky 后，普通用户还需要拥有该条目或包含它的目录，才能执行相关删除。具有适当 CAP_FOWNER 能力的特权进程，可以绕过这项所有权限制。因此 sticky 约束的是具体权限模型下的同级用户，并不抵御所有管理员，也不保护文件免受目录所有者删除。把它描述为绝对隔离，会夸大真实保证。

sticky 不阻止本来被允许的内容访问。一个用户可能无法 unlink 某个 0666 文件，却仍然可以读取或覆盖它。新建子目录也不会自动继承父目录的 sticky 位。混淆路径保护、内容隐私和继承，会让共享目录树表现出与顶层看起来完全不同的行为，需要沿实际数据位置检查，而不是只看根部权限字符串。

快速验证

把脚本保存为 sticky.py，在一次性 Linux 容器中以 root 运行 python3 sticky.py。控制进程需要分配三个数字身份并启动普通子进程的权限，不会创建账号。实测使用 Linux 6.12.76 和 Python 3.11.2，所有操作都发生在临时样本目录内：

from pathlib import Path
from tempfile import TemporaryDirectory
import errno,os,stat,subprocess,sys

directory_owner=61000;file_owner=61001;other_user=61002
probe_code=r'''
import os,sys
path=sys.argv[1];operation=sys.argv[2]
try:
 if operation=='unlink':os.unlink(path)
 elif operation=='rename':os.rename(path,path+'-renamed')
 elif operation=='write':
 fd=os.open(path,os.O_WRONLY|os.O_TRUNC)
 try:os.write(fd,b'other-user-write')
 finally:os.close(fd)
 elif operation=='read':
 fd=os.open(path,os.O_RDONLY);os.close(fd)
 elif operation=='mkdir':os.mkdir(path,0o777)
 else:raise AssertionError('unknown operation')
except OSError as error:print(error.errno)
else:print(0)
'''
def probe(uid,path,operation):
 result=subprocess.run([sys.executable,'-c',probe_code,str(path),operation],user=uid,group=uid,extra_groups=[],capture_output=True,text=True,timeout=5)
 assert result.returncode==0,result.stderr
 return int(result.stdout)
with TemporaryDirectory(prefix='xbcatm-sticky-') as directory:
 root=Path(directory);root.chmod(0o755);shared=root/'shared';shared.mkdir();shared.chmod(0o777)
 os.chown(shared,directory_owner,directory_owner);victim=shared/'victim'
 def make_victim(mode):
 victim.write_bytes(b'fixture');os.chown(victim,file_owner,file_owner);victim.chmod(mode)
 make_victim(0o000)
 assert probe(other_user,victim,'unlink')==0
 print('without sticky, directory write/search allows removing another owner’s mode-000 file')
 shared.chmod(0o1777);make_victim(0o666)
 assert probe(other_user,victim,'unlink')==errno.EPERM
 assert probe(other_user,victim,'rename')==errno.EPERM
 assert probe(other_user,victim,'write')==0 and victim.read_bytes()==b'other-user-write'
 victim.chmod(0o600);assert probe(other_user,victim,'read')==errno.EACCES
 print('sticky blocks outsider unlink/rename, but file permissions still govern reading and writing')
 assert probe(file_owner,victim,'unlink')==0
 make_victim(0o600);assert probe(directory_owner,victim,'unlink')==0
 print('both the entry owner and the directory owner may remove it')
 child=shared/'child';assert probe(other_user,child,'mkdir')==0
 assert not child.stat().st_mode&stat.S_ISVTX
 shared.chmod(0o1766);assert stat.filemode(shared.stat().st_mode).endswith('T')
 assert probe(other_user,shared/'blocked','mkdir')==errno.EACCES
 shared.chmod(0o1777);assert stat.filemode(shared.stat().st_mode).endswith('t')
 print('sticky is not inherited by a new subdirectory; uppercase T means other-execute is absent')

第一组使用属于一个身份的 0777 目录，以及属于另一个身份的 000 文件。第三个用户成功 unlink 该文件，证明目录写入与搜索权限可以独立于内容权限允许删除。root 只负责准备样本，真正被检查的删除动作由第三个普通身份执行，避免特权绕过使结果失去解释价值。

把目录设为 1777 后，第三个用户的 unlink 与 rename 都得到 EPERM。同一用户在文件为 0666 时，却成功覆盖内容。写入使用不含 O_CREAT 的打开方式，明确操作既有文件，避免 Linux 另一项针对共享目录普通文件的保护策略干扰结果。实验需要区分正在测量的权限规则，而不是把所有拒绝都归因于 sticky。

文件改为 0600 后，第三个用户的读取得到 EACCES。此过程中 sticky 始终启用，所以改变内容访问结果的是文件权限。两种错误来自不同检查，不能合并成“sticky 让每个临时文件私有”的结论。共享目录中的名字不容易被别人删除，与其中内容只有本人能读写，是两条需要分别成立的条件。

文件所有者随后成功删除自己的条目，重新创建的文件也能由目录所有者删除。两项操作都通过普通子进程身份检查，直接验证所有权例外，没有依赖可能具备绕过能力的 root。目录所有者对条目的管理权，与文件所有者对内容的访问权存在区别，应在共享空间设计中明确这种关系。

第三个用户接着创建子目录，后者没有自动继承 sticky。父目录改为 1766 后，权限显示以大写 T 结束，再次创建失败，因为缺少目录搜索权限。恢复 1777，则显示小写 t，表示 sticky 与其他用户执行位同时存在。大写字母不表示保护更强，而是提醒相应执行位缺失，必须结合目录遍历语义理解。

有意识地设计共享存储

当策略允许共享创建、但限制同级用户删除时，可以使用 sticky。预期读写者则需要通过文件权限或 ACL 单独配置。如果每位用户的数据必须保密，应使用另一身份实际尝试访问；只有目录带 sticky，无法证明其中的文件不可读。权限验证要针对需要保护的动作，而不是只确认配置位已经存在。

应把目录所有权理解为对目录项的管理权限。目录所有者可能无法读取某文件，却能够删除它并中断其他用户工作。在多层目录中，需要检查每个条目真正所在父目录的权限，因为受保护的祖先不会自动把 sticky 行为传给后代。顶层正确不等于整棵树已经具有相同删除边界。

创建临时文件时，应使用能够新建合适受限对象、且不信任可预测既有名字的接口。sticky 解决共享目录中一类删除问题，却不解决符号链接替换或所有不安全打开方式。应按应用实际身份与文件系统，分别验证创建、后续内容访问和清理行为，才能确认完整工作流程符合预期。

来源

inode(7)，sticky 目录、文件所有权与权限位显示，已核验 2026-09-12。
unlink(2)，目录写入搜索权限与 sticky 删除限制，已核验 2026-09-12。
capabilities(7)，CAP_FOWNER 对 sticky 目录所有权检查的例外，已核验 2026-09-12。
rename(2)，sticky 目录内重命名的权限检查，已核验 2026-09-12。

环境变量属于各自的进程

Sat, 25 Sep 2027 00:00:00 +0000

环境是程序启动时收到的一组名称与字符串值。子进程通常接收父进程选定的环境，修改自己的副本不会回写父进程或兄弟进程。这是一条有用的配置边界，却不是命令没有副作用的保证：程序仍可能根据配置修改共享文件、数据库或其他资源。理解变量如何传递，与判断程序实际会做什么，是两个需要分别核对的问题。

导出决定另一个程序能收到什么

Shell 变量与环境条目有关联，但并不是同一概念。DEMO_SETTING=local 创建或更新 Shell 参数，export DEMO_SETTING 才把它标记为启动外部命令时应包含的环境项。父 Shell 能打印变量，不代表新启动的 Bash 就能看到未导出的值。把赋值写进某个配置文件，也不会让每个 Shell 自动读取它；还必须确认文件是否在对应启动路径上被加载。

Bash 从环境继承的变量已经带有导出属性，之后重新赋值会保留该属性。因此子进程修改值后，再启动孙进程时可以直接传递新值，不要求每一代重复写一次导出命令。unset 删除变量，Bash 的 export -n 则取消导出属性但保留当前 Shell 中的值。真正需要确认的是直接启动者传入了什么，而不是机械地搜索祖先脚本里出现了多少次导出语句。

子 Shell 不等于重新执行一个 Shell 程序

圆括号命令组和命令替换使用从当前 Shell 复制出来的子 Shell 环境，所以能够看到从未导出的普通 Shell 变量。它们的修改仍不会回到外层。这与重新执行一个 Bash 程序不同：后者收到的是导出的环境条目，不是父 Shell 整张参数表。若把两种情况都简单称为“子进程只认识已导出变量”，就会错误解释圆括号内的实际行为。

使用点命令加载文件时，文件中的命令在当前 Shell 执行，赋值因而能直接改变调用者。这并没有打破进程边界，因为根本不是另一个进程把修改传回来。被加载的文件是可执行 Shell 代码，不是被动的数据文件；只有当你确实打算在当前上下文执行那些内容时，才应加载它。文件扩展名叫配置，并不会改变这一点。

单次调用配置有自己的生命周期

DEMO_SETTING=once external-command 为一次外部命令提供值，不会永久改写外层 Shell 的对应变量。这条结论针对外部命令；特殊内建命令、函数等结构的赋值行为，还受到具体 Shell 规则影响。因此不能进一步推导出“所有看起来像命令的写法都会启动隔离进程”，更不能用这种推断判断函数或者点命令是否会改动当前状态。

在操作系统接口上，execve 接收明确的环境数组，替换当前进程映像，本身并不创建新进程。启动者可以保留、过滤或重建环境，这解释了为什么权限切换、服务管理器以及容器配置会产生不同于交互终端的变量。只有进程父子关系仍不足以证明应用最终收到的配置；应沿真正的启动接口检查传入值，而不是假设环境在整条链路上原样保留。

坏掉的样子

修改终端里的环境，不会更新已经运行的服务。修改环境文件，也要等相关启动器重新读取并启动进程才会生效，除非应用自己实现了配置重载机制。排查时应确认服务使用的配置路径，并在真正处理请求的进程中验证行为。另一个终端里打印出新值，只能证明那个终端的状态发生了变化，不能代替服务侧验收。

缺失与空字符串也要区分，应用可能给它们不同含义。环境字符串不能包含内嵌的空字符，平台还限制参数与环境的总大小，因此不适合装任意二进制载荷或无限增长的文档。诊断时只检查必要的非敏感键，不要直接输出整个环境；完整环境中可能混有其他工具继承的凭据，而本次故障根本不需要这些内容。

快速验证

下面的 Bash 示例只打印专用演示变量，不读取外部配置文件，也不改变外层终端环境。传给点命令的短文档已经把测试所用配置完整写在示例中，便于检查将执行的内容。各行输出分别对应不同的变量传递边界，而不是靠查看某个配置声明就推断它已经生效。

BASH_ENV= bash --noprofile --norc <<'BASH'
unset DEMO_SETTING
DEMO_SETTING=local
printf 'shell=%s\n' "$DEMO_SETTING"
bash --noprofile --norc -c 'printf "unexported-child=%s\n" "${DEMO_SETTING-unset}"'
(printf 'subshell=%s\n' "$DEMO_SETTING")
export DEMO_SETTING
bash --noprofile --norc <<'CHILD'
printf 'exported-child=%s\n' "$DEMO_SETTING"
DEMO_SETTING=child
bash --noprofile --norc -c 'printf "grandchild=%s\n" "$DEMO_SETTING"'
CHILD
printf 'parent-after-child=%s\n' "$DEMO_SETTING"
DEMO_SETTING=once bash --noprofile --norc -c 'printf "one-command=%s\n" "$DEMO_SETTING"'
printf 'parent-after-command=%s\n' "$DEMO_SETTING"
. /dev/stdin <<'CONFIG'
DEMO_SETTING=sourced
CONFIG
printf 'parent-after-source=%s\n' "$DEMO_SETTING"
BASH

未导出变量时，新 Bash 打印 unset，圆括号子 Shell 却能看到 local。导出之后，新子进程收到 local，修改自己的副本，再把 child 传给孙进程；外层 Shell 仍是 local。单次覆盖打印 once，紧接着检查父级仍然得到 local，说明覆盖没有反向传播。

最后，点命令把当前这层演示 Shell 的值改成 sourced。这些结果共同区分普通参数、导出条目、子 Shell 副本、单次调用覆盖，以及在当前 Shell 中执行代码。实验确认的是变量作用域，并没有宣称应用不会产生其他副作用，也没有代替对真实服务部署配置的检查。

来源

Bash 执行环境，导出条目与子 Shell 复制状态的区别，已核验 2026-09-07。
Bash 环境，导出属性与单次命令赋值，已核验 2026-09-07。
POSIX exec 函数，进程映像替换及显式环境数组，已核验 2026-09-07。

shell 找不到那条裸命令时

Thu, 20 May 2027 00:00:00 +0000

“找不到命令”说明一次查找失败，却不代表 Shell 每次都遍历了 PATH 的全部目录。在普通 Bash 中，不带斜杠的命令词可能对应函数、内建命令、缓存的可执行路径，或者刚刚搜索到的程序。更早的输入读取阶段，别名还可能已经改写命令。面对报错，应先检查真正发生故障的那个 Shell，而不是立即重装一个其实已经存在的工具。

先确认是哪一层查找给出结果

展开之后，Bash 先检查函数，再检查内建命令，之后才查找外部程序。type name 描述当前解析结果，type -a name 可以看到其他定义或候选项。command -v name 适合检查该 Shell 中是否存在某个命令，但结果不保证是文件路径，也可能说明它是函数或内建命令。因此不能无条件把输出交给复制文件或读取文件的工具。

查找外部程序时，PATH 中的目录按顺序参与搜索，靠前的旧版本可以遮住后面的新版本。Bash 还会缓存成功找到的路径：hash -t name 可以检查缓存项，hash -r 清空缓存表。原路径上的文件发生变化，与缓存仍选择旧位置，是两个不同的问题。另开一个终端可能重置这些状态，让故障暂时消失，却没有解释原会话到底发生了什么。

斜杠直接选择路径

命令词中的任何斜杠都会绕过外部程序的 PATH 搜索。./tool 指向当前目录的文件，/opt/example/bin/tool 则指定绝对位置。单独输入 tool 并不自动包含当前目录；只有空目录项、相对目录项等配置才可能让当前工作目录介入搜索。这意味着相同的命令名，在不同目录下也可能选中不同的可执行文件。

给服务配置环境时，应明确列出可信目录。交互终端能运行，不证明定时任务、服务管理器或另一个用户拥有相同的环境和启动文件。排查时需要比较实际环境与工作目录。修改登录配置文件也不会自动更新已经运行的进程；应该把预期环境应用到真正负责启动命令的进程，再验证原来的调用链。

坏掉的样子

Bash 通常在找不到命令时返回 127，在找到却无法执行时返回 126。这两个值可以引导调查，却不能取代诊断文本：脚本文件明明存在，但首行指定的解释器不存在，同样可能执行失败。应同时检查选中的文件、执行权限与解释器，而不是反复向搜索路径追加目录，最后把问题掩盖成一次偶然成功。

也不要为了让名称被找到，就把可写的项目目录插到可信工具之前，或者不加区分地提高权限。先确认函数、别名或缓存是否参与了解析。Bash 的 command name 可以绕过同名函数，明确的可执行路径可以绕过目录选择；这些做法不会自动让程序变得可信，也不能补齐程序自身缺失的依赖。找到命令与命令正确执行，是需要分别验证的两件事。

快速验证

下面的 Bash 实验创建两个同名的临时程序。只有这两个专用临时目录被加入搜索路径，全部环境变化都局限于子 Shell。退出时逐个删除实验创建的文件和目录，不修改任何已安装程序。故意执行失败的分支会立即记录状态，避免被随后的输出操作覆盖。

准备阶段启用遇错退出，让临时文件创建失败时及时停止；开始故意制造执行失败之前，再关闭该选项。本轮在 Bash 5.2.37 上观察到文档规定的一百二十六与一百二十七。对于裸名称搜索失败，命令未找到处理函数可以提供自己的退出状态；下面故意缺失的路径含有斜杠，不会测试这一钩子。因此仍应把状态与实际执行路径、Shell 选项及诊断一起解释，而不能根据一个数字推断所有启动环境。

bash --noprofile --norc <<'BASH'
set -eu
demo_dir=$(mktemp -d)
trap 'rm -f "$demo_dir/one/demo-tool" "$demo_dir/two/demo-tool" "$demo_dir/blocked"; rmdir "$demo_dir/one" "$demo_dir/two" "$demo_dir"' EXIT
mkdir "$demo_dir/one" "$demo_dir/two"
printf '#!/bin/sh\nprintf "one\\n"\n' > "$demo_dir/one/demo-tool"
printf '#!/bin/sh\nprintf "two\\n"\n' > "$demo_dir/two/demo-tool"
chmod +x "$demo_dir/one/demo-tool" "$demo_dir/two/demo-tool"
PATH="$demo_dir/one:$demo_dir/two:$PATH"
demo-tool
hash -p "$demo_dir/two/demo-tool" demo-tool
demo-tool
hash -r
demo-tool
demo-tool() { printf 'function\n'; }
demo-tool
command demo-tool
unset -f demo-tool
"$demo_dir/two/demo-tool"
: > "$demo_dir/blocked"
chmod 600 "$demo_dir/blocked"
set +e
if "$demo_dir/blocked" 2>/dev/null; then
 printf 'unexpected execution\n'
else
 printf 'not-executable=%s\n' "$?"
fi
if "$demo_dir/missing" 2>/dev/null; then
 printf 'unexpected file\n'
else
 printf 'missing=%s\n' "$?"
fi
BASH

开头应依次出现 one、two、one，分别证明普通搜索、显式设置缓存项，以及清缓存后的重新搜索。随后是 function、one、two，区分函数调用、绕过函数和指定绝对路径。最后，不可执行的文件应返回 126，不存在的路径应返回 127。这些结果来自受控的临时文件，不依赖机器恰好安装了哪些同名软件。

实验并没有覆盖所有操作系统加载器错误，也没有模拟每一种服务启动环境。处理实际故障时，应在出错环境中记录解析到的命令与版本，修正后仍沿同一条调用链复验。另一个终端里查询成功，只能证明那个终端可用，不能证明原来的服务已经恢复。

来源

POSIX shell 命令查找，定义了 PATH 查找规则与找不到命令时的退出状态，已核验 2026-06-01。
Bash 参考手册：命令查找与执行，函数和内建命令优先级及可执行路径缓存，已核验 2026-09-07。

优雅关闭：停止准入，再排空工作

Sat, 19 Dec 2026 00:00:00 +0000

优雅关闭改变的是服务接收与完成工作的方式，信号只是触发条件。它能够提供的保证比“绝不丢失任何东西”更有限，也更具体：停止接收新的业务工作，记录此前已经接受的任务，在有界时间内等待完成，并在期限耗尽时如实报告剩余工作。仅仅捕获一个信号，并不等于已经实现安全关闭。

信号开始的是协调过程

应用可以处理 SIGTERM，然后启动自己的关闭流程；SIGKILL 则不能捕获、阻塞或忽略。首先应确认谁真正收到了停止信号：如果外层包装进程收到信号却不转发，内部工作进程即使安装了正确的处理器，也可能根本没有机会执行它。

信号处理器应保持简短。Python 在主解释器的主线程执行信号处理函数，并明确警告不要在其中使用同步锁。实验只设置一个标记，把修改就绪、关闭准入和等待任务的工作留给普通控制流程，不在信号处理器里执行网络操作或等待工作线程。

应该尽早撤下就绪，让路由变更开始传播，但本地业务准入仍需要独立闸口，因为已有连接和传播延迟都可能带来后续请求。关闭闸口与登记已经接受的任务，必须使用一致的边界；否则看似已经停止接收，实际上却可能漏记同时进入的新任务。

截止期限约束完整生命周期

任务应一直记账到真正的完成点。调用方等待超时，不证明工作线程已经停止；响应已经发送，也不证明业务事务已经持久化。应根据操作契约选择完成边界，而不是把任意一次连接关闭都解释成成功，更不能仅凭客户端离开就提前回收在途任务。

进程内的经过时间应由单调时钟计算，并在监督器实际允许的时间内为清理留出余量。期限到达后，对剩余工作必须有明确的取消、放弃或可靠移交政策。从等待循环里跳出来，本身不会终止正在运行的线程，也不会撤销已经执行的业务效果。

正常排空和未完整关闭，应在记录中保持可区分。某个非零退出码是服务自身的约定，不是能够保证正确恢复的通用规则。客户端没有拿到响应时，仍可能需要根据幂等契约或业务记录确认结果，不能仅凭服务正在关闭就断言重试一定安全。

与监督器核对同一份契约

systemd 的 TimeoutStopSec 管理配置中的停止命令等待和服务停止等待；KillMode 选择被终止的进程范围，不决定排空能持续多久。mixed 模式首先向主进程发送终止信号，最后的强制终止覆盖控制组内剩余进程；主进程提前退出，也可能触发这一升级。真实 unit 中的停止钩子和通知延长机制必须一起检查。

Kubernetes 在执行已配置的 preStop 钩子之前，就开始计算终止宽限时间，钩子不是额外领取另一份独立预算。EndpointSlice 的终止状态更新与本地关闭同时推进，并不是完成一次全局同步屏障后，从此再也不会有请求到达。因此，端点变更不能替代应用自己的准入判断。

实际停止信号也可能受到镜像或运行时配置影响。应测试部署中的进程树和停止约定，而不是把本地直接执行程序的结果扩大为容器、sidecar 与代理协调全部正确的证据。这些组件各自的关闭顺序和宽限时间，需要沿真实调用链核对。

坏掉的样子

一个只修改就绪状态的关闭标记，可能让已有的持久连接继续不断提交新工作；反过来，立即切断全部活动连接，又会丢掉原本有时间完成的请求。停止新的业务准入，与完成已经获准的工作，是两个需要分别控制和观察的决定。

无界等待线程可能超过监督器允许的时长。守护线程允许进程退出时不等待它们，但这意味着放弃，不等于安全取消或事务回滚。库自身也有关闭契约：Python socketserver 的 shutdown 必须从不同于 serve_forever 的线程调用，否则会造成死锁，关闭路径反而永远无法结束。

应同时观察接受、完成、拒绝和未完成的工作，以及关闭耗时和退出结果。只记录一个“退出成功”，却不区分这些数量，可能掩盖真正丢掉的任务。验收对象应该是完整生命周期，而不是那一行信号注册代码或某个看起来正常的退出状态。

快速验证

保存为 shutdown_check.py，在类 Unix 系统上用 Python 3.10 以上版本执行 python3 shutdown_check.py。实验已在 macOS、Python 3.14.4 上运行。每种情况都创建自己的子进程和回环 HTTP 服务，SIGTERM 只发给该子进程；POST release 路由仅用于测试协调，不是建议上线的管理接口。

from concurrent.futures import ThreadPoolExecutor
from http.client import HTTPConnection, RemoteDisconnected
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
import json
import selectors
import signal
import subprocess
import sys
from threading import Condition, Event, Thread
import time


def child(grace):
 state = {"draining": False, "active": 0}
 condition, release = Condition(), Event()
 stop_requested = False

 def stop(signum, frame):
 nonlocal stop_requested
 stop_requested = True # No lock, I/O, or shutdown call in the signal handler.

 class Handler(BaseHTTPRequestHandler):
 def log_message(self, *args):
 pass

 def reply(self, status, value):
 body = json.dumps(value).encode()
 self.send_response(status)
 self.send_header("Content-Type", "application/json")
 self.send_header("Content-Length", str(len(body)))
 self.send_header("Cache-Control", "no-store")
 self.end_headers()
 self.wfile.write(body)

 def do_GET(self):
 if self.path == "/state":
 with condition:
 snapshot = dict(state)
 self.reply(200, snapshot)
 elif self.path == "/readyz":
 with condition:
 ready = not state["draining"]
 self.reply(200 if ready else 503, {"ready": ready})
 elif self.path == "/work":
 with condition:
 admitted = not state["draining"]
 if admitted:
 state["active"] += 1
 if not admitted:
 self.reply(503, {"error": "draining"})
 return
 try:
 if release.wait(timeout=5):
 self.reply(200, {"done": True})
 else:
 self.reply(503, {"error": "fixture-timeout"})
 finally:
 with condition:
 state["active"] -= 1
 condition.notify_all()
 else:
 self.reply(404, {"error": "not-found"})

 def do_POST(self):
 if self.path == "/release": # Loopback-only test coordination, not workload admission.
 self.reply(200, {"released": True})
 release.set() # Finish the control reply before work can complete and the child exits.
 else:
 self.reply(404, {"error": "not-found"})

 signal.signal(signal.SIGTERM, stop)
 server = ThreadingHTTPServer(("127.0.0.1", 0), Handler)
 server.daemon_threads = True # Explicitly permits abandonment in the deadline case.
 serving = Thread(target=server.serve_forever, kwargs={"poll_interval": 0.01})
 serving.start()
 print(json.dumps({"port": server.server_port}), flush=True)
 while not stop_requested:
 time.sleep(0.005)
 deadline = time.monotonic() + grace
 with condition:
 state["draining"] = True
 while state["active"] and time.monotonic() < deadline:
 condition.wait(timeout=max(0, deadline - time.monotonic()))
 unfinished = state["active"]
 server.shutdown() # Called outside the thread running serve_forever.
 serving.join(timeout=2)
 server.server_close() # Does not wait for daemon request threads.
 assert not serving.is_alive()
 print(json.dumps({"unfinished": unfinished, "deadline_expired": unfinished > 0}), flush=True)
 return 3 if unfinished else 0 # Fixture policy, not a universal exit-code convention.


def request(port, route, method="GET"):
 connection = HTTPConnection("127.0.0.1", port, timeout=3)
 try:
 connection.request(method, route)
 response = connection.getresponse()
 return response.status, json.loads(response.read())
 finally:
 connection.close()


def wait_state(port, predicate):
 deadline = time.monotonic() + 3
 while time.monotonic() < deadline:
 status, state = request(port, "/state")
 assert status == 200
 if predicate(state):
 return state
 time.sleep(0.01)
 raise AssertionError("child did not reach the expected state")


def exercise(finish):
 process = subprocess.Popen(
 [sys.executable, __file__, "child", "3" if finish else "1"],
 stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True,
 )
 try:
 with selectors.DefaultSelector() as selector:
 selector.register(process.stdout, selectors.EVENT_READ)
 assert selector.select(timeout=5), "child did not announce its local port"
 port = json.loads(process.stdout.readline())["port"]
 assert request(port, "/readyz") == (200, {"ready": True})
 with ThreadPoolExecutor(max_workers=1) as pool:
 active = pool.submit(request, port, "/work")
 wait_state(port, lambda state: state["active"] == 1)
 process.send_signal(signal.SIGTERM)
 wait_state(port, lambda state: state["draining"])
 assert request(port, "/readyz") == (503, {"ready": False})
 assert request(port, "/work") == (503, {"error": "draining"})
 assert request(port, "/state")[1]["active"] == 1
 if finish:
 assert request(port, "/release", "POST")[0] == 200
 assert active.result(timeout=4) == (200, {"done": True})
 output, errors = process.communicate(timeout=5)
 assert errors == ""
 record = json.loads(output)
 assert process.returncode == (0 if finish else 3)
 assert record == {"unfinished": 0 if finish else 1, "deadline_expired": not finish}
 if not finish:
 try:
 active.result(timeout=4)
 except (OSError, RemoteDisconnected):
 pass
 else:
 raise AssertionError("abandoned work must not report a successful reply")
 print("completed drain" if finish else "expired drain", record, "exit", process.returncode)
 finally:
 if process.poll() is None:
 process.kill() # Safety cleanup targets only this fixture's child.
 process.wait(timeout=5)
 process.stdout.close()
 process.stderr.close()


if __name__ == "__main__":
 if sys.argv[1:2] == ["child"]:
 raise SystemExit(child(float(sys.argv[2])))
 exercise(True)
 exercise(False)

两个场景都在 SIGTERM 之前接受一个请求。排空标记可见后，就绪返回 503，新的业务请求也得到 503，而先前获准的请求仍然计入在途工作，没有因为开始关闭就被假装清零。断言比较的是这些真实 HTTP 响应与子进程状态。

释放原请求后，它先收到 200，子进程再以零退出，并报告没有未完成工作。如果不释放，当前实验的一秒排空预算会耗尽；子进程报告一个未完成请求，以三退出，等待中的客户端拿不到成功响应。退出三只是这份实验明确选择的结果约定。

后一个场景刻意演示退出时放弃守护线程，不证明协作式取消、持久化、SIGKILL 清理或安全重放。实验没有运行 systemd unit、部署 Kubernetes 工作负载、执行真实事务或施加生产流量；这些更强保证不能从本机关闭结果中直接推导。

来源

Linux signal(7)，终止信号与 SIGKILL 不可捕获的边界，已核验 2026-09-09。
Python 信号，主线程信号处理及处理器内禁止使用锁的警告，已核验 2026-09-09。
Python socketserver，关闭调用的线程要求及守护请求线程行为，已核验 2026-09-09。
systemd.service，TimeoutStopSec 的停止等待与通知延长机制，已核验 2026-09-09。
systemd.kill，KillMode 进程范围与终止升级，已核验 2026-09-09。
Kubernetes：Pod 生命周期，preStop、终止宽限、停止信号与 EndpointSlice 变化，已核验 2026-09-09。

让持久状态和临时空间拥有不同生命周期

Thu, 03 Dec 2026 00:00:00 +0000

持久应用状态和可丢弃临时文件，需要不同的保留、容量与恢复策略。分开路径有助于表达这些策略，但目录本身不会创造持久性，也不会隔离磁盘容量。真正决定进程重启、容器替换、宿主故障或清理后保留什么的，是路径背后的存储。可靠布局需要把每类数据连接到明确生命周期，而不是仅仅给文件夹起两个不同名字。

坏掉的样子

如果清理任务把混合目录全部当作可丢弃内容，可能在删除临时下载时一起删除已提交记录。相反，也可能备份了大量可重建缓存，却漏掉真正重要的小数据库。文件扩展名和年龄不能代替对应用所有权的理解；需要知道路径由谁管理，以及其内容是否真的能从权威来源重新构造，才能决定能否删除。

容器重启和替换也不同。停止再启动同一个容器，通常保留其可写文件系统层；删除容器才会丢弃该层，而明确保留的命名卷可以继续存在。tmpfs 又有不同生命周期，容器停止时其内容会消失。把这三类位置统称为临时，会掩盖影响恢复流程的区别，导致测试重启成功后就误以为替换也安全。

同一个文件系统里的两个目录，仍然竞争该文件系统的剩余空间。只把临时路径从 /data/tmp 改成 /scratch，却不改变存储策略，并不会自动保护数据库写入。容量隔离需要合适的挂载、配额或其他可执行预算，同时监控应区分临时空间增长与持久状态增长。路径整齐不能替代真正的资源边界。

快速验证

先取得固定镜像，再用宿主 Python 和 Docker 运行脚本。实测为 Docker 29.3.1、Linux arm64，镜像内 Python 3.11.16 提供 SQLite 模块。它创建一个私有命名卷和八 MiB 的 tmpfs 临时挂载，只删除自身容器与卷。小规模临时空间耗尽被限制在实验内部，不修改既有服务存储：

import subprocess,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],text=True,capture_output=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def execute(container,code):return docker('exec',container,'python','-c',code).stdout.strip()

name='xbcatm-state-'+uuid.uuid4().hex[:10];volume=name+'-data';containers=[name+'-one',name+'-replacement']
try:
 docker('volume','create',volume)
 def start(container):
 docker('run','-d','--name',container,'--network','none','--mount','type=volume,src='+volume+',dst=/state','--tmpfs','/scratch:rw,size=8m',BASE,'python','-c','import time;time.sleep(180)')
 start(containers[0])
 execute(containers[0],'from pathlib import Path;import sqlite3;c=sqlite3.connect("/state/data.sqlite");c.execute("create table records(value text)");c.execute("insert into records values (?)",("committed",));c.commit();c.close();Path("/ephemeral").write_text("container-layer");Path("/scratch/crumb").write_text("scratch")')
 docker('stop','--time','1',containers[0]);docker('start',containers[0])
 execute(containers[0],'from pathlib import Path;import sqlite3;assert Path("/ephemeral").exists();assert not Path("/scratch/crumb").exists();c=sqlite3.connect("/state/data.sqlite");assert c.execute("select value from records").fetchall()==[("committed",)];c.close()')
 print('stop/start retains the container writable layer and volume data, while the tmpfs scratch mount loses its file')
 docker('rm','-f',containers[0]);start(containers[1])
 execute(containers[1],'from pathlib import Path;import sqlite3;assert not Path("/ephemeral").exists();c=sqlite3.connect("/state/data.sqlite");assert c.execute("select value from records").fetchall()==[("committed",)];c.close()')
 print('replacement loses the old writable layer but retains the named-volume database')
 execute(containers[1],'''import errno,os,sqlite3
fd=os.open('/scratch/fill',os.O_CREAT|os.O_WRONLY,0o600)
try:
 try:
 while True:os.write(fd,b'x'*1048576)
 except OSError as error:assert error.errno==errno.ENOSPC
finally:os.close(fd)
source=sqlite3.connect('/state/data.sqlite');source.execute('insert into records values (?)',('after-scratch-full',));source.commit()
backup=sqlite3.connect('/state/check-copy.sqlite');source.backup(backup);backup.close();source.close()
restored=sqlite3.connect('/state/check-copy.sqlite');assert restored.execute('select value from records order by rowid').fetchall()==[('committed',),('after-scratch-full',)];restored.close()
''')
 print('bounded scratch reaches ENOSPC while state still commits; a SQLite backup copy reopens with both committed records')
finally:
 docker('rm','-f',*containers,check=False);docker('volume','rm',volume,check=False)

第一个容器在 /state 下创建 SQLite 数据库并提交一条记录，在普通可写层写入 /ephemeral，再把临时文件放进 /scratch。三个路径都通过普通文件接口访问，背后却是不同存储位置。持久应用记录通过 SQLite commit 提交，不依赖尚未关闭的输出缓冲，从而让后续生命周期对照具有明确数据边界。

停止再启动同一个容器后，数据库记录与 /ephemeral 仍存在，临时文件却不见了。启动命令不会重建这些文件，因此观察的是存储寿命，不是初始化逻辑把丢失隐藏起来。这个结果把保留容器时的进程重启，与真正销毁可写层区分开。排查重启后数据行为时，应先确认实际执行了哪一种操作。

随后删除原容器，创建挂载同一命名卷的替换容器。数据库仍含 committed，但 /ephemeral 已不存在。新实例获得新的可写层，同时重新连接保留卷。这证明卷不依赖某个容器的生命周期，却不证明能够抵御 Docker 宿主丢失或卷本身被删除。持久性保证必须附带存储所在位置和删除规则。

接着，替换容器持续写入受限临时挂载，直到返回 ENOSPC。此时仍可向卷中的数据库插入并提交 after-scratch-full。成功提交证明本次配置的容量边界确实生效，不表示持久存储没有上限，也不保证免受其他共享资源耗尽影响，例如宿主总内存。一个隔离维度有效，不能推导所有资源都独立。

最后，通过 SQLite 备份接口创建数据库副本，关闭、重新打开，并按顺序核对两条已提交记录。这里使用数据库自己的复制接口，没有假定随手复制一个正在使用的数据库文件名，就能一致取得所有必要文件。副本仍在相同实验卷上，因此只验证复制可读性与内容，不是独立灾难恢复备份的证据。

让策略跟随数据契约

权威应用数据使用稳定状态目录，可重建工作使用独立管理的临时位置。文件系统层次标准把应用状态与 /var/lib 对应；容器可以选择不同路径，同时保留这种语义区别。通过应用配置明确目录，并说明哪个组件负责创建、权限、清理和迁移。只在部署文档里写路径，而应用实际写向别处，也无法形成有效边界。

有意设置临时预算，并在耗尽时处理错误，不要删除无关状态。缓存只有在权威来源和重建过程确实可用时才可丢弃。一些看似临时的文件，可能是进行中事务或恢复所必需，所以清理需要应用契约，不能仅凭不加区分的年龄规则。删除之前应知道它为何存在，而不是只知道它看起来旧。

独立备份应具有符合数据要求的保留策略，并在新环境中测试恢复。卷跨容器替换保留，是持久性证据，不是备份证据；同卷副本无法抵御该卷整体丢失。监控真实底层存储，核对恢复内容，并把破坏性的卷删除设为明确生命周期决策，才能让目录分离真正服务于数据安全和可维护性。

来源

Docker volumes，独立于容器可写层的数据生命周期，已核验 2026-09-12。
Docker tmpfs mounts，临时内存挂载及大小限制，已核验 2026-09-12。
Filesystem Hierarchy Standard: /var/lib，需要保留的应用可变状态信息，已核验 2026-09-12。
SQLite online backup API，通过数据库接口执行一致复制，已核验 2026-09-12。

命名的配置文件偏爱清晰

Sat, 21 Nov 2026 00:00:00 +0000

配置容易找、易读、可 diff,这不只是一种偏好;它正是变更保持可评审的方式。用清晰的约定命名文件,是迈向环境特定、单一来源配置的第一步。

文件是一份意图记录

一份带名字、进仓库、能追溯版本的配置文件，本身就是一份意图记录：部署上去的每个值都是显式可查的，改动也像代码一样被 review、被 diff。当文件与项目同住仓库时，每次修改都留下 blame 与 pull request，任何人随时都能回答「当前这套是什么、谁改过」。清晰的命名约定（应用参数放 app.conf、环境形态放 app.env）让每份文件的用途一眼可见，而不是被四处散落的命令行参数悄悄改写。

环境变量与文件解决不同问题

环境变量与文件要解决的是不同问题。变量的优势在于同一份构建可以部署到很多环境而不必改镜像——运行时按环境注入不同的值。文件的好处是能表达结构化的配置，而不是用一串拼字符串的变量去硬凑。多数团队两者并用：文件负责结构，环境负责在部署时注入值。让这套做法保持诚实的是——真值的来源明确，结构与可注入值之间的边界是刻意划开的，而不是随手撞出来的。

密钥仍然要移出去

把配置文件放进仓库，并不等于就允许把密钥一起提交。任何属于凭据的东西，都必须在运行时被注入或从密钥仓库里引用，绝不能写死在你提交进去的那个文件里。配置与密钥在架构上就该分开：文件管形态，密钥库管机密。存储加密、传输保护与访问控制仍需单独配置，环境注入也不等于加密。启动日志可以记录键名与获胜来源，但敏感取值必须脱敏，不能把整份生效配置无条件打印。

坏掉的样子

配置名漂移会让加载器读错文件。部署时写下的是 app-prod.json，程序启动时打开的却是 app.prod.json，预期文件根本不存在，加载器又悄悄回退到一份陈旧的开发配置。服务看似正常启动，实际连错了数据库，而版本差异里没有任何痕迹，因为错的是文件名而不是某个具体的值。正确做法是启动时只解析一条显式路径并把它打印出来，找不到就直接报错退出，绝不去猜测某个名字相近的兄弟文件。

环境变量覆盖则是另一个方向的静默失败。APP_PORT 被写成空字符串，或者把下划线误写成连字符，加载器可能用空值覆盖掉文件里的正确值，也可能什么都不覆盖，具体行为取决于实现。无论哪一种，运行时的真实值都已经和仓库里的文件对不上了，却又没有留下任何差异记录，排查的人反复阅读配置文件，只会得出什么都没变的错误结论。正确做法是为每个配置键记录赢家来源，明确区分文件、环境与命令行参数，并在启动时打印出来，明确拒绝已经提供的空值，不悄悄退回旧来源；本例还检查未知应用键、类型、模式与端口范围。

密钥进仓库是最贵的一类失败。有人为了临时修复预发布环境，把携带生产凭据的 .env 提交上去，下一次提交又把它删掉，以为事情已经过去。实际上凭据还留在版本历史、镜像与备份里，中间每一次克隆都把它带走了，后续删除并不能收回已经扩散的秘密。正确做法是提交的文件只保留形态，把敏感位置写成 password = "from-store" 这样的占位符，真实值只从密钥库或运行时环境注入，并用提交前扫描钩子在凭据落地之前就把它拦下来，否则清理历史与轮换密钥的代价会远超当初图方便省下的时间。

快速验证

把下面程序保存为 config_precedence_probe.py，然后运行 python3 config_precedence_probe.py。它只用标准库，在临时目录里写多组 JSON 示例，不会触碰任何真实配置。好样本从 {"host": "127.0.0.1", "port": 8000, "mode": "dev"} 出发，先用环境变量 APP_PORT=9001 覆盖端口，再用命令行 --mode prod 覆盖模式，最后断言合并结果与每个键的来源映射完全符合文件小于环境、环境小于参数的优先级。

import argparse
import json
from pathlib import Path
from tempfile import TemporaryDirectory

KEYS = {"host", "port", "mode"}
ENV = {"APP_HOST": "host", "APP_PORT": "port", "APP_MODE": "mode"}

def validate(key, value):
 if isinstance(value, bool) or value is None or not isinstance(value, (str, int)):
 raise ValueError("invalid type: " + key)
 text = str(value).strip()
 if not text:
 raise ValueError("empty value: " + key)
 if key == "port":
 if not text.isascii() or not text.isdecimal() or not 1 <= int(text) <= 65535:
 raise ValueError("invalid port")
 return int(text)
 if key == "mode" and text not in {"dev", "prod"}:
 raise ValueError("invalid mode")
 if not isinstance(value, str):
 raise ValueError("text required: " + key)
 return text

def load(path, env, argv):
 parser = argparse.ArgumentParser()
 for key in sorted(KEYS):
 parser.add_argument("--" + key)
 cli = {k: v for k, v in vars(parser.parse_args(argv)).items() if v is not None}
 file = json.loads(Path(path).read_text())
 if not isinstance(file, dict) or set(file) - KEYS:
 raise ValueError("unknown file keys or non-object config")
 if any(k.startswith("APP_") and k not in ENV for k in env):
 raise ValueError("unknown application environment key")
 merged, sources = {}, {}
 for label, values in [("file", file), ("env", {ENV[k]: v for k, v in env.items() if k in ENV}), ("cli", cli)]:
 for key, value in values.items():
 merged[key], sources[key] = validate(key, value), label
 if set(merged) != KEYS:
 raise ValueError("missing required fields")
 return merged, sources

with TemporaryDirectory() as directory:
 path = Path(directory) / "app.prod.json"
 path.write_text(json.dumps({"host":"127.0.0.1", "port":8000, "mode":"dev"}))
 value, source = load(path, {"APP_PORT":"9001"}, ["--mode", "prod"])
 assert value == {"host":"127.0.0.1", "port":9001, "mode":"prod"}
 assert source == {"host":"file", "port":"env", "mode":"cli"}
 print("GOOD", value, "via", source) # These synthetic fields are non-secret.
 for env, argv in [({"APP_PORT":""}, []), ({"APP_PORT":"65536"}, []),
 ({"APP_PORT":True}, []), ({"APP_PORRT":"9001"}, []),
 ({}, ["--mode", ""]), ({}, ["--port", "-1"])]:
 try:
 load(path, env, argv)
 except ValueError:
 pass
 else:
 raise AssertionError("invalid config accepted")
 for contents in [{"host":"127.0.0.1"}, {"host":"x","port":None,"mode":"dev"},
 {"host":"x","port":8000,"mode":"dev","password":"placeholder"}]:
 path.write_text(json.dumps(contents))
 try:
 load(path, {}, [])
 except ValueError:
 pass
 else:
 raise AssertionError("invalid file accepted")
 try:
 load(Path(directory) / "app-prod.json", {}, [])
 except FileNotFoundError:
 pass
 else:
 raise AssertionError("wrong path accepted")
print("PASS: precedence, present-empty rejection, types, unknown keys, range and missing path")

反例拒绝已经提供的空覆盖值，而不是静默退回旧来源；还会拒绝范围外端口、伪装成整数的布尔值、未知 APP_ 键、非法参数、缺字段、空值与未知文件键。刻意写错的文件名抛出找不到文件。输出只展示无秘密的成功合并，最后打印 PASS；真实诊断不能照此打印敏感值。实验验证的是这个加载器声明的政策，不是所有配置格式。名称、优先级和空值处理都属于应用契约，不能因为采用 JSON 或环境变量就认为自动正确。还应明确哪些前缀属于本应用，避免把无关进程环境误当作需要拒绝的配置。

来源

12 Factor：配置与环境，由环境驱动的配置，已核验 2026-10-15。
12 Factor：构建、发布、运行，分离各阶段，已核验 2026-10-15。
环境变量手册，环境如何塑造一个进程，已核验 2026-10-15。

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

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

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

坏掉的样子

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

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

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

快速验证

在 PID 1 为 systemd 的一次性 Linux 环境中，以管理员身份运行下面的 Python 脚本。它只写入明确命名的临时运行时单元和一个临时工作目录。记录中的环境是隔离容器内的 Debian 12、systemd 252.39。执行前确认两个单元文件名尚未被使用，避免与已有服务混淆：

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

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

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

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

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

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

让生命周期信息真正有用

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

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

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

来源

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

定时任务需要能够安全重跑

Sat, 15 Aug 2026 00:00:00 +0000

调度器启动的是一次尝试，业务关心的通常是某个逻辑任务是否完成。一笔每日额度可能因为报错、重启或人工补跑而尝试多次。如果每次尝试都生成新的身份，重复执行就无法与新工作区分。应使用能够代表预期任务的键，例如任务名称与名义计划时间，并在修改业务状态之前定义重复键的含义。尝试日志中的唯一编号可以保留，但不能代替业务层面的去重身份。

调度触发与业务执行是两件事

不能假设所有调度器都会补跑遗漏工作。普通 cron 的具体行为随实现变化，没有统一补跑承诺。启用 Persistent=true 的 systemd 日历定时器，在停用期间至少错过一次触发时，可以在重新启用后补触发；这不等于把所有错过的时间点逐个重放。Kubernetes 文档也明确说明，某些情况下 CronJob 可能重复创建 Job，或者没有创建对应任务。

因此要先确定业务规则：过时任务直接跳过、每个缺失周期都处理，还是对当前状态做一次校正。去重键应使用名义上的逻辑周期，并明确时区。实际启动时间会随重试变化，不能用于识别同一次计划工作。诊断需要的尝试编号与业务身份应分开记录，这样才能同时看见执行了几次尝试，以及到底完成了几个逻辑周期。

坏掉的样子

先查询有没有处理过，再单独修改数据，存在竞态。两个工作进程可能都看到键不存在，然后都应用业务效果。进程锁也许能阻止一台机器上的重叠运行，却不能让业务更新与完成标记文件自动形成原子操作。如果更新成功后、写标记之前失败，重试就会重复生效；先写标记再执行业务，则可能把尚未发生的工作误记为完成。调整两个步骤的先后顺序不能消除中间窗口。

当业务状态与完成记录位于同一个事务数据库时，应在唯一约束下共同提交。提交之前失败，两者都不应留下；提交之后重试，应识别已经完成的逻辑键。SQLite 的 BEGIN IMMEDIATE 会提前开始写事务，其他写入者可能等待，也可能因为繁忙而失败。超时限制等待长度，并不保证任何并发量下都不会冲突；调用方仍需正确区分重试、失败和重复完成。

这个原子性边界不覆盖外部邮件、支付或 HTTP 调用。本地回滚无法撤销远端已经接受的效果。此类流程需要远端提供合适的幂等契约，或采用持久投递设计并在接收方去重。同一个键如果可能携带不同负载，还需要明确拒绝这种冲突的规则。下面示例始终增加固定额度，因此只验证同一逻辑操作的重复尝试，没有把变更参数的重用键视为新请求。

快速验证

本轮以 Python 3.12.14 与 SQLite 3.53.1 完整运行下列示例，实际使用临时数据库与并发线程。

保存为 idempotent-jobs.py 后运行 python3 idempotent-jobs.py。脚本使用临时 SQLite 数据库和八个工作线程，每个线程建立独立数据库连接。业务效果是给余额增加十个单位；非空主键记录已经完成的每日逻辑额度发放，并与余额修改处于同一个事务中。实验不需要实际修改系统定时器，也不会访问外部服务。

from concurrent.futures import ThreadPoolExecutor
from pathlib import Path
from tempfile import TemporaryDirectory
from threading import Barrier
import json
import sqlite3

with TemporaryDirectory() as directory:
 database = str(Path(directory) / 'jobs.db')
 with sqlite3.connect(database) as connection:
 connection.executescript('''
CREATE TABLE balance (id INTEGER PRIMARY KEY, units INTEGER NOT NULL);
INSERT INTO balance VALUES (1, 0);
CREATE TABLE completed (logical_key TEXT PRIMARY KEY NOT NULL);
''')

 def run(key, fail=False, gate=None):
 connection = sqlite3.connect(database, timeout=10, isolation_level=None)
 try:
 if gate:
 gate.wait(timeout=5)
 connection.execute('BEGIN IMMEDIATE')
 inserted = connection.execute(
 'INSERT INTO completed VALUES (?) ON CONFLICT(logical_key) DO NOTHING', (key,))
 if not inserted.rowcount:
 connection.execute('COMMIT')
 return 'duplicate'
 connection.execute('UPDATE balance SET units = units + 10 WHERE id = 1')
 if fail:
 raise RuntimeError('injected failure before commit')
 connection.execute('COMMIT')
 return 'applied'
 except Exception:
 if connection.in_transaction:
 connection.execute('ROLLBACK')
 raise
 finally:
 connection.close()

 key = 'daily-credit:2026-09-13T00:00:00Z'
 try:
 run(key, fail=True)
 except RuntimeError as error:
 assert str(error) == 'injected failure before commit'
 with sqlite3.connect(database) as connection:
 assert connection.execute('SELECT units FROM balance').fetchone() == (0,)
 assert connection.execute('SELECT count(*) FROM completed').fetchone() == (0,)
 gate = Barrier(8)
 with ThreadPoolExecutor(max_workers=8) as pool:
 results = list(pool.map(lambda _: run(key, gate=gate), range(8)))
 assert results.count('applied') == 1 and results.count('duplicate') == 7
 assert run(key) == 'duplicate'
 assert run('daily-credit:2026-09-14T00:00:00Z') == 'applied'
 with sqlite3.connect(database) as connection:
 units = connection.execute('SELECT units FROM balance').fetchone()[0]
 completed = connection.execute('SELECT count(*) FROM completed').fetchone()[0]
 assert (units, completed) == (20, 2)
 print(json.dumps({'rolled_back_attempt_left_no_state': True,
 'concurrent_applied': results.count('applied'),
 'concurrent_duplicates': results.count('duplicate'),
 'final_units': units, 'completed_logical_jobs': completed}))

第一次尝试在完成插入和余额更新之后、提交之前故意抛出异常。脚本验证回滚之后余额仍为零，也不存在完成键。随后八个工作线程同时处理同一个逻辑时间点，必须只有一个返回 applied，另七个返回 duplicate。唯一键判断与业务修改依靠真实数据库串行化，不是通过假的内存锁预先安排好结果。并发开始屏障让竞争条件实际存在。

成功提交后再重放同一个键，仍然是重复；换成下一个名义日期，才是新的逻辑任务，并再次增加十个单位。最终余额应为二十，完成键应为两个。这个结果覆盖单个 SQLite 数据库中的回滚、并发去重和提交后重放，没有验证调度器一定送达、进程被强制终止时的恢复，也没有证明外部系统的效果可以恰好发生一次。

让失败与完成都能被看见

记录逻辑键、每次尝试的结果、耗时与最近成功完成的业务周期。正常重复与数据库错误要区分；如果捕获所有异常后都标成完成，就会把丢失工作隐藏起来。还要定义完成记录需要保存多久，删除记录后再收到旧重试，可能重新应用业务效果。可用的运行证据应让值班人员判断预期周期是否完成，而不只是证明定时器曾经启动过某个进程。

来源

SQLite: transactions，写入串行化、提交和回滚语义，已核验 2026-10-15。
SQLite: UPSERT，针对指定唯一约束冲突的处理，已核验 2026-10-15。
systemd.timer，持久日历定时器补触发的适用范围，已核验 2026-10-15。
Kubernetes: CronJob，近似调度以及重复或遗漏任务的可能性，已核验 2026-10-15。

最小权限是门槛,不是感觉

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

最小权限是把某项明确工作需要的操作，授予正确主体，并限定资源范围与有效时间。它是一份能够验证的政策，而不是令人安心的标签。应从服务实际启动身份和依赖开始梳理；闲置权限与缺失权限是不同发现，不能用同一种处理方式解决，也不能因为一个接口暂时调用成功就认为边界已经合适。

把最小值写清楚

列出服务读取的文件、写入的目录、需要访问的网络目标以及管理操作，同时覆盖启动、日志、轮转、恢复与退出。业务数据虽然只在一个目录，服务仍可能合理地需要临时空间和共享库。一份有用清单解释每项访问为什么存在，而不是笼统宣称数据目录以外的一切都不必要，更不应遗漏低频但关键的恢复路径。

对 systemd 单元，User= 与 Group= 决定运行身份，文件权限和沙箱设置进一步约束行为。ProtectSystem=strict 使单元视图中的大部分文件系统只读，但 API 文件系统有文档规定的例外，也可能另行开放写入路径。只读不等于不可读；若目的是保护秘密内容，需要独立的访问权限或可见性约束，例如适合当前服务的 ProtectHome= 政策，不能把写入失败当作读取也被隔离的证明。

检验具体边界

不同指令解决不同问题。PrivateDevices= 限制设备暴露，NoNewPrivileges= 防止通过执行程序取得新权限，RestrictAddressFamilies= 限制套接字地址族。最后这一项不是目标地址或端口防火墙。内核支持、系统或用户服务管理器、既有描述符和其他设置，都可能影响实际效果；列出一串指令名称，并不能证明已经拥有完整沙箱。

单项 capability 可能比不受限 root 更窄，却未必是一项很小的权限，其中有些覆盖广泛管理操作。授予之前，应查看它实际允许什么，以及文件所有权、ACL 或独立受限辅助程序能否更好地满足需求。测试时要在真实服务上下文中同时执行一个应允许的操作和一个相邻但应拒绝的操作，分别记录结果，避免管理员手动验证掩盖服务自身边界。

宽权限为什么总会留下来

事件期间的临时授权经常活得比事件更久。应记录负责人、原因和到期或复核时间，使恢复权限不会悄悄成为日常权限。变更后比较线上绑定与获准政策；源码仓库中存在配置文件，并不说明正在运行的工作负载真的使用了它。临时例外需要明确归宿，而不能只靠某个人记得事后撤销。

凭据寿命属于另一项控制。范围较窄的令牌在有效期内仍可被滥用，轮换权限过大的凭据也不会自动减少权限。应使用适当限定的凭据，避免把它们复制到日志或运维手册。复核既要看它能做什么，也要看工作或人员关系结束后如何撤销；权限范围、保存方式与有效时间共同决定暴露，不能互相替代。

坏掉的样子

在 Kubernetes 中，通配动词与资源会在规则的 API 组和绑定范围内授予广泛权限，但并不自动等于跨所有组和命名空间的集群管理员。即便如此，新出现的匹配资源或动词仍可能无需再次修改政策就得到授权。判断实际权限时，需要检查主体、命名空间、资源名和全部叠加授权，不能看到一个很窄的 Role 就认为总权限也一样窄。

一段时间没有使用，只能成为复核线索，不能直接证明权限应删除。恢复操作可能很重要，却不会出现在普通一周的记录里。反过来，某个角色使用过某项动作，也不能成为给所有角色都保留它的理由。使用记录应按身份和角色关联；例外需要业务依据，不能把一份全局动作集合误当作逐角色的授权证据。

过度收紧可能阻断合法发布，并诱使人绕过正规流程。删除权限之前，应提供且验证更窄的受支持路径。身份模拟本身也受权限控制，不是加一个参数就凭空变成管理员。紧急运维流程应保留责任与记录，而不是让工作流转入秘密共享账号，再把正规路径的零授权当成安全成功。

快速验证

保存为 privilege_audit.py，运行 python3 privilege_audit.py。标准库模型回放七次合成请求，另外按每个角色独立的合成复核窗口记录比较授权与使用。它不读取凭据、不查询生产身份，也不修改任何权限，因此可以安全地观察纯集合判定，同时明确实际授权验证仍然另有工作。

ROLES = {
 "api-reader": {"articles:read", "health:read"},
 "deployer": {"articles:read", "articles:publish", "health:read"},
 "ops-admin": {"articles:read", "articles:publish", "secrets:read", "users:write"},
}

# (role, action, should_allow)
REQUESTS = [
 ("api-reader", "articles:read", True),
 ("api-reader", "articles:publish", False),
 ("api-reader", "secrets:read", False),
 ("deployer", "articles:publish", True),
 ("deployer", "secrets:read", False),
 ("ops-admin", "secrets:read", True),
 ("ops-admin", "users:write", True),
]

# Synthetic observations from an independent review window, per role.
USED = {
 "api-reader": {"articles:read", "health:read"},
 "deployer": {"articles:read", "articles:publish", "health:read"},
 "ops-admin": {"articles:read", "articles:publish"},
}


def allowed(role, action):
 return action in ROLES.get(role, set())


for role, action, expected in REQUESTS:
 decision = allowed(role, action)
 assert decision is expected, (role, action, decision)
 print(f"{role:10} {action:17} -> {'allow' if decision else 'deny'}")

for role, granted in sorted(ROLES.items()):
 unused = sorted(granted - USED[role])
 print(f"{role:10} granted={len(granted)} unused={len(unused)} {unused}")
 if role == "ops-admin":
 assert unused == ["secrets:read", "users:write"], unused

assert not allowed("unknown-role", "articles:read")
assert not allowed("api-reader", "unknown:action")
print("PASS: 7 requests match the matrix; ops-admin holds 2 unused grants")

预期出现七行请求结果、三行角色用量和最后的 PASS 行。读取者不能发布或读密钥，发布者不能读密钥；管理员有两项权限没有出现在自己的复核窗口集合中。未知角色与未知动作均被拒绝。请求测试与使用统计是两类独立输入，因此某次合成请求获准，不会自动成为该角色真实使用过权限的证据，更不能直接证明线上发生权限漂移。

修订后的两种语言示例都已在 Linux、Python 3.12.14 下通过。这里仅验证集合授权模型，不执行 systemd 沙箱、Kubernetes 授权、准入政策或令牌过期。生产复核应针对实际执行点逐项测试，并保留应允许与应拒绝的结果；模型通过不能替代那些边界已经生效的证据。

来源

systemd.exec 手册，加固选项，单元级限制选项，已核验 2026-08-12。
capabilities 手册，把 root 拆成细粒度能力，已核验 2026-08-12。
OWASP：最小权限，面向开发者的访问控制实践，已核验 2026-08-12。
Kubernetes RBAC：规则与绑定范围，核对可叠加规则、API 组与绑定范围，已核验 2026-10-15。
systemd 252 上游执行环境手册源码，核对上游 252 版文件系统与地址族沙箱边界，已核验 2026-10-15。

Unix · XB 现场笔记

fork 创建进程，exec 替换其中的程序

坏掉的样子

快速验证

明确启动时的资源所有权

来源

Setuid 在 exec 时改变有效身份

文件位与进程凭据分开观察

执行环境可以抑制转换

降权需要完整设计

坏掉的样子

快速验证

来源

sticky bit 限制共享目录中的删除操作

坏掉的样子

快速验证

有意识地设计共享存储

来源

环境变量属于各自的进程

导出决定另一个程序能收到什么

子 Shell 不等于重新执行一个 Shell 程序

单次调用配置有自己的生命周期

坏掉的样子

快速验证

来源

shell 找不到那条裸命令时

先确认是哪一层查找给出结果

斜杠直接选择路径

坏掉的样子

快速验证

来源

优雅关闭：停止准入，再排空工作

信号开始的是协调过程

截止期限约束完整生命周期

与监督器核对同一份契约

坏掉的样子

快速验证

延伸阅读

来源

让持久状态和临时空间拥有不同生命周期

坏掉的样子

快速验证

让策略跟随数据契约

延伸阅读

来源

命名的配置文件偏爱清晰

文件是一份意图记录

环境变量与文件解决不同问题

密钥仍然要移出去

坏掉的样子

快速验证

延伸阅读

来源

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

坏掉的样子

快速验证

让生命周期信息真正有用

延伸阅读

来源

定时任务需要能够安全重跑

调度触发与业务执行是两件事

坏掉的样子

快速验证

让失败与完成都能被看见

来源

最小权限是门槛,不是感觉

把最小值写清楚

检验具体边界

宽权限为什么总会留下来

坏掉的样子

快速验证

延伸阅读

来源