服务 · XB 现场笔记

Consul 发现结果取决于健康策略与新鲜度

Thu, 06 Apr 2028 00:00:00 +0000

Consul 服务发现提供注册端点和已经记录的健康观测，不能承诺每个返回端点都会成功响应调用方的下一次请求。实用的运维模型需要分开四件事：注册了什么、哪些检查与该实例有关、查询接受哪些状态，以及这些观测可能已经过去多久。仅仅成功解析到一个地址，并没有自动建立上述全部保证，也没有证明业务请求已经能够完成。

注册记录与健康状态是两回事

catalog 存储注册信息，健康端点再附上检查结果。不加过滤的 /v1/health/service/web 响应，可以包含检查为 critical 的实例。检查失败并不会自动抹去服务注册；显式注销、配置了持续 critical 后自动移除，属于不同的生命周期机制。ACL 也可能影响读者能看到哪些记录，所以查询里缺少实例，不能只归因于健康检查失败。

注册的检查通常从 critical 开始，除非显式提供初始状态。但这并不意味着每个注册服务都一定具有有意义的就绪检查。判断某个服务实例时，需要结合它自己的服务级检查，以及 serfHealth 等节点级检查。同一节点上，数据库服务的检查失败，不会自动让不相关的 Web 服务检查失败；节点级检查变为 critical，则会影响该节点上的服务。不要把“相关检查全部通过”误解成“这台机器上的所有服务检查都必须通过”。

检查结果也不只是布尔值。脚本退出码零表示 passing，一表示 warning，其他退出码表示 critical；HTTP 检查把成功的 2xx 视为健康，把 429 视为 warning，其他响应表示失败。这些状态究竟证明了什么，仍取决于探测内容。TCP 握手成功或进程存在，并不证明应用能完成一次真实请求；检查实现必须与希望验证的能力对应。

DNS 并非总是只返回 passing

HTTP 健康端点的 passing=true 要求相关检查全部 passing。Consul DNS 服务查询的默认策略不同：warning 实例仍可符合候选条件，critical 实例则被排除。配置 dns_config.only_passing=true 后，warning 也会被排除。因此，一个 warning 实例出现在 DNS，却不在 passing-only API 结果里，不一定意味着检查失效，也可能只是两条路径明确采用了不同策略。

比较结果时，应保持服务、数据中心、适用时的命名空间，以及观察时间窗口一致。Consul 的 DNS 通常监听 8600 端口；如果没有配置相应转发，只向系统解析器查询，并不是直接检查 Consul。直接查询能够去掉这一中间环节，但仍然不会自动从调用方网络探测业务端点，也不能证明返回地址在所有网络路径上都可达。

新鲜度包含多个阶段

探测间隔、探测超时、连续失败阈值、agent 到 server 的传播、读取一致性，以及客户端缓存，都可能增加延迟。三十秒间隔不等于端到端三十秒内必定摘除。TTL 检查从最近一次更新计算到期；如果服务在 TTL 中途失败，并不一定还会获得完整的一段新 TTL。应观察真实状态转移，不能把一个配置数字当成所有故障路径的精确上界。

反熵负责修复 agent 本地状态与 catalog 的差异。文档中的周期随集群规模变化，而且是近似间隔；注册变更本身也会触发更新。如果同步持续失败，差异可以跨越多个周期，因此周期同步既不是唯一更新机制，也不是最长收敛时间的保证。网络不可达、权限错误或存储故障，不会因为下一分钟到来就必然消失。

HTTP 查询通常使用 default 一致性模式，DNS 通常允许 stale 读取。consistent HTTP 读取要求 leader 向多数派确认身份，会付出额外代价。然而，更强的 catalog 读取一致性，也无法发现尚未被任何检查观测到的应用故障。注册状态的一致性与真实业务的就绪程度，始终是不同问题，不能互相替代。

坏掉的样子

passing 探测可能检查了错误依赖、从不同网络发起，或者遗漏死锁。反过来，如果每个实例的就绪状态都绑定到同一个共享依赖，共同故障又可能一次摘除整个池。应围绕可用的请求能力和预期降级行为选择检查，同时保留客户端超时及有界恢复路径，不能把注册表当成消除所有请求失败的机制。

不要根据一张 API 与 DNS 不一致的截图就宣布检查没有运行。先检查 warning 策略、相关检查 ID、ACL 可见性、注销行为，以及缓存或陈旧观测。critical 实例继续出现在未过滤的健康响应里，本来就是正常现象，不是服务器忽略过滤条件的证据。只有先确认比较对象与策略，才有依据继续追查异常。

快速验证

把代码保存为 consul_filter.py，执行 python3 consul_filter.py。这个标准库实验使用合成记录，不启动 Consul agent，不发网络请求。它验证筛选差异和陈旧快照风险，并不是 Consul 运行时实现的集成测试。

from copy import deepcopy

nodes = {"n1": "passing", "n2": "critical"}
services = [
 {"ID": "web-1", "Name": "web", "Node": "n1", "Status": "passing"},
 {"ID": "web-2", "Name": "web", "Node": "n1", "Status": "warning"},
 {"ID": "db-1", "Name": "db", "Node": "n1", "Status": "critical"},
 {"ID": "web-3", "Name": "web", "Node": "n2", "Status": "passing"},
]


def health_rows(name):
 # Synthetic snapshot: only the node and THIS service contribute checks.
 return [
 {"ID": item["ID"], "Checks": [nodes[item["Node"]], item["Status"]]}
 for item in services if item["Name"] == name
 ]


def selected(rows, allowed):
 return [row["ID"] for row in rows if all(s in allowed for s in row["Checks"])]


snapshot = health_rows("web")
assert [row["ID"] for row in snapshot] == ["web-1", "web-2", "web-3"]
assert selected(snapshot, {"passing"}) == ["web-1"]
assert selected(snapshot, {"passing", "warning"}) == ["web-1", "web-2"]
print("unfiltered: web-1 web-2 web-3; passing-only: web-1; default DNS policy: web-1 web-2")

previous = deepcopy(snapshot)
services[0]["Status"] = "critical"
current = health_rows("web")
assert selected(previous, {"passing"}) == ["web-1"] # An old snapshot stays old.
assert selected(current, {"passing"}) == []
assert len(current) == 3 # Failing health is not deregistration.
assert selected(current, {"passing", "warning"}) == ["web-2"]
print("service failure changes selection, not registration; an old snapshot still selects web-1")

nodes["n1"] = "critical"
assert selected(health_rows("web"), {"passing", "warning"}) == []
print("node failure excludes both web instances on n1; db-1 never controlled their earlier health")

断言证明不相关的数据库健康不会控制 Web 选择，warning 与 critical 在两种策略下不同，而失败注册仍保留在未过滤视图中。更新当前状态，也不会改写之前复制的快照。最后将节点状态改为 critical，模型会把该节点上的两个 Web 实例都移出符合 DNS 策略的候选集合。这些结果是确定的集合运算，不是实际测得的服务故障摘除延迟。

部署验收仍需在配置的 warning 策略下，对照真实未过滤与 passing-only 健康响应，以及直接 DNS 查询。分别记录检查状态转换和客户端不再使用实例的时刻。本次没有执行这项集成；离线模型没有提供探测时间测量、DNS 报文证据或可用性保证。把模型的适用范围写清楚，才能避免“断言都通过”掩盖尚未验证的运行链路。

来源

Consul Health API，服务实例、检查、passing 过滤和 ACL 可见性，已核验 2026-10-15。
Consul 健康检查，初始状态、脚本及 HTTP 结果与 TTL 到期，已核验 2026-10-15。
Consul DNS 配置，only_passing 与相关检查，已核验 2026-10-15。
Consul DNS 行为，8600 端口和缓存控制，已核验 2026-10-15。
Consul 一致性，agent 更新及近似反熵周期，已核验 2026-10-15。
Consul 一致性模式，HTTP、DNS 默认模式和多数派确认，已核验 2026-10-15。
Consul 健康检查参考，超时、阈值和 critical 服务注销，已核验 2026-10-15。

socket 激活让服务按需启动

Tue, 01 Feb 2028 00:00:00 +0000

端口永远就绪，而进程只在有人敲门时才起来，这正是少用却沉重的服务该有的妙招。每个闲置守护进程都在花钱：常驻内存、周期性唤醒、补丁面、日志噪音。一台机器上几十个不常用的服务加起来，税交了不少，事一件没干。套接字激活把交易反过来——内核拿着监听套接字，守护进程出生之前它就归系统服务管理器所有，第一个带着真活的连接到了，服务进程才出生。

交接的顺滑让一切透明。客户端照常连端口，不知道家里没人；管理器拉起服务，把已经接受的连接递进去，第一个客户端都不必等两遍。做对了，按需启动和常开除了账单看不出区别——除了首击延迟，这是唯一要诚实预算的成本。

让监听器先等着

systemd 在服务之前先把 socket 打开，第一个连接到来时才启动单元，并把收到的文件描述符交过去。把 ListenStream 配好一次，让 socket 在任何守护进程起来之前就先诞生并绑定好。套接字单元和服务单元按名配对，一个管监听、一个管干活；默认模式把整个监听套接字交给单个服务实例，按连接派生的模式则给简单请求处理配每连接一个实例。

分离还顺手解决了开机排序。不用写脆弱的先后依赖：套接字开机早期就在，客户端随便什么顺序起，连不上就等一等、重试一次，而不是直接报错。排队的连接在内核积压里等着，开机竞态变成了队列深度而不是错误。当然积压长度也要调：启动慢的服务遇上开机早期的连接洪峰，溢出起来和普通监听队列一样。

服务按需唤醒

空闲的守护进程可以一直停着，用每实例的内存与启动周期，换一次交接的开销。所以套接字激活的服务可以一直睡，直到第一个请求值得它跑起来。这套最适合管理工具、老协议网关、定期但罕见的任务——闲忙比按天算、不按分钟算的服务。

闲时退出补上闭环：服务空闲若干秒自己停，系统在零成本和满能力之间振荡，不用人管。套接字从不关闭，下一个客户端透明触发下一次启动。没有闲时退出，激活只省了开机内存，进程还是越积越多——按需启动加闲时停止成对出现，妙招才变成稳态节省。

用速度换内存

代价是第一次访问有一段短暂热身，这适合很少跑的任务，而对始终热呼的路径很浪费。在首次调用的延迟可接受、而内存节省真的有意义时才开启它。动手前两边都量化：从连接到首个响应的冷启动耗时，常开会永远占住的常驻内存。启动三百毫秒换八百内存，大胆开；预热二十秒换五十内存，算了。

有些负载无论如何都受不了这个间隙。靠健康检查编排的系统会在启动期判端点死亡，负载均衡会摘掉首个慢后端，超时卡得紧的客户端没等服务热完就失败了。这些就让守护进程常开，内存该花就花——或者开机时预热一次，激活只覆盖之后漫长的闲置。

坏掉的样子

标志性故障是惊群式启动：监控扫一轮，五十个睡着的服务同时被连醒，同时启动，主机内存告急、负载冲顶，服务大面积变慢。每个激活单独看都合理，合在一起就是踩踏。用错峰检查间隔、按服务的启动限制、足够短的闲时退出，把稳态重叠压小。测试激活要在监控负载下测，不只拿一条手工请求测。

第二种故障是半吊子适配：服务认定套接字归自己，启动时自己绑端口，和管理器已绑的套接字撞车。被激活的那一刻恰恰启动失败，连接挂住，日志怪地址已被占用。服务必须接受递进来的文件描述符而不是自己绑；上游代码改不动，就写个小垫片继承套接字再拉起守护进程过渡。

快速验证

端到端验证按需行为：

systemctl status foo.socket foo.service
ss -ltnp | grep ':8080'
curl -m 10 localhost:8080/health; systemctl show foo.service -p ActiveState,ExecMainStartTimestamp

请求之前服务未激活、套接字在监听；请求之后时间戳显示一次由连接触发的新启动。

来源

systemd.socket 手册，套接字单元官方参考，已核验 2026-06-01。
systemd.service 手册，服务单元行为与闲时退出，已核验 2026-09-05。

Linger 延长 systemd 用户管理器在登录之外的寿命

Tue, 20 Apr 2027 00:00:00 +0000

Linger 改变的是一个账号的 systemd 用户管理器在什么时候保持可用。启用后，logind 可以在开机时启动该管理器，并在该账号登录会话结束后继续保留它，从而支持普通账号拥有的无人值守工作。这个标志控制管理器寿命，各个服务仍然遵守自己的激活、失败、停止和安装规则。账号可以没有登录会话，同时有管理器运行，但这不等于所有应用都已经启动。

坏掉的样子

开启 linger 不会自动启用账号配置目录里的每一个单元文件。服务仍需要通过启用关系、依赖、定时器、套接字或其他明确路径受到激活。因此管理器可能完全正常，目标应用却保持非活动。应同时检查两者，而不能把一个 linger 标志理解成当前所有服务的运行清单，更不能仅凭它存在就认定某个后台端口已经提供业务响应。

进程不会跨过整台机器重启继续存活。Linger 可以让新的用户管理器在开机时启动，已启用单元再创建新的进程，原来的内存状态已经消失。加密家目录或较晚挂载的路径，也可能让配置和应用数据在管理器启动时不可用。需要保留的状态应持久化，开机依赖应明确安排，不能靠“会跨重启”这种模糊说法跳过实际恢复过程。

Linger 也不是让崩溃应用无限重启的指令，不会自动把任意 shell 后台任务纳入服务管理。重启策略、资源限制和 logind 对会话进程的处理，分别属于不同控制。稳定的后台角色需要真实用户单元和可观察结果，不能只依赖登出前启动过一个命令，再把账号管理器继续存在当成那个命令必然受控运行。

快速验证

在具备 systemd、logind、用户 D-Bus 支持与账号管理工具的一次性 Linux 系统中，以管理员身份运行下面的 Python 脚本。实测环境为 Debian 12、systemd 252.39。它创建临时账号和家目录，只为该账号开启 linger，最后回收本次改动，全程不为这个账号建立登录会话：

from pathlib import Path
from tempfile import TemporaryDirectory
import os,pwd,subprocess,time,uuid

name='xbcatm-linger-'+uuid.uuid4().hex[:8];unit='field-worker.service'
def run(*args):
 result=subprocess.run(args,capture_output=True,text=True,timeout=20)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def wait_for(check,seconds=5):
 deadline=time.monotonic()+seconds
 while not check():
 assert time.monotonic()<deadline,'state transition timed out';time.sleep(0.05)
with TemporaryDirectory(prefix=name+'-',dir='/run') as directory:
 root=Path(directory);root.chmod(0o755);home=root/'home';home.mkdir()
 run('useradd','--no-create-home','--user-group','--home-dir',str(home),'--shell','/bin/sh',name)
 account=pwd.getpwnam(name);uid=account.pw_uid;gid=account.pw_gid;manager=f'user@{uid}.service'
 def userctl(*args):
 return run('setpriv','--reuid='+str(uid),'--regid='+str(gid),'--init-groups',
 'env',f'XDG_RUNTIME_DIR=/run/user/{uid}',f'DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/{uid}/bus',
 'systemctl','--user',*args)
 def manager_value(key):return run('systemctl','show',manager,'-p',key,'--value')
 try:
 units=home/'.config/systemd/user';units.mkdir(parents=True)
 (home/'worker.py').write_text("from pathlib import Path\nimport os,time\np=Path(__file__).with_name('worker-pid');t=p.with_suffix('.tmp');t.write_text(str(os.getpid()));t.replace(p)\ntime.sleep(60)\n")
 (units/unit).write_text('[Service]\nType=exec\nExecStart=/usr/bin/python3 %h/worker.py\n[Install]\nWantedBy=default.target\n')
 for path in [home,*home.rglob('*')]:os.chown(path,uid,gid)
 run('loginctl','enable-linger',name)
 wait_for(lambda:Path(f'/run/user/{uid}/bus').exists())
 assert run('loginctl','show-user',name,'-p','Linger','--value')=='yes'
 assert run('loginctl','show-user',name,'-p','Sessions','--value')==''
 assert manager_value('ActiveState')=='active'
 assert userctl('show',unit,'-p','ActiveState','--value')=='inactive'
 print('linger starts a manager with zero login sessions; merely installing a user unit does not start it')
 userctl('enable','--now',unit);wait_for(lambda:(home/'worker-pid').exists())
 first=(home/'worker-pid').read_text();first_manager=manager_value('MainPID')
 run('systemctl','restart',manager)
 wait_for(lambda:Path(f'/run/user/{uid}/bus').exists() and (home/'worker-pid').read_text()!=first)
 assert manager_value('MainPID')!=first_manager
 assert userctl('show',unit,'-p','MainPID','--value')==(home/'worker-pid').read_text()
 assert run('loginctl','show-user',name,'-p','Sessions','--value')==''
 print('enabled user service starts as a new process after a real manager restart')
 userctl('disable',unit)
 assert userctl('show',unit,'-p','ActiveState','--value')=='active'
 print('disable removes future enablement but does not stop the current service')
 userctl('stop',unit);run('loginctl','disable-linger',name)
 wait_for(lambda:manager_value('ActiveState')=='inactive',seconds=20)
 print('with no sessions and linger disabled, user manager stops after policy delay')
 finally:
 run('loginctl','disable-linger',name)
 run('systemctl','stop',manager,f'user-runtime-dir@{uid}.service')
 run('userdel',name)

执行启用后，用户管理器变为活动，其总线端点出现，logind 报告 linger 已开启、会话列表为空。但已经安装的工作单元仍然非活动。这证明让管理器保持可用，与请求某个应用运行，是不同操作；即使文件已经出现在正确配置目录中，也还需要符合实际契约的激活入口。

随后脚本通过正确用户管理器启用并启动工作服务。安装段把它连接到用户默认 target，显式启动则开始当前执行，进程标记记录真正的工作者编号。控制器通过 setpriv 和用户运行时总线操作，不会悄悄建立登录会话。因此后续看到服务运行，不能归因于控制命令本身意外延长了某个会话。

重启系统层的 user@UID.service 后，账号管理器被替换，已启用的工作服务随后写出不同进程编号，新用户管理器也报告同一个新工作者，会话列表仍为空。这里验证的是根据保存的单元启用关系，在真实管理器重启后重新构建运行状态，而不是仅仅观察原进程多活了一段时间。新的进程身份也直接说明恢复与延续不是同一件事。

仅禁用工作服务、没有请求停止时，当前服务仍然活动。禁用移除的是后续启用链接，不是隐式终止命令。脚本检查这个差别，再显式停止工作者、关闭 linger；没有剩余会话时，账号管理器按停止策略回到非活动。因此停当前工作、改变未来激活和改变管理器寿命，需要分别表达和核对。

清理过程在需要时再次关闭 linger，停止实验管理器和运行时目录单元，删除临时账号与家目录。实验有意使用临时配置，没有重启整台机器。正文涉及开机的语义来自文档契约，实际观测到的进程替换来自管理器重启，不能冒称已经完成了机器重启验证。正式部署若要求开机可用，仍应在对应环境检验这个阶段。

有意管理无人值守账号

保持账号启用单元可审阅，及时移除不再需要的服务。登出后仍然可用的服务可能持续持有内存、打开的文件、凭据与网络监听器。普通用户权限限制了部分动作，但该身份已经获得的访问仍然存在，因此应按工作负载配置合适权限和受支持资源控制，不能把非 root 当成完全不影响共享系统的保证。

配置与凭据应通过无需交互 shell 的机制供应。终端中成功启动一次，不证明无人登录时具有相同环境；需要核对工作目录、输入路径和管理器重启后的访问。当开机可用是部署要求时，再执行真实开机验证。这样才能发现家目录挂载、环境变量或外部依赖只在交互登录后才成立的问题。

退役后台角色时，应区分禁用服务、停止当前执行、关闭 linger 和删除账号数据，其他会话或激活入口也可能继续影响结果。完成目标操作后，检查账号管理器及服务的真实状态。有效保证是一套写清楚的无人值守生命周期，具有明确激活与停止方式，而不是承诺某一个进程编号永远存活。

来源

systemd 252 loginctl，启用与禁用按账号的 linger 并检查会话，已核验 2026-09-12。
systemd 252 user@.service，账号管理器与运行时目录生命周期，已核验 2026-09-12。
systemd 252 logind.conf，用户停止延迟以及会话与用户服务的区别，已核验 2026-09-12。
systemd 252 systemctl，启用与禁用以及启动与停止的不同效果，已核验 2026-09-12。

服务 · XB 现场笔记

Consul 发现结果取决于健康策略与新鲜度

注册记录与健康状态是两回事

DNS 并非总是只返回 passing

新鲜度包含多个阶段

坏掉的样子

快速验证

来源

socket 激活让服务按需启动

让监听器先等着

服务按需唤醒

用速度换内存

坏掉的样子

快速验证

延伸阅读

来源

Linger 延长 systemd 用户管理器在登录之外的寿命

坏掉的样子

快速验证

有意管理无人值守账号

延伸阅读

来源