etcd 成员进程退出码 0、1、2、130、143 分别代表什么如何判断是否属于正常退出【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd运维或排障 etcd 集群时成员进程退出后进程退出码是判断正常停机还是异常退出的第一个线索。etcd 仓库自带一份退出码参考文档 exit_codes.md其中明确etcd server 显式使用三个退出码——0success、1general errors、2argument errors在 Linux/Unix 系统上被 SIGTERM/SIGTERM 信号终止时退出码取决于进程类型PID 1 进程以 0 退出非 PID 1 进程会重新向自身发送信号最终退出码为 143SIGTERM或 130SIGINT。五个退出码速查退出码含义触发条件文档原文0成功正常关闭、--help、--version或 PID 1 进程收到信号后优雅关闭1一般错误各类启动/运行期 fatal 错误日志器创建失败、flag 校验失败、discovery 失败、listener 失败等2参数错误命令行 flag 解析失败130SIGINTCtrl-C终止128 2Linux/Unix 上的非 PID 1 进程143SIGTERM 终止128 15Linux/Unix 上的非 PID 1 进程平台差异需要注意130/143 这一128 信号编号的行为是 Linux 平台特有的。文档说明在其他平台上etcd 退出时通常无错误返回 0否则返回 1所以同一份退出码判断逻辑不能直接套用到非 Linux 环境。退出码 0如何判断是正常退出文档为退出码 0 列出四类场景对应的源码位置如下行号以当前仓库源码为准Help 标志--help打印帮助信息后以os.Exit(0)结束见 config.goVersion 标志--version打印版本号后以os.Exit(0)结束见 config.go正常关闭主流程在 stopped 通道关闭后调用osutil.Exit(0)见 etcd.goPID 1 进程收到信号后的优雅关闭信号处理逻辑里若进程 PID 为 1内核不会协助杀死 PID 1直接os.Exit(0)见 interrupt_unix.go。也就是说看到 0 就可以认定进程走的是成功路径要么完成了打印帮助/版本这类一次性任务要么完成了正常或优雅关闭。退出码 130 / 143如何判断是被信号触发对 Linux/Unix 上的非 PID 1 进程信号处理流程interrupt_unix.go是通过signal.Notify监听 SIGINT 和 SIGTERML52-L53收到信号后先记录日志received signal; shutting down日志中带signal字段标明收到的信号L65依次执行已注册的 InterruptHandleretcd 在启动时注册了e.Close用于关闭 server见 etcd.go将信号恢复为默认处理并重新向自身Kill该信号L76-L77由内核把退出码设为 128 信号编号SIGINT → 130SIGTERM → 143。因此 130/143 出现时的判断方法是先确认退出时刻是否有发送信号的操作Ctrl-C、kill -TERM pid、服务管理器的 stop 动作若有且日志中存在received signal; shutting down说明进程先执行了关闭逻辑再被信号结束属于预期内的停机。可以在前台复现这一路径# 前台启动 etcd进程退出后在 shell 中查看退出码 etcd echo $? # 进程退出后打印退出码可选分支——主动验证 SIGTERM 得到 143kill -TERM etcd PID # 将 etcd PID 替换为 etcd 进程的实际 PID发送信号后etcd 日志应记录received signal; shutting down随后 shell 中$?为 143。如果 etcd 是以 systemd 服务方式运行的仓库中的示例 unit 文件 etcd.service 配置了Restartalways和RestartSec10s无论以哪个退出码结束包括 14310 秒后进程都会被重新拉起。排查为什么成员进程反复出现时需要把退出码和这组重启策略放在一起看。退出码 1按日志定位具体错误文档列出了所有以 1 退出的场景每个场景在源码中都有对应的、先于退出打印的日志信息。退出码本身不区分错误类型需要对照日志场景文档表述关键日志信息代码位置Failed to create loggererror creating zap logger %vetcd.goFailed to verify flagsfailed to verify flagsetcd.goDiscovery token already usedfailed to bootstrap; discovery token was already used并提示do not reuse discovery token; generate a new one to bootstrap a clusteretcd.goInitial cluster configuration errorfailed to start并可能提示forgot to set --initial-cluster?、forgot to set --initial-advertise-peer-urls?etcd.goDiscovery faileddiscovery failedFataletcd.goListener failedlistener failedFataletcd.goFailed to list data directoryfailed to list data directoryFataletcd.goInvalid datadir (member proxy 同时存在)invalid datadir; both member and proxy directories existFataletcd.goUnsupported architectureRefusing to run etcd on unsupported architecture since ETCD_UNSUPPORTED_ARCH is not setetcd.goGeneric fatal error见 util.goutil.go无效的 listen/advertise 类 URL 配置listen-peer-urls、listen-client-urls、listen-client-http-urls、initial-advertise-peer-urls、advertise-client-urls、listen-metrics-urlsunexpected error setting up 对应配置项: ...embed/config.go比如发现退出码 1 且日志中有failed to bootstrap; discovery token was already used就可以直接定位到复用了已使用过的 discovery token这一原因按日志提示重新生成 token而不是盲目重启进程。退出码 2参数解析错误退出码 2 只在命令行 flag 解析失败时触发flagSet.Parse返回既非 nil 也非flag.ErrHelp的错误时直接os.Exit(2)见 config.go。注意--help同样经过这段解析逻辑但命中flag.ErrHelp分支后以 0 退出不会报参数错误。退出码为 2 时检查启动命令中的 flag 拼写和取值。etcd 还支持把ETCD_前缀的环境变量映射为 flag见 config.go 的flags.SetFlagsFromEnv环境变量里的非法取值同样会在这里失败另外如果设置了--config-file其他命令行 flag 和环境变量会被忽略config.go。判断路径小结退出码 0成功路径无需进一步排查退出码 130/143仅 Linux 有意义SIGINT/SIGTERM 触发的停机核对退出时刻是否有主动发送信号的操作并确认日志中有received signal; shutting down退出码 1按上表用退出前的日志信息定位具体错误场景退出码 2回查启动命令与环境变量中的 flag 取值。限制说明130/143 的信号语义只适用于 Linux 平台文档中引用的代码位置指向某一固定提交e0a72cf本文行号以当前仓库源码为准退出码 1 不区分错误类型必须结合日志判断。【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考