LSF实践专题（7）：Job exit问题分析

 您有时候可能会遇到LSF作业异常退出的问题，其原因可能是：

• 因为LSF配置而杀掉作业的，例如设置了作业的MEMLIMIT和RUNLIMIT

• 因为OOM（Out Of Memory），操作系统自动触发杀掉进程的

• 应用程序自己退出的（例如程序发生了core dump或其它原因退出）

我们怎样进一步分析作业异常退出的问题呢？这里提供几种常见的分析方法。

方法1:

用bhist -l <jobid>查看作业信息。

如果是LSF因为配置RUNLIMIT、MEMLIMIT、CPULIMIT等策略或者bkill杀掉的作业，bhist输出中能找到相关的信息。

如果是其它原因导致作业退出，bhist -l输出中可以看到作业的退出码（exit code）：

• 126：作业命令无权限执行

• 127：找不到作业命令

如果退出码大于128，则将其减去128，余值就是进程接收到的系统信号（在Linux上可以用kill -l命令查看所有系统信号），作业就是因为收到该信号而异常结束的。几个常见的退出码如下：

• 130：作业收到信号2（130-128，例如Ctrl+c）退出

• 135：作业收到信号7（135-128，system bus error）退出

• 137：作业收到信号9（137-128，被kill -9杀掉）退出

• 139：作业收到信号11（139-128，segmentation fault）退出

如果是没有明确意义的退出码，可能是应用程序自身设置的特殊退出码。

方法2：

如果作业退出问题能够稳定复现，那么用bsub提交作业时可以加上-o和-e选项。这样在作业运行时，应用程序向标准输出（stdout）产生的日志会保存到-o指定的文件中，向标准错误（stderr）产生的日志会保存到-e指定的文件中。我们就可以从-o和-e输出文件中找到线索。如果知道应用程序的日志位置，也可以直接查看应用日志来分析问题。

方法3：

如果作业是脚本，可以在脚本里插入调式和打印语句来帮助定位问题。

方法4：

如果怀疑是LSF没有启动作业进程，可以用系统工具strace来跟踪LSF的sbatchd进程和作业进程，例如用如下命令来跟踪执行：

strace -f -v -tt -T -s 1024 -o /tmp/sbd.strace -p <pid_of_sbatchd>

上面这条命令开始执行后，再提交作业，然后查看/tmp/sbd.strace日志中是否有线索。

方法5：

如果怀疑作业因为某些系统原因退出，例如OOM，除了用bhist查看作业退出码是否为137外，也可以从系统日志中（/var/log/messages或用journalctl命令查看）查找线索。

方法6：

如果作业退出码显示作业是被杀掉的，但是bhist又没有明显信息表明作业是被LSF杀掉的，也找不到被谁杀掉，可以使用Linux系统的auditd功能去分析进程是被谁杀掉的。

方法7：

如果无法确定是LSF的问题、系统环境问题还是应用程序自身的问题导致作业异常退出，也可以在LSF外面单独运行作业（即不通过bsub命令提交，而是直接在计算节点上运行应用程序），用相同的用户、环境变量和执行节点，运行参数相同的应用程序，看能否正常运行。如果可以正常运行，再进一步分析LSF方面的问题；如果不能正常运行，那么需要先分析应用程序自身的问题。

以上几种方法，在具体分析问题时，可以根据需要灵活使用。关于LSF作业的exit code，也可以参考以下链接：

IBM Documentation

 欢迎关注下方微信公众号【HPC常青园】，共同交流HPC集群管理经验和最佳实践。如果您有关于HPC集群的具体需求，欢迎邮件沟通交流：hpc@ivyent.cn。