文章目录
矿工在 HiveOS 里刚点下启动就退出，面板上给出的提示是 custom exited (exitcode=0), waiting to cooldown a bit，然后把机器留在重启循环里，算力一直是零。很多人看到“冷却”两个字就去查温度，或者直接判定显卡坏了。这两种方向都可能白花时间。
这条报错的信息量集中在括号里。exitcode 决定了这次退出属于正常收工还是异常崩溃，waiting to cooldown 只是 HiveOS 外层脚本的固定动作：进程结束之后先等一会儿，再把它拉起来。要回答的是矿工为什么退出，冷却这一步只是流程本身。
本文按现象、配置、版本、系统镜像、超频与日志这条顺序整理，目标是让现场能靠一份日志定位到具体一层，省掉反复换矿工的试错。
exitcode 为 0 和崩溃是两回事
HiveOS 的矿工运行在一个外层包装里。包装脚本启动矿工进程，进程返回之后读取退出码，打印 exited 加退出码，然后等冷却时间，再重新启动。所以 waiting to cooldown a bit 描述的是一段固定流程，本身不代表故障。
退出码的性质决定了下一步往哪查。exitcode=0 表示进程认为自己完成了任务并正常返回，没有触发异常终止。这类退出的原因通常落在配置层面：矿工拿到了它认为不成立的参数组合，于是干脆不干活。exitcode=1 一般是通用错误，exitcode=139 对应 128 加 11，也就是收到段错误信号，两者更偏向程序或驱动问题。
同一类现象在社区里以多种矿工名出现，包括 lolminer exiting、teamredminer exited、gminer exited，还有 phoenixminer exited (exitcode=139) 和 cpuminer exited (exitcode=0)。它们的处理思路接近，但退出码不同，取证重点也不同。
日志位置是固定的，HiveOS 把每个矿工的输出写在以矿工名命名的目录下。要判断退出瞬间发生了什么，可以在网页版 Shell 或本地终端里先看开头一百行。
cat /var/log/miner/teamredminer/teamredminer.log | head -100
日志为空也是有效信息。如果目录下没有文件，说明矿工根本没走到写出日志的阶段，问题可能停在下载、解压或启动脚本这一层。
双挖页面的第二个币种只保留一个矿池
在能查到的复现记录里，这个报错出现频率最高的原因和双挖有关，而且集中在第二个币种的矿池配置上。飞行表里给第二个币种配了不止一个服务器地址时，矿工拿到一组它无法同时建立的连接，就会直接退出，退出码为 0。
处理方式很直接：进入对应飞行表，打开第二个币种的矿池配置，确认里面只保留了一个服务器，保存后重启矿机。多位遇到同样报错的矿工在只保留一个矿池连接之后恢复运行。
第二个高频原因是 worker 名。在双挖配置里给第二个算法填写了 worker 名，会让部分矿工在拼接连接参数时出错并退出。把第二个算法的 worker 名清空，只保留主算法的 worker 名，是成本最低的一次尝试。有人在社区里明确记录了删除两处 worker 名之后问题消失，也有人反馈无效，所以这一步适合当成免费验证，不必指望它一次解决。
第三个原因是矿池给出的参数格式。部分自定义矿工要求把币种写进密码字段，形式类似 c=币种符号。如果密码字段空着或填了别的值，矿工可能启动后立刻退出。这一项要和矿池自己的接入说明逐字核对，不要照搬其他矿池的示例。
先锁定矿工版本，再动其它参数
HiveOS 的矿工配置里，版本一栏默认可能是 The Latest。这个默认值意味着每次重启都可能换到新版本，而新版本里的参数变动或缺陷正好可以让矿工在启动阶段退出。
把版本从 The Latest 改成一个具体的历史版本，是排查成本很低的一步。改完之后保存飞行表并重启矿机。如果换版本之后报错消失，就基本可以确认是矿工版本的问题，接下来只需要固定在可用版本上，等上游修复再升级。
换矿工是同一层级的动作。teamredminer 退出时报错，可以换成 tdxminer 或 lolminer 试一次；lolminer 退出，可以试 gminer。要注意 HiveOS 在切换到新矿工时需要先下载安装，这个过程通常要十几分钟，期间面板显示不正常属于正常现象。也有人遇到的情况刚好相反，把自定义矿工换回原矿工之后立刻恢复正常，说明故障出在矿工包本身，与机器无关。
驱动与系统镜像的版本梯度
有一类退出和显卡型号绑定得很紧。社区里有矿工反馈多台使用 RX 580 的机器在同一时间段内集体出现 exited (exitcode=0), waiting to cooldown a bit，尝试降级 HiveOS、清空超频、轮换 nbminer、lolminer、gminer、teamredminer，以及更换成 rvn、zelhash、kawpow 等不同币种，都无法恢复。最终的处理是重刷镜像。
判断是否属于这一类，可以看面板上显卡的显存和信息是否正常显示。显存一栏空白，通常指向驱动或硬件这一层，而不是矿池配置。反过来，如果显存信息完整、型号识别正常，就没有必要往驱动方向投入。
系统更新可以用一条命令完成，它会重新安装并按需重启。
hive-replace -s -y
如果希望改回上一个稳定版本，可以先列出可选镜像，再从列表里挑一个旧版本。列表的读取命令是 hive-replace --list，在里面选稳定版本对应的编号即可。下载和写入的时间取决于硬盘速度和网络状况，完成后机器会自行重启。
超频参数过激会让矿工直接拒绝启动
超频设置过激的表现，和硬件故障很像：矿工在启动阶段退出，退出码为 0，机器进入冷却循环。区别在于，这类问题在把超频参数清空或者改成保守值之后会立刻改变。
验证方式是把对应显卡的超频方案先关掉，或者整体切换到一个没有做过超频的飞行表，然后重启矿机观察。如果矿工能正常跑起来，再逐步把参数加回去，每次只加一项，记录哪一项触发了退出。这一步之所以值得做，是因为它把“猜”变成了可重复的对照实验。
超频参数只在部分显卡上成立。把同一套参数从一张卡复制到另一张不同型号的卡，很可能直接导致矿工拒绝启动，多人共用一份参数表时尤其容易忽略。
DAG 校验与内存余量
显卡数量较多的机器还会碰到另一条路径。矿工启动时需要校验各张卡上的 DAG，这个动作会占用内存。机器内存不够时，校验过程可能失败，矿工随之退出。
处理办法是在矿工配置的额外参数里关闭启动阶段的 DAG 校验。不同矿工的命令行不同，lolminer 对应的是 --disable-dag-verify。填写之前要确认参数名和当前矿工版本匹配，写错的参数本身也会让矿工退出。
显存余量和系统内存余量是两件事，DAG 校验吃的是系统内存。有人把两者混为一谈，在显存设置上反复调整而问题依旧。
重装矿工与日志取证
当配置、版本和超频都排除之后，剩下的动作是把矿工本身重新装一遍。HiveOS 的 Shell 里可以按顺序执行三条命令，作用是先停掉矿工，清掉已安装的矿工包，再让系统重新拉起。
miner stop
apt remove -y hive-miners-*
miner start
这套操作会刷新矿工的配置文件和依赖，代价是要重新等待下载。它适合在已经怀疑包损坏但又不确定的时候做一次。
取证的标准流程是两步。先打开日志开关或者在出现问题的瞬间抓取日志，再按矿工名去对应目录读取。日志里通常会给出具体拒绝原因，例如矿池地址解析失败、币种参数缺失、算法与币种不匹配。拿到这一行再回到配置页面修改，比按顺序试十种方法要快。
一份最小排查顺序
现场没有时间做穷举，可以按这个顺序推进。
第一步确认退出码，从面板提示里读出括号内的数字。第二步只保留第二个币种的一个矿池，并清空第二个算法的 worker 名。第三步把矿工版本从 The Latest 改成具体版本，或者换一个矿工再试。第四步读取矿工日志，确认是否有明确的参数错误。第五步清空超频参数，排除设置过激。第六步核对显卡显存信息，判断是否需要重刷系统镜像。第七步重装矿工。
这个顺序把成本从低到高排列，前两步不需要重启整机，多数情况下能直接结束问题。真正需要动系统镜像和重装矿工的情况，通常伴随显卡信息异常或者整批机器同时出问题，而不是单台机器偶发。
退出码落在 139 这一档时，排查重心应转向驱动版本与矿工二进制。退出码为 0 时，配置层面的嫌疑最大。把这两类分开处理，能省掉大量无效折腾。
延伸阅读
- Powercolor RX 480 2GB接入HiveOS
- HiveOS 批量改配置最怕漏掉回滚条件
- Powercolor RX 580 8GB在HiveOS的BIOS核验流程
- 今晚批量改 HiveOS 配置前，先确认谁有一键下发权限
- HiveOS 批量命令最怕一次误选全场
