您有时候可能会遇到LSF作业异常退出的问题其原因可能是因为LSF配置而杀掉作业的例如设置了作业的MEMLIMIT和RUNLIMIT因为OOMOut Of Memory操作系统自动触发杀掉进程的应用程序自己退出的例如程序发生了core dump或其它原因退出我们怎样进一步分析作业异常退出的问题呢这里提供几种常见的分析方法。方法1:用bhist -l jobid查看作业信息。如果是LSF因为配置RUNLIMIT、MEMLIMIT、CPULIMIT等策略或者bkill杀掉的作业bhist输出中能找到相关的信息。如果是其它原因导致作业退出bhist -l输出中可以看到作业的退出码exit code126作业命令无权限执行127找不到作业命令如果退出码大于128则将其减去128余值就是进程接收到的系统信号在Linux上可以用kill -l命令查看所有系统信号作业就是因为收到该信号而异常结束的。几个常见的退出码如下130作业收到信号2130-128例如Ctrlc退出135作业收到信号7135-128system bus error退出137作业收到信号9137-128被kill -9杀掉退出139作业收到信号11139-128segmentation 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