文章

只读根文件系统限制对服务打包代码和配置所在文件系统层的普通写入，明确挂载仍可提供运行数据的可写位置。这能减少意外修改和部分持久化机会，但边界是文件系统变更本身。它不会单独移除进程权限、阻止读取可访问数据，也不会禁止与其他服务通信，需要按实际作用范围理解其价值。 坏掉的样子 应用经常在主要数据目录之外写入临时文件、缓存、锁文件、生成配置或运行状态。只读根会让这些假设在启动或不常见操作中以 EROFS 暴露。只测健康检查端点，可能漏掉生成报表、刷新缓存或关停清理时才经过的写入路径。因此必须沿真实工作流程检查需求，不能把进程成功启动当成全部功能可用。 即使容器根层只读，可写挂载仍然可写，其中状态仍可能被故障或受损进程改坏。把大块可写目录覆盖到打包路径，也可能抵消这些路径原本需要的保护。应检查最终挂载布局，而不是根据一个根层选项推断整棵路径树的行为。路径看起来位于只读根之下，并不证明中间没有另一个可写挂载。 只读与保密也是不同属性。进程仍可能读取打包文件、执行已有程序，并通过允许的网络路径发送数据。该设置也不保证容器逃逸之后仍受相同保护，更不约束能够改变挂载安排的权限。应结合凭据、能力、隔离和应用行为理解它的贡献，避免把一项文件系统限制描述成完整安全边界。 快速验证 在一次性 Linux 容器内以 root 运行下面 Python 脚本。容器应使用只读根，在 /tmp 挂可写 tmpfs，在 /work 挂独立可写卷，镜像内预先安装 Python 3。实测使用 Linux 6.12.76 和 Python 3.11.2，没有宿主机绑定挂载、特权模式或外部网络： from pathlib import Path from tempfile import TemporaryDirectory import errno,os,socket,subprocess,sys,uuid assert os.geteuid()==0,'run inside a disposable read-only-root container as root' assert os.statvfs('/').f_flag&os.ST_RDONLY name='xbcatm-readonly-'+uuid.uuid4().hex for base in [Path('/'),Path('/usr'),Path('/etc')]: path=base/name try:fd=os.open(path,os.O_WRONLY|os.O_CREAT|os.O_EXCL,0o600) except OSError as error:assert error.errno==errno.EROFS,error else: os.close(fd);path.unlink();raise AssertionError('root filesystem accepted a new file') print('even this root process receives EROFS on paths in the read-only root, usr and etc tree') for base in ['/tmp','/work']: assert not os.statvfs(base).f_flag&os.ST_RDONLY with TemporaryDirectory(prefix='xbcatm-write-',dir=base) as directory: path=Path(directory)/'data';path.write_bytes(b'allowed');assert path.read_bytes()==b'allowed' path.write_bytes(b'changed');assert path.read_bytes()==b'changed' print('explicit tmpfs and data-volume mounts remain writable, including overwriting their contents') assert Path('/etc/os-release').read_text() result=subprocess.run([sys.executable,'-c','print("executed")'],capture_output=True,text=True,check=True) assert result.stdout.strip()=='executed' with socket.socket() as listener,socket.socket() as client: listener.bind(('127.0.0.1',0));listener.listen(1);client.connect(listener.getsockname()) connection,_=listener.accept() with connection: client.sendall(b'local');assert connection.recv(5)==b'local' print('reading packaged files, executing an existing program, and loopback network I/O still work') 脚本先检查根文件系统报告的只读标志，再尝试在根、usr 和 etc 下排他创建唯一名字的文件。即使采用 root 身份，三次都得到 EROFS。唯一名称与排他创建保证探测不会覆盖既有配置文件。结果来自当前文件系统真正拒绝操作，而不是只看配置中出现了某个只读选项。 ...

优雅关闭改变的是服务接收与完成工作的方式，信号只是触发条件。它能够提供的保证比“绝不丢失任何东西”更有限，也更具体：停止接收新的业务工作，记录此前已经接受的任务，在有界时间内等待完成，并在期限耗尽时如实报告剩余工作。仅仅捕获一个信号，并不等于已经实现安全关闭。 信号开始的是协调过程 应用可以处理 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 路由仅用于测试协调，不是建议上线的管理接口。 ...

分布式链路追踪利用共同的链路标识和明确的关系，连接一次请求中被记录下来的操作。一个跨度表示一项操作，带有开始与结束时间、属性、事件和状态。当结账请求依次涉及应用、库存服务和支付服务时，这些信息可以帮助我们还原处理路径。但最终图形取决于哪些位置做了插桩、哪些数据通过采样并成功导出，不能把它当成请求实际执行过的全部动作清单。 链路标识用于归集相关跨度，跨度标识用于区分同一条链路中的具体操作，父跨度标识则连接直接的上游操作。通过 HTTP 跨越边界时，W3C 的 traceparent 请求头携带链路标识、发送端跨度标识和链路标志。接收端必须提取这些上下文，再创建自己的跨度。仅仅在几条互不关联的日志里写入同一个请求编号，并不会自动形成可供追踪系统识别的跨度父子关系。对于由多个上游共同触发的工作，可以用跨度链接表达额外关系，而不是给一个跨度分配多个父级。 链路 A 与 B 是原文两组链路的图解名称，不是真实标识。图解仅依据原文叙述与未执行代码；历史状态仍为已阅读、执行受阻，本次没有重跑或新增运行验证。箭头长度不表示耗时。 先读关系，再分析耗时 一个服务端跨度可能包含数据库操作，也可能包含多个同时进行的外部请求。把所有跨度的时长相加，会重复计算重叠的时间；如果兄弟跨度并发执行，用父跨度时长减去所有子跨度时长，也可能得到毫无意义的负数。应当阅读时间线，判断哪些区间位于影响请求完成的关键路径。跨机器的时钟差异以及缺失的插桩，还会限制我们对图上空白区间的解释精度。 跨度状态也需要单独理解。HTTP 响应码、异常事件和 OpenTelemetry 的错误状态是三份不同的信息，插桩库可能依据自己的约定将它们关联起来。手工记录异常时，不能因此假定所有有关的状态字段都已经改变。服务名称等资源属性回答数据由哪个服务发出，而某个跨度的名称、属性和事件回答该服务中发生了什么操作。混淆这两个层次，会使跨服务排查失去可靠的定位依据。 坏掉的样子 代理可能丢弃传播请求头，接收服务也可能没有调用上下文提取逻辑。此时业务请求已经成功抵达下游，但下游工作在追踪系统里属于另一条链路。还有一种错误是链路标识相同，父跨度却连接错误：数据看似聚到一起，实际因果位置已经不对。验证一个服务边界时，既要检查链路标识，也要检查直接父跨度，不能只确认后端收到了几条跨度就宣布传播正确。 ...

命令行 HTTP 请求提供一个范围较小、容易检查的服务视角：不用经过浏览器渲染，就能看到状态、响应头、正文和耗时。开始之前先明确问题，是检查原地址是否正确跳转、最终页面能否读取，还是某种请求方法是否被接受。不同问题需要不同探测方式。一条 curl 命令成功，只能说明这次请求满足了对应条件，不能证明网站所有功能都正常，也不能直接代替用户实际访问路径的验证。 先确定问题再选择选项。这里是固定文章夹具的结果，不是新的执行证据；文章审核与执行仍待完成。 分开保存四类证据 默认情况下，curl 输出响应正文，即使 HTTP 表达错误，进程也可能成功退出。命令退出状态描述传输工具的结果，HTTP 状态则描述已经收到的响应，两者都应该保留。收到正文为“missing”的四零四响应，与根本没有取得 HTTP 响应的连接失败，并不是同一种故障。监控脚本需要明确判断自己关心的响应契约，不能只靠 shell 有没有返回非零状态。 ...

常规 Linux 容器通过守护进程所在宿主的 Linux 内核运行进程，并利用命名空间提供选定的隔离视图。镜像文件提供用户态环境，不会给每个容器单独启动一个内核。在 macOS 的 Docker Desktop 中，守护进程和 Linux 容器位于 Linux 虚拟机里，所以容器共享的是该虚拟机内核，而不是 macOS 内核。讨论“宿主”时必须说清楚这一层。 图示普通独立命名空间配置，容器共享守护进程一侧的 Linux 内核；命名空间、资源限制与安全策略解决不同问题。 坏掉的样子 假定每个容器都有独立操作系统内核，会导致错误诊断。如果守护进程所在 Linux 环境缺少某个内核能力，仅换成包含另一发行版用户态文件的镜像，并不会让该能力出现。反过来，升级镜像内的软件包，也不会升级宿主内核。这个区别影响系统调用、内核模块、安全边界和资源统计，不能用容器里显示的发行版名字代替判断。 命名空间隔离可以配置，不是每次部署都完全相同的固定组合。容器可以加入其他网络命名空间、使用宿主网络、共享卷，或者采用不同的用户命名空间映射。看到容器内 UID 为零，也不能直接判断容器外权限；必须结合能力集合、用户映射、安全策略和暴露资源分析。一个数字或名称不足以描述完整安全边界。 ...

文件锁协调的是一组参与者：大家约定锁哪个对象、何时获取锁，以及哪些操作必须放在临界区内。Linux 提供多种锁接口，它们的所有权和释放规则并不相同。选一个文件名，再调用名称里带 lock 的函数，并不足以构成正确协议；还必须明确底层对象、锁的种类，以及相关每份引用的寿命，否则看起来都成功加锁的程序仍可能同时修改同一份逻辑数据。 图示限于本地 Linux 语义；参与者须使用同种锁与稳定对象。建议锁不阻止普通写入，重建锁文件可能分离所有权；互斥不等于持久化。 坏掉的样子 在本实验使用的 Linux 本地文件系统上，flock 提供建议式互斥。另一个请求冲突锁的进程会等待或失败，但完全没有请求锁的普通写入仍然可以进行。因此，文件锁不会赋予内容隐私，也不会自动限制所有能够打开文件的程序。只有参与者实际遵循共同协议，互斥才能保护需要保持一致的数据操作。 如果更新通过新 inode 替换原路径，直接锁数据文件就会出现对象分离。已有锁仍关联旧的打开文件描述，后续打开者却访问替换后的文件，并可能成功获取另一把锁。两个写者都以为自己独占同一份逻辑文档，实际锁住的却是不同对象。路径名称稳定，并不意味着路径背后的文件身份稳定。 传统 POSIX 记录锁还具有容易忽略的寿命规则：锁属于进程，该进程关闭任何一个指向该文件的描述符，都会释放它在该文件上持有的记录锁。因此，某个库独立打开并关闭同一 inode，也可能使程序其他位置持有的锁失效。这与通过打开文件描述拥有锁的 flock 不同，不能把两套释放规则混用。还要注意，通过任意复制引用显式解锁，也会释放同一把 flock；其他复制描述符仍然打开，并不能抵消显式解锁。 快速验证 把脚本保存为 locking.py，在一次性 Linux 环境中运行 python3 locking.py。实测环境为 Linux 6.12.76、Python 3.11.2 和本地 tmpfs。每个竞争锁的请求都在独立子进程中执行，并使用非阻塞获取，因此预期冲突会产生可检查结果，不会让演示一直挂起： ...

Link 响应头描述当前资源与其他资源之间的关系。一个返回 JSON 的接口可以用它给出下一页，让客户端不必解析 HTML，也不必猜测分页参数。这个字段提供目标地址和关系类型，是否访问仍由客户端决定。它是可供理解的元数据，不是强制浏览器下载资源、要求爬虫收录页面或授予访问权限的指令。 相对于有效请求地址解析返回的目标。保留关系语法，并分别处理目标策略与浏览器暴露规则。 链接包含上下文与目标 例如 </items?cursor=b>; rel="next"，表示从当前上下文资源指向指定目标。没有显式的 anchor 参数时，上下文通常是被请求的资源。相对目标应根据重定向之后的有效请求地址解析，不能根据程序工作目录或想象中的接口根路径拼接。只包含查询串的目标会替换查询参数而保留路径，这与以斜杠开头、从站点根部解析的地址不同。 rel 指出关系类型，注册关系包括 next、prev、alternate 和 canonical，扩展关系还可以使用 URI 标识。type="application/json" 等参数描述的是目标资源，不会改写当前响应实际的内容类型，也不保证目标可信。如果一个链接通过 anchor 改变了上下文，无法处理这种上下文的客户端就不应擅自把它解释成当前页面的关系，否则链接含义已经改变。 ...

调用方需要的不只是三位数字，还要知道是否收到 HTTP 响应、正文是否完整到达，以及应用结果是否满足预期操作。这是三个不同的问题。二百响应可以按既定契约携带应用层失败，也可能在响应头之后发生传输中断；没有收到响应之前就连接失败，则根本没有 HTTP 状态。诊断和指标应保留这些区别，不能把它们压成一个过于简单的成功标志。 按实际取得的证据分类 HTTP 错误响应仍然是一份响应，其中可能包含有用的表示、认证挑战、请求标识或 Retry-After 字段。有些客户端库会为四开头和五开头状态抛出异常，但仍允许读取这些信息。处理时应先捕获具体 HTTP 异常，再处理更宽泛的传输异常；否则，一个带明确限流提示的四二九，就可能被归成和连接失败完全相同的通用网络错误，丢失下一步判断依据。 HTTP 交换成功也可能只代表业务信封成功传递。例如批处理或 RPC 契约可以返回二百，同时在正文里说明某个子操作失败。应读取文档定义的结构，而不是默认这种响应里的业务全部成功，也不能断言所有此类接口都违反 HTTP。监控需要验证自己承诺监控的结果；如果业务契约要求检查正文，那么只读状态码就没有完成相应检查。 坏掉的样子 在收到响应头时记录状态，可能掩盖随后出现的正文截断。Content-Length、流结束、解压与解析，都影响最后是否得到可用表示。应把已经收到的状态与未完成的传输分别报告，不能因为状态指标已经计入二百，就把只有半份内容的响应视为应用成功。收到响应头，是比完整收到并理解业务结果更早的一个验证点。 是否重试也不能只看第一位数字。四二九表示请求受到限流，可以附带 Retry-After；五零三也可能建议等待。该字段可以使用延迟秒数或 HTTP 日期，但两种形式都没有保证服务器到时一定恢复。客户端应结合服务器提示、有界重试策略、退避和操作语义，避免一遇到错误就立即重放。等待提示不是无限重试的授权，也不是恢复成功的证据。 非幂等请求的响应丢失，可能让业务效果处于未知状态：客户端失去联系之前，服务器也许已经提交。没有合适的幂等契约就重复操作，可能产生重复工作。另一方面，有些四开头错误会随着身份、状态或限流条件改变而变得可恢复。按照整个类别制定“总是重试”或“绝不重试”，会抹掉真正需要用于决策的信息，而不是简化正确的处理逻辑。 状态码本身也不能说明究竟是哪一个组件生成了响应。源站、网关和中间层都可能返回错误，归因时应结合请求标识与相应日志。curl 的 000 一类诊断值，不是注册的 HTTP 响应状态，通常表示没有取得可用的 HTTP 状态。把它当成某种服务器错误，会把连接阶段的问题错误地归到已经收到响应之后的处理阶段。 快速验证 将脚本保存为 status-client.py 并执行 python3 status-client.py。临时回环服务器提供五种响应情况；客户端使用真正的 urllib 响应对象和异常机制，并为实验关闭代理路由，不进行自动业务重试。另一个已经绑定但没有开始监听的回环端口用于产生拒绝连接，不需要访问外部主机，也不会依赖某个远端服务恰好离线。 from http.client import IncompleteRead from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer from threading import Thread from urllib.error import HTTPError, URLError from urllib.request import ProxyHandler, build_opener import json import socket class Handler(BaseHTTPRequestHandler): def do_GET(self): if self.path == '/application-error': status, data, retry = 200, b'{"ok":false,"error":"demo"}', None elif self.path == '/busy': status, data, retry = 503, b'{"error":"unavailable"}', '3' elif self.path == '/limit': status, data, retry = 429, b'{"error":"limited"}', '2' else: status, data, retry = 404, b'{"error":"missing"}', None if self.path == '/truncated': self.send_response(200) self.send_header('Content-Length', '100') self.end_headers() self.wfile.write(b'partial') return self.send_response(status) self.send_header('Content-Type', 'application/json') self.send_header('Content-Length', str(len(data))) if retry: self.send_header('Retry-After', retry) self.end_headers() self.wfile.write(data) def log_message(self, *args): pass opener = build_opener(ProxyHandler({})) def inspect(url): try: try: response = opener.open(url, timeout=3) except HTTPError as error: response = error with response: result = {'http_status': response.code, 'retry_after': response.headers.get('Retry-After')} try: body = response.read() except IncompleteRead: return {**result, 'complete_body': False} return {**result, 'complete_body': True, 'payload': json.loads(body)} except URLError: return {'http_status': None, 'transport_failure': True} server = ThreadingHTTPServer(('127.0.0.1', 0), Handler) thread = Thread(target=server.serve_forever) thread.start() try: origin = f'http://127.0.0.1:{server.server_port}' results = {path: inspect(origin + path) for path in ('/application-error', '/busy', '/limit', '/missing', '/truncated')} with socket.socket() as reserved: reserved.bind(('127.0.0.1', 0)) # Bound without listen: no HTTP server on this port. results['connection-refused'] = inspect(f'http://127.0.0.1:{reserved.getsockname()[1]}/') assert results['/application-error']['http_status'] == 200 assert results['/application-error']['payload']['ok'] is False assert results['/busy']['http_status'] == 503 and results['/busy']['retry_after'] == '3' assert results['/limit']['http_status'] == 429 and results['/limit']['retry_after'] == '2' assert results['/missing']['http_status'] == 404 assert results['/truncated'] == {'http_status': 200, 'retry_after': None, 'complete_body': False} assert results['connection-refused'] == {'http_status': None, 'transport_failure': True} print(json.dumps(results)) finally: server.shutdown() thread.join() server.server_close() 应用信封返回 HTTP 二百与 ok: false。繁忙和限流端点分别返回五零三、四二九，并保留 Retry-After 的三秒和两秒文本值。缺失端点仍被记录成 HTTP 四零四，而不是传输错误。这四份正文在本实验中均完整且可解析，因而能够进一步判断其业务字段；脚本没有实际等待这些延迟，也没有宣称等待后一定成功。 ...