节点故障排除指南

节点控制台/log日志错误

Zend 错误: 没有定义auth机制

检查zen.conf文件中是否存在rpcuser和rpcpassword条目，并且zen-cli命令正常工作。

运行'node setup'，它将读取zen.conf文件。

重新启动跟踪器应用程序：'Crtr-c'然后'node app'或者如果使用pm2：'pm2 restart 0'

一次更改了太多配置值。 不允许重新连接。 一次只能更改一个

一次只能更改以下其中一项：

• IP地址，
• 节点t地址，
• 质押地址。

nodeid必须保持不变。 nodeid位于〜/ nodetracker / config / config.json文件中。

如果您已重建或克隆节点并使用新的wallet.dat，则会更改节点t地址。 要使用相同的质押地址和IP地址连接到服务器并进行身份验证。 更新新节点t地址后，如果需要，可以更改质押地址。

无法注册， 未通过身份验证。
当重建节点或者某些节点配置发生更改或节点配置缺少节点ID时，这通常发生在已注册的节点上。

节点正在连接到服务器，但服务器未找到数据库记录。 检查是否存在〜/ nodetracker / config / config.json文件并确保它具有正确的节点ID。

节点已注册，<node t-address>已通过身份验证。
该节点先前已注册，但缺少nodeid。 服务器识别该节点并发回节点的nodeid以在config文件夹中重新创建该文件。

未经过身份验证，未找到节点或没有nodeid或仍在初始化。
当节点尚未完全验证（忙碌服务器）时会发生这种情况。 它自己会重试。

挑战问题

挑战隐私Z地址余额目前为0。无法进行挑战
“no available balance found or 0”

挑战未在节点上的z地址中找到余额，并且无法发送隐蔽交易。每次挑战都需要.0002zen（挑战费0.0001，矿工费为0.0001）。这是为了确保隐私交易能被下一个区块打包所需的最小值。

Z地址可以在发送交易时暂时显示0余额，直到交易被打包到块中确认、并找零后，重新出现余额。

有两种方法可以帮助确保始终有可用的余额。使用任一种方法，节点上仅需要总共约0.3至0.5zen。这一数额应该够节点每天一次持续挑战几年。如果节点始终遇到挑战失败，则可能会消耗更多zen

1.在节点上创建第二个z地址并向其发送少量z地址。这可以是一个z地址中的0.2，另一个也发送0.2zen。跟踪应用程序将检查每个地址中的可用余额，并使用它首先找到的地址。这是首选方法。

或者

2.向单个z地址发送多个并且少量（四个量为0.1zen）。这应该在z地址中留下未花费的金额（'记录'），以便余额检查不会失败。

"unable to get blockhash from zen"
"bad-txns-joinsplit-requirements-not-met"

Zen区块链很可能没有完全同步。 等待它同步完成。 可以检查节点上的'zen-cli getblockcount'的结果与https://explorer.zensystem.io/blocks上的块高度进行比较。

"常规异常: std::bad_alloc"

节点存在内存问题或内存不足，并且zen无法完成正在执行的操作。 如果最近重新启动了节点，请确保swap文件仍可用。

较慢的系统可能也能通过5GB的挑战，但6GB会留下更多的空间。 如果需要，请增加swap。

使用'free -h'检查可用内存。

它看起来应该类似于：

              total        used free      shared buff/cache available
Mem:           3.8G 2.9G        187M 1.7M 665M        623M
Swap:          4.0G 975M        3.0G

"exceeded reply time - no txid from node"

向该节点发送了一个挑战，但是没有收到来自节点的挑战结果，或者没有向tracker服务器发送表明挑战失败的交易ID。 如果“challenge Results”表的“received”单元格中没有条目，则表示服务器没有处理回复。

如果挑战中断并且服务器在一小时后将挑战标记为dead，也可能发生这种情况。

使用节点详细信息页面上的“发送挑战”按钮发送另一个手动挑战，并检查结果。

如果此问题仍然存在，请更新zen.conf，并在下面添加以下参数。 然后重启zend和Node Tracker。

rpcworkqueue=512

'allowed reply variance exceeded'

这是节点完成挑战的时间与服务器从节点接收应答的时间之间的检查。

节点上可能运行两个跟踪器，这可能导致延长的回复时间。 这些可能会相互覆盖，导致不可预测的结果。

如果使用PM2:

运行 'pm2 list'  应该只让一个节点进程运行。 并停止第二个实例。

进程程编号可能为0和1。

• pm2 stop 1

• pm2 delete 1

• pm2 restart 0

• pm2 save

如果仅有一个PM2进程。

• 手动检查pm2运行状态和节点跟踪器。

• 这可能是以'node app.js'开头的，或者可能有重启脚本来启动它。

• 如果运行使用Ctrl-c停止跟踪器。 然后调整配置，以了解系统的应用程序启动方式。 PM2可以自己处理。 （请参阅有关PM2网站上'startup'命令的PM2说明）

如果没使用PM2 

运行 'top' 查看正在运行的进程列表

在进程列表中，应该只有一个描述包含对'node'的引用（这是nodejs）

该条目可能如下所示。 第一个数字是PID（进程ID）

3014 nodeadm+  20 0 1220348 39920   1868 S 0.3 4.0 77:00.16 node /home/node

要么杀死其中一个节点进程，要么重启服务器可能更简单。 一旦重启，
再次检查跟踪器运行的多个实例。

停止一个进程:

• 识别要停止的进程的PID

• 使用'q'或'Ctrl-c'退出top

• 输入'kill -9 pid number'替换进程的pid号。

常规

收不到电子邮件

这可能来自节点的通知或详细信息页面上的按钮，用于挑战或详细信息。

检查nodetracker配置以获取正确的电子邮件并重新启动跟踪器。

• node ~/nodetracker/setup.js
• sudo systemctl restart zentracker