芯片研发工程师 A 和 IT 管理员 X，望着遍地的 job 尸体面面相觑，job 额头上大写的 EXIT 标志令人触目惊心。
工程师 A 先开口了。
“这里面很多 job 都是因我而来的，我要对他们负责任。它们终归是在 IT 维护的环境中挂掉的，你们也有推卸不掉的管理责任，我并不想多谈它们是怎么来的，现在我只想搞清楚它们是怎么没的。”
管理员 X 深吸了一口气，缓缓说道：“一个任务的失败，无非是环境、系统、人为和命令的综合作用，其它因素也有潜在可能，只是概率较小，如果希望破案，我们就需要借助一些信息技术手段，加上合理缜密的逻辑推理，来还原事情的真相，放心吧，我会还事件一个公道的！”。
一般破案逻辑
管理员 X 掏出一份破旧的内部文档，翻开第一页，上面记录着有史以来的 job 阵亡案件及其分析总结。
一般来说，job 的失败多是由于如下几个方面的因素导致的。
而分析 job 失败原因的时候，首先要根据 LSF job 的已知信息给出基本的方向性判断，然后再通过其它信息获取渠道来辅助判断，主要的信息以及信息来源包括如下几方面。
job FAIL 原因分析的一般路径如下。
基于如上基本经验，管理员 X 开始了破案之旅。
典型案例 – 环境因素
第一个映入眼帘的，是 44766121 这个 job。
首先，管理员 X 利用 bjobs -UF 命令获取了 44766121 的基本信息。
[X@admin-computer ~]$ bjobs -UF 44766121
Job <44766121>, User <***>, Project <***>, Status <EXIT>, Queue <***>, Interactive pseudo-terminal shell mode, Job Priority <50>, Command <tessent -shell>, Share group charged <***>
Tue Jun 25 20:30:30: Submitted from host <n232-134-195>, CWD <***>, Requested Resources < rusage[mem=10783]>;
Tue Jun 25 20:30:32: Started 1 Task(s) on Host(s) <n232-134-207>, Allocated 1 Slot(s) on Host(s) <n232-134-207>;
Tue Jun 25 20:30:40: Exited with exit code 127. The CPU time used is 0.0 seconds.
Tue Jun 25 20:30:40: Completed <exit>. 利用工具 lsfMonitor 的 Function -> Check Fail reason 功能，得到了如下如下 exit code 分析结果。
127 的 exit code 意味着 Command 未找到，也就是说用户的 PATH 中没有配置 tessent 的路径，导致 job 执行失败。
管理员 X 尝试复现一下这个问题。
[X@admin-computer ~]$ which tessent
/usr/bin/which: no tessent in (/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
[X@admin-computer ~]$
[X@admin-computer ~]$ bsub -q normal "tessent -shell"
memoryPrediction: The recommended rusage memory value is: 32MB.
Job <45048696> is submitted to queue <normal>.
[X@admin-computer ~]$
[X@admin-computer ~]$ bjobs -UF 45048696
Job <45048696>, User <X>, Project <default>, Status <EXIT>, Queue <normal>, Job Priority <50>, Command <tessent -shell>, Share group charged </X>
Wed Jun 26 17:22:44: Submitted from host <admin-computer>, CWD <$HOME>, Requested Resources < rusage[mem=32]>;
Wed Jun 26 17:22:45: Started 1 Task(s) on Host(s) <n232-135-012>, Allocated 1 Slot(s) on Host(s) <n232-135-012>, Execution Home </home/X>, Execution CWD </home/X>;
Wed Jun 26 17:22:45: Exited with exit code 127. The CPU time used is 0.0 seconds.
Wed Jun 26 17:22:45: Completed <exit>. X 的环境中并没有配置 tessent 工具的 PATH，当尝试 bsub “tessent -shell” 时，果然得到了同样的 exit code 127，猜测成立。
没想到第一个 FAIL job 的死因这么快就被破解了，简单的有些不可思议。
典型案例 – 系统因素（1）
第二个被查看的，是 41264142 这个 job。
用 bjobs -UF 命令获取 41264142 的基本信息。
[X@admin-computer ~]$ bjobs -UF 41264142
Job <41264142>, User <***>, Project <***>, Status <EXIT>, Queue <***>, Interactive pseudo-terminal shell mode, Job Priority <50>, Command <verdi -dbdir simv.daidir/>, Share group charged <***>
Tue Jun 11 21:27:03: Submitted from host <n232-134-131>, CWD <***>, Requested Resources < rusage[mem=25201]>;
Tue Jun 11 21:27:04: Started 1 Task(s) on Host(s) <n232-132-030>, Allocated 1 Slot(s) on Host(s) <n232-132-030>;
Tue Jun 25 21:29:12: Exited by LSF signal TERM_RUNLIMIT. The CPU time used is 19438.4 seconds.
Tue Jun 25 21:29:12: Completed <exit>; TERM_RUNLIMIT: job killed after reaching LSF run time limit. 在 job 信息中获取到了非常明确的 TERM_RUNLIMIT 提示，可以再用 lsfMonitor 来二次确认下。
利用工具 lsfMonitor 的 Function -> Check Fail reason 功能，得到了如下 TERM signal 的分析结果。
意思是说，这个 LSF（的 queue）有 RUNLIMIT 的运行时间限制，这个 job 运行的时间太久了，达到了允许的上限，所以被 LSF 给 kill 掉了。
管理员 X 从 job 信息中看到，任务从 06-11 21:27 开始运行，06-25 21:29 结束，运行了 14 天零 2 分钟。（好诡异的 2 分钟啊）
用命令 bqueues -l <queue> 获取队列的信息。
X@admin-computer ~]$ bqueues -l ***
QUEUE: ***
-- For *** jobs.
PARAMETERS/STATISTICS
PRIO NICE STATUS MAX JL/U JL/P JL/H NJOBS PEND RUN SSUSP USUSP RSV PJOBS
40 0 Open:Active - - - - 3869 0 3869 0 0 0 0
Interval for a host to accept two jobs is 0 seconds
RUNLIMIT
20162.0 min 果然，这个 queue 的 RUNLIMIT 限制就是 14 天零 2 分钟（20162.0 min），确实跟 job 的实际运行时长相符。
第二个悬案也被轻松破解了。
典型案例 – 系统因素（2）
再接再厉，接下来是 44437327 这个 job。
用 bjobs -UF 命令获取 44437327 的基本信息。
[X@admin-computer ~]$ bjobs -UF 44437327
Job <44437327>, Job Name <***>, User <***>, Project <***>, Status <EXIT>, Queue <***>, Interactive pseudo-terminal shell mode, Job Priority <50>, Command <pt_shell -f .tmp.tcl>, Share group charged <***>
Mon Jun 24 20:39:39: Submitted from host <n232-134-130>, CWD <***>, Requested Resources < select[volcengine] rusage[mem=30000]>;
Mon Jun 24 20:39:39: Started 1 Task(s) on Host(s) <n249-073-038>, Allocated 1 Slot(s) on Host(s) <n249-073-038>;
Tue Jun 25 22:54:29: Exited with exit code 137. The CPU time used is 2433.5 seconds.
Tue Jun 25 22:54:29: Completed <exit>. 利用工具 lsfMonitor 的 Function -> Check Fail reason 功能，得到了如下 exit code 的分析结果。
信息提示，任务失败的原因可能跟资源限制有关。
管理员 X 仍然借用 lsfMonitor，查询一下 Tue Jun 25 22:54:29 这个时间节点，任务运行机器 n249-073-038 上的负载状况。
通过上图可以看到，在 job 44437327 结束的时刻附近，服务器 n249-073-038 上的可用内存从 2TB 下降到了 62.9GB 的系统保留内存警戒线附近，并且在 job 44437327 结束后快速回升，由此可以判断，系统内存不足触发了 job 44437327 的失败。
再下一城！
典型案例 – 人为因素
排在其后的是 44744821 这个 job。
用 bjobs -UF 命令获取 44744821 的基本信息。
[X@admin-computer ~]$ bjobs -UF 44744821
Job <44744821>, User <***>, Project <***>, Status <EXIT>, Queue <***>, Job Priority <50>, Command <make powrep_flow MODULE=dpu_subsys FLOW=RFSDB_SYN_PD SCENARIO=max RELEASE=v0226 APPEND=a0 CORNER=FF>, Share group charged <***>
Tue Jun 25 19:18:29: Submitted from host <n232-135-013>, CWD <***>, 4 Task(s), Requested Resources < rusage[mem=51571]>;
Tue Jun 25 19:18:30: Started 4 Task(s) on Host(s) <n232-132-036> <n232-132-036> <n232-132-036> <n232-132-036>, Allocated 4 Slot(s) on Host(s) <n232-132-036> <n232-132-036> <n232-132-036> <n232-132-036>, Execution Home </home/***>, Execution CWD <***>;
Tue Jun 25 19:19:36: Exited with exit code 130. The CPU time used is 74.0 seconds.
Tue Jun 25 19:19:36: Completed <exit>; TERM_OWNER: job killed by owner. 在 job 信息中获取到了非常明确的 TERM_OWNER 提示，可以再用 lsfMonitor 来二次确认下。
利用工具 lsfMonitor 的 Function -> Check Fail reason 功能，得到了如下 TERM signal 的分析结果。
这个提示已经足够明确，用户自己杀死的自己的 job！
管理员 X 尝试重现一下这个问题。
[X@admin-computer ~]$ bsub -q normal "sleep 100"
Job <45057984> is submitted to queue <normal>.
[X@admin-computer ~]$
[X@admin-computer ~]$ bkill 45057984
Job <45057984> is being terminated
[X@admin-computer ~]$
[X@admin-computer ~]$ bjobs -UF 45057984
Job <45057984>, User <X>, Project <default>, Status <EXIT>, Queue <normal>, Job Priority <50>, Command <sleep 100>, Share group charged </X>
Wed Jun 26 18:00:19: Submitted from host <admin-computer>, CWD <$HOME>;
Wed Jun 26 18:00:20: Started 1 Task(s) on Host(s) <n249-073-080>, Allocated 1 Slot(s) on Host(s) <n249-073-080>, Execution Home </home/X>, Execution CWD </home/X>;
Wed Jun 26 18:00:30: Exited with exit code 130. The CPU time used is 0.0 seconds.
Wed Jun 26 18:00:30: Completed <exit>; TERM_OWNER: job killed by owner. 果然，用户自己 kill 自己 job 的时候，job 的遗言中会显示出 “TERM_OWENR: job killed by owner” 这样的提示，是无可辩驳的铁证。
工程师 A 的脸刷地一下红了，不好意思地说 “这个、这个，是我不小心 kill 的，还是一起看看下一个吧…”。
典型案例 – 命令因素（1）
躺在后面的，是 45257669 这个 job。
用 bjobs -UF 命令获取 45257669 的基本信息。
[X@admin-computer ~]$ bjobs -UF 45257669
Job <45257669>, User <***>, Project <***>, Status <EXIT>, Queue <***>, Interactive pseudo-terminal shell mode, Job Priority <50>, Command <innovus -stylus -wait 120 -file ../scr/08_invs_dataout.tcl -log ../log/dataout.log>, Share group charged <***>
Thu Jun 27 09:02:08: Submitted from host <n232-135-012>, CWD <***>, 8 Task(s), Requested Resources <rusage[mem=51200]>;
Thu Jun 27 09:02:09: Started 8 Task(s) on Host(s) <n249-073-009> <n249-073-009> <n249-073-009> <n249-073-009> <n249-073-009> <n249-073-009> <n249-073-009> <n249-073-009>, Allocated 8 Slot(s) on Host(s) <n249-073-009> <n249-073-009> <n249-073-009> <n249-073-009> <n249-073-009> <n249-073-009> <n249-073-009> <n249-073-009>;
Thu Jun 27 10:14:34: Exited with exit code 139. The CPU time used is 18345.3 seconds.
Thu Jun 27 10:14:34: Completed <exit>. 利用工具 lsfMonitor 的 Function -> Check Fail reason 功能，得到了如下 exit code 分析结果。
“分段错误” 是一种比较少见的错误类型，看上去像是 c 语言程序运行故障。
管理员 X 根据获取到的 job 信息，进入了案发现场（job 运行路径），调取了现场的监控记录（命令 log）。
adence Innovus(TM) Implementation System.
Copyright 2022 Cadence Design Systems, Inc. All rights reserved worldwide.
Version: v22.34-s061_1, built Wed Oct 18 11:20:49 PDT 2023
Options: -stylus -wait 120 -file ../scr/08_invs_dataout.tcl -log ../log/dataout.log
...
pstack
========================================
Thread 51 (Thread 0x2b58be326700 (LWP 10160)):
#0 0x00002b58b04269dd in accept () from /lib64/libpthread.so.0
#1 0x000000002f464fb7 in ProcessInfo::handleConnection(void*) ()
#2 0x000000000bdd9595 in create_head(void*) ()
#3 0x00002b58b041fea5 in start_thread () from /lib64/libpthread.so.0
#4 0x00002b58b0ec9b0d in clone () from /lib64/libc.so.6
Thread 50 (Thread 0x2b58be527700 (LWP 10161)):
#0 0x00002b58b0ec0b43 in select () from /lib64/libc.so.6
#1 0x000000002f45cc1b in ProcessInfo::sampleUsage(void*) ()
#2 0x000000000bdd9595 in create_head(void*) ()
...
#39 0x0000000030d2371c in Tcl_MainEx ()
#40 0x0000000006c936f1 in main ()
========================================
gdb
========================================
Using: gdb
/ic/sh.5kECXf: Permission denied.
Crashed in AAE on net Unknown net. 监控（命令 log）中记录了完整的案发现场，在多线程应用场景中，工具 innovus 发生了 crash，所有的线程都发生了崩溃，并且在频死时报告出了内心独白（堆栈信息）。
大家面面相觑，工程师 A 想的是 “没想到是 EDA 工具有 bug 啊，AE 需要解释清楚”，而管理员想的是 “任务失败了，他竟然连 log 都不看一眼…”。
典型案例 – 命令因素（2）
“X，并不是我存心为难你。”
工程师 A 略有些不甘心地说。
“尽管上面 EXIT 的 job 都找到了原因，但是我还是隐隐约约觉得 LSF 环境有一些不太正常的地方，有些时候我的 EDA 工具明明是跑失败了，但是 LSF job 的状态仍然是报告 DONE，比如 45297303 这个 job，这是不是有些异常呢？”
管理员 X 也感到好奇了起来，凑上来看看工程师 A 的新证据。
[A@user-computer ~]$ bjobs -UF 45297303
Job <45297303>, User <***>, Project <***>, Status <DONE>, Queue <***>, Interactive pseudo-terminal shell mode, Job Priority <50>, Command <./run.sh>, Share group charged <***>
Thu Jun 27 12:04:05: Submitted from host <n232-135-067>, CWD <***>, Requested Resources < rusage[mem=12612]>;
Thu Jun 27 12:04:06: Started 1 Task(s) on Host(s) <n249-073-071>, Allocated 1 Slot(s) on Host(s) <n249-073-071>;
Thu Jun 27 12:18:42: Done successfully. The CPU time used is 660.3 seconds. 确实，45297303 这个 job 是 “DONE” 的状态，说明 “./run.sh” 这个命令的退出码是 0，应该是执行成功了。
工程师 A 又调出了 45297303 的日志文件。
..
Assertion failed: "false", dgcom_exec, grLoops.cc, line 771
Aborting.
Stack trace for crashing thread
-------------------------------
SNPSee_72fe6ee5e6adf88ac107a01d196ffb8ed40842348ffb0f8b+36
SNPSee_9ea8dbbd5e74784445edf9ed12a0bc4777b489dcaefdb88f6aa47f4097fccf5e+156
...
A detailed stack trace has been captured in /***/syn_fc/run/Synopsys_stack_trace_54988.txt.
The tool has just encountered a fatal error:
...
Fatal: Internal system error, cannot recover.
Error code=6
CPU time=656
Release = 'V-2023.12-SP4-DEV' Architecture = 'linux64' Program = 'Fusion Compiler'
Exec = '/ic/software/synopsys/fusioncompiler/V-2023.12-SP4-DEV-20240401/linux64/nwtn/bin/dgcom_exec' 45297303 的 EDA 工具 log 中确实因为遇到了 fatal error 而退出！
管理员 X 疑惑地进入了案发地（job 运行路径），打开运行命令脚本（./run.sh）。
[X@user-computer ~]$ cat run.sh
#!/bin/bash
fc_shell -f /***/syn_fc/scr/syn.tcl -x "set stage none;" -output_log_file /***/syn_fc/log/syn_fc.log
exit 0 脚本最后一行刺目的 “exit 0” 让人瞬间觉得哭笑不得。
管理员 X 跟工程师 A 解释道：“LSF 根据 job command 的 exit code 判断 status，如果 exit code 是 0，那么 LSF 就认为这个 job 是 DONE 的状态，如果 exit code 非 0，那么 LSF 就认为这个 job 是 EXIT 的状态，所以在书写脚本的时候，应该严谨地通过最后一行命令的 return code 来反馈整个脚本的执行状态…”
工程师 A 表情沉重地点上了一支烟，陷入了沉思。
收尾
战场很快就被打扫的差不多了，大多数 job 都确定了明确的死因，并被一一登记在案，但是总有一些 job，因为信息的模糊和缺失而死无对证。
但是无论对工程师 A 还是对管理员 X 而言，这并不重要，探索的最终目的并不是为了解世界的全部真相，而是为了掌握正确的方法和逻辑，以避免反复地掉到同一个坑里无法自拔。
附录
附一、LSF 退出码含义
‘-9’: 通常表示作业被强制终止
‘-8’: 通常表示资源严重不足
‘-7’: 通常表示无效的主机名或节点
‘-6’: 通常表示作业被系统强制终止
‘-5’: 通常表示作业被用户终止或中断
‘-4’: 通常表示无效的队列名称
‘-3’: 通常表示无效的作业 ID
‘-2’: 通常表示内部错误
‘-1’: 通常表示系统级错误
‘0’: 成功完成并正常退出
‘1’: 通常表示一般性的警告性错误
‘2’: 通常表示一般性的错误
‘3’: 通常表示一般性的致命错误
‘4’: 通常表示初始化失败
‘5’: 通常表示输入 / 输出错误
‘6’: 通常表示无效的参数
‘7’: 通常表示无法分配足够的内存
‘8’: 通常表示目录不存在或无法访问
‘9’: 通常表示文件不存在或无法访问
’10’: 通常表示不支持的功能或操作
’11’: 通常表示文件已存在
’12’: 通常表示超时错误
’13’: 通常表示权限被拒绝
’14’: 通常表示资源不足
’15’: 通常表示信号中断
’16’: 通常表示管道损坏或被关闭
’17’: 通常表示死锁错误
’18’: 通常表示磁盘已满
’19’: 通常表示读取错误
’20’: 通常表示写入错误
’21’: 通常表示连接错误
’22’: 通常表示无效或损坏的数据
’23’: 通常表示操作被中止
’24’: 通常表示过多打开的文件
’25’: 通常表示操作不可行
’26’: 通常表示无效的文件系统操作
’27’: 通常表示文件太大，超出限制
’28’: 通常表示信号已被阻塞
’29’: 通常表示管道已满或破裂
’30’: 通常表示无效的进程
’31’: 通常表示在操作中断时出现错误
’32’: 通常表示某个命令的语法错误
’33’: 通常表示触发某个限制或配额
’34’: 通常表示某个服务或进程的异常终止
’35’: 通常表示输入或输出的格式错误
’36’: 通常表示某个进程或作业已经在运行
’37’: 通常表示某个进程或作业已经停止或结束
’38’: 通常表示操作被取消或中断
’39’: 通常表示需要更高的权限来执行操作
’40’: 通常表示某个连接或会话已经关闭
’41’: 通常表示接收到无效或损坏的数据
’42’: 通常表示某个网络连接失败
’43’: 通常表示某个网络服务不可用
’44’: 通常表示某个数据库操作失败
’45’: 通常表示某个文件或目录已经损坏
’46’: 通常表示某个操作已超时
’47’: 通常表示安全验证失败
’48’: 通常表示发生未知的错误
’49’: 通常表示某个任务或处理已中断
’50’: 通常表示某个进程或作业达到资源限制
’51’: 通常表示故障引起的不可恢复的错误
’52’: 通常表示某个进程被非法访问或操作
’53’: 通常表示某个操作被有效的权限限制
’54’: 通常表示某个系统服务或组件不可用
’55’: 通常表示某个数据损坏或丢失
’56’: 通常表示某个网络连接已经超时
’57’: 通常表示某个数据库连接失败
’58’: 通常表示某个脚本或程序操作失败
’59’: 通常表示某个任务被取消或终止
’60’: 通常表示某个进程或作业已过期
’61’: 通常表示某个配置错误导致无法正常执行
’62’: 通常表示某个日志文件错误
’63’: 通常表示某个加密或解密操作失败
’64’: 通常表示某个进程或作业运行时间过长
’65’: 通常表示与某个硬件设备的通信失败
’66’: 通常表示某个数据库查询操作失败
’67’: 通常表示某个网络协议错误
’68’: 通常表示某个文件系统操作失败
’69’: 通常表示某个环境变量未设置或无效
’70’: 通常表示某个进程或作业的使用量超过限制
’71’: 通常表示某个数据库连接超时
’72’: 通常表示某个配置文件错误
’73’: 通常表示某个依赖项未满足
’74’: 通常表示某个加密或解密密钥无效
’75’: 通常表示某个消息传递失败
’76’: 通常表示某个网络通信错误
’77’: 通常表示某个文件或目录已损坏
’78’: 通常表示某个版本错误
’79’: 通常表示某个资源不可用
’80’: 通常表示某个任务超时
’81’: 通常表示某个链接无效或过期
’82’: 通常表示某个权限被拒绝
’83’: 通常表示某个输入无效或错误
’84’: 通常表示某个输出无效或错误
’85’: 通常表示某个连接被重置
’86’: 通常表示某个数据库事务失败
’87’: 通常表示某个网络服务超负荷
’88’: 通常表示某个文件被锁定
’89’: 通常表示某个配置项缺失或无效
’90’: 通常表示某个配置文件丢失或损坏
’91’: 通常表示某个请求被限制或阻止
’92’: 通常表示某个协议错误
’93’: 通常表示某个验证失败
’94’: 通常表示某个数据传输错误
’95’: 通常表示某个脚本或程序非法操作
’96’: 通常表示某个任务被其他任务阻塞
’97’: 通常表示某个命令已过时或不再支持
’98’: 通常表示某个外部资源不可达
’99’: 通常表示某个时间戳无效或过期
‘100’: 通常表示某个进程或作业已经终止
‘101’: 通常表示某个协议切换失败
‘102’: 通常表示某个网络连接已被废弃
‘103’: 通常表示某个配置文件格式错误
‘104’: 通常表示某个请求被重定向
‘105’: 通常表示某个数据库操作异常
‘106’: 通常表示某个加密或解密错误
‘107’: 通常表示某个脚本或程序运行环境错误
‘108’: 通常表示某个资源限制被超出
‘109’: 通常表示某个输入输出错误
‘110’: 通常表示某个网络连接超载
‘111’: 通常表示某个进程或作业被阻塞
‘112’: 通常表示某个命令执行失败
‘113’: 通常表示某个服务不可达
‘114’: 通常表示某个证书无效或过期
‘115’: 通常表示某个文件系统错误
‘116’: 通常表示某个资源被释放或移除
‘117’: 通常表示某个地址被禁止访问
‘118’: 通常表示某个任务被挂起或暂停
‘119’: 通常表示某个操作系统错误
‘120’: 通常表示某个协议版本错误
‘121’: 通常表示某个文件或目录不存在
‘122’: 通常表示某个资源临时不可用
‘123’: 通常表示某个命令语法错误
‘124’: 通常表示某个日志记录失败
‘125’: 通常表示某个编码或解码错误
‘126’: 通常表示某个执行权限不足
‘127’: 通常表示某个命令未找到
‘128’: 通常表示某个无效的退出状态
‘129’: 通常表示某个库依赖项错误
‘130’: 通常表示某个进程或作业被中断
‘131’: 通常表示某个信号捕获失败
‘132’: 通常表示某个文件被修改
‘133’: 通常表示某个连接被拒绝
‘134’: 通常表示某个堆栈溢出
‘135’: 通常表示某个资源超时
‘136’: 通常表示某个内存分配错误
‘137’: 通常表示某个进程或作业因超出资源限制而被杀死
‘138’: 通常表示某个信号超出范围
‘139’: 通常表示某个分段错误
‘140’: 通常表示某个程序或进程收到了致命信号
‘141’: 通常表示某个时钟错误
‘142’: 通常表示某个文件格式无效
‘143’: 通常表示某个程序被终止或中断
‘144’: 通常表示某个信号被阻止
‘145’: 通常表示某个操作被终止
‘146’: 通常表示某个目录切换失败
‘147’: 通常表示某个管道错误
‘148’: 通常表示某个孤儿进程（没有父进程）
‘149’: 通常表示某个挂起的进程或作业
‘150’: 通常表示某个资源耗尽
‘151’: 通常表示某个镜像损坏或无效
‘152’: 通常表示某个文件被锁定
‘153’: 通常表示某个内存映射错误
‘154’: 通常表示某个信号处理失败
‘155’: 通常表示某个网络操作失败
‘156’: 通常表示某个设备驱动错误
‘157’: 通常表示某个套接字连接错误
‘158’: 通常表示某个链接超时
‘159’: 通常表示某个文件描述符无效
‘160’: 通常表示某个插件或扩展错误
‘161’: 通常表示某个远程主机不可达
‘162’: 通常表示某个文件读取错误
‘163’: 通常表示某个文件写入错误
‘164’: 通常表示某个数据包损坏
‘165’: 通常表示某个数据库连接错误
‘166’: 通常表示某个超出容量限制
‘167’: 通常表示某个死锁状态
‘168’: 通常表示某个证书验证失败
‘169’: 通常表示某个系统时钟漂移
‘170’: 通常表示某个正在进行的操作被取消
‘171’: 通常表示某个权限不允许操作
‘172’: 通常表示某个目标不可到达
‘173’: 通常表示某个文件系统不支持操作
‘174’: 通常表示某个系统服务异常
‘175’: 通常表示某个网络地址不可用
‘176’: 通常表示某个资源已经存在
‘177’: 通常表示某个数据内容被篡改
‘178’: 通常表示某个系统崩溃或故障
‘179’: 通常表示某个进程或作业超时
‘180’: 通常表示某个用户操作中止
‘181’: 通常表示某个文件被加密
‘182’: 通常表示某个库文件损坏
‘183’: 通常表示某个账户权限不足
‘184’: 通常表示某个资源被占用
‘185’: 通常表示某个数据格式错误
‘186’: 通常表示某个网络连接已关闭
‘187’: 通常表示某个缺少依赖项
‘188’: 通常表示某个系统日志错误
‘189’: 通常表示某个命令行参数错误
‘190’: 通常表示某个配置文件缺失或损坏
‘191’: 通常表示某个文件权限错误
‘192’: 通常表示某个进程或作业已经在运行
‘193’: 通常表示某个设备或服务不可用
‘194’: 通常表示某个数据验证错误
‘195’: 通常表示某个协议操作失败
‘196’: 通常表示某个系统初始化错误
‘197’: 通常表示某个备份或恢复错误
‘198’: 通常表示某个连接被重置
‘199’: 通常表示某个程序逻辑错误
‘200’: 通常表示某个成功的状态，表示程序或进程成功终止
‘201’: 通常表示某个一个请求被响应成功
‘202’: 通常表示某个异步操作已经启动结果可能在以后的时间返回
‘203’: 通常表示某个接受已接收的请求但未执行
‘204’: 通常表示某个请求成功执行，但没有返回实体内容
‘205’: 通常表示某个请求成功执行后，需要发送新的请求才能获取更新的页面
‘206’: 通常表示某个请求成功执行，但只返回了部分内容
‘207’: 通常表示某个多状态响应，用于表示多个操作的结果
‘208’: 通常表示某个请求执行的结果已经包含在响应消息中
‘209’: 通常表示某个请求成功执行，但返回的信息已经被代理修改
‘210’: 通常表示某个请求成功执行，但返回的资源已经移动
‘211’: 通常表示某个请求成功执行，但返回的内容已更改
‘212’: 通常表示某个请求成功执行，但需要额外的身份验证
‘213’: 通常表示某个请求成功执行，但返回的数据部分已失效
‘214’: 通常表示某个请求成功执行，但没有满足请求的结果
‘215’: 通常表示某个请求成功执行，但需要进一步处理
‘216’: 通常表示某个请求成功执行，但存在范围不匹配的内容
‘217’: 通常表示某个请求成功执行，但返回的数据类型不受支持
‘218’: 通常表示某个请求成功执行，但返回的数据已经已知
‘219’: 通常表示某个请求成功执行，但存在内部冲突
‘220’: 通常表示某个请求成功执行，但进程或操作处于暂停状态
‘221’: 通常表示某个请求成功执行，但返回的内容未更改
‘222’: 通常表示某个请求成功执行，但返回的内容已被重新排序
‘223’: 通常表示某个请求成功执行，但返回的内容未被重置
‘224’: 通常表示某个请求成功执行，但存在版本冲突
‘225’: 通常表示某个请求成功执行，但存在服务器过载
‘226’: 通常表示某个请求成功执行，但返回的内容是通过协商缓存生成的
‘227’: 通常表示某个请求成功执行，但源数据存在问题
‘228’: 通常表示某个请求成功执行，但数据解析失败
‘229’: 通常表示某个请求成功执行，但存在内容更新冲突
‘230’: 通常表示某个请求成功执行，但返回的内容包含警告信息
‘231’: 通常表示某个请求成功执行，但返回的内容需要用户进一步处理
‘232’: 通常表示某个请求成功执行，但返回结果需要进一步验证
‘233’: 通常表示某个请求成功执行，但返回的内容需要管理员干预
‘234’: 通常表示某个请求成功执行，但存在资源限制
‘235’: 通常表示某个请求成功执行，但返回的内容包含敏感信息
‘236’: 通常表示某个请求成功执行，但返回的内容包含过期信息
‘237’: 通常表示某个请求成功执行，但返回的内容存在冲突
‘238’: 通常表示某个请求成功执行，但返回的内容被转换
‘239’: 通常表示某个请求成功执行，但服务端要求重新认证
‘240’: 通常表示某个请求成功执行，但需要进行重定向
‘241’: 通常表示某个请求成功执行，但存在过多的重定向
‘242’: 通常表示某个请求成功执行，但返回的内容需要进行安全验证
‘243’: 通常表示某个请求成功执行，但返回的内容需要进行数据转换
‘244’: 通常表示某个请求成功执行，但存在连接超时
‘245’: 通常表示某个请求成功执行，但返回的内容已过期
‘246’: 通常表示某个请求成功执行，但返回的内容需要进行语义解析
‘247’: 通常表示某个请求成功执行，但返回的内容需要进行格式转换
‘248’: 通常表示某个请求成功执行，但返回的内容需要进行编码转换
‘249’: 通常表示某个请求成功执行，但返回的内容需要进行内容裁剪
‘250’: 通常表示某个请求成功执行，但返回的内容需要进行内容合并
‘251’: 通常表示某个请求成功执行，但返回的内容需要进行内容过滤
‘252’: 通常表示某个请求成功执行，但返回的内容需要进行内容排序
‘253’: 通常表示某个请求成功执行，但返回的内容需要进行内容分割
‘254’: 通常表示某个请求成功执行，但返回的内容需要进行内容聚合
‘255’: 通常表示命令因不明原因执行失败
附二、LSF TERM 信号含义
TERM_ADMIN: 任务被 root 用户或 LSF 管理员终止
TERM_BUCKET_KILL: 任务被 kill -b 命令终止
TERM_CHKPNT: 在 checkpointing 之后，任务被终止
TERM_CPULIMIT: 因达到 LSF CPU 使用限制，任务被被终止
TERM_CSM_ALLOC: 因 CSM 分配 API 错误，任务被终止
TERM_CWD_NOTEXIST: 当前工作目录不可访问或在执行主机上不存在，任务被终止
TERM_DATA: 因数据暂存失败，任务被终止
TERM_DEADLINE: 因截止期限到期，任务被终止
TERM_EXTERNAL_SIGNAL: 任务被 LSF 外部的信号所终止
TERM_FORCE_ADMIN: 任务被 root 用户或 LSF 管理员终止，没有时间进行清理
TERM_FORCE_OWNER: 任务被所有者终止，没有时间进行清理
TERM_KUBE: 因 Kubernetes 集成，任务被终止
TERM_LOAD: 因负载超过阈值，任务被终止
TERM_MC_RECALL: 因多集群任务重新调用，任务被终止
TERM_MEMLIMIT: 因达到 LSF 内存使用限制，任务被终止
TERM_ORPHAN_SYSTEM: LSF 自动终止了孤立任务
TERM_OTHER: 在切换到另一个队列后，处于 WAIT 状态的区块任务被终止并重新排队
TERM_OWNER: 任务被所有者终止
TERM_PREEMPT: 任务因抢占而终止
TERM_PRE_EXEC_FAIL: 达到执行前重试限制后，任务被终止
TERM_PROCESSLIMIT: 达到 LSF 进程限制后，任务被终止
TERM_RC: 当云平台回收 LSF 资源连接器执行主机时，任务被终止
TERM_REMOVE_HUNG_JOB: 任务被从 LSF 中移除
TERM_REQUEUE_ADMIN: 任务被 root 用户或 LSF 管理员终止并重新排队
TERM_REQUEUE_OWNER: 任务被所有者终止并重新排队
TERM_REQUEUE_RC: 当云平台回收 LSF 资源连接器执行主机时，任务被终止并重新排队
TERM_RMS: 因 RMS 系统错误，任务被终止
TERM_RUNLIMIT: 因达到 LSF 运行时间限制，任务被终止
TERM_SWAP: 因达到 LSF swap 使用限制，任务被终止
TERM_THREADLIMIT: 因达到 LSF 线程限制，任务被终止
TERM_UNKNOWN: LSF 无法确定终止原因
TERM_WINDOW: 因队列运行窗口关闭，任务被终止
TERM_ZOMBIE: 当 LSF 不可用，任务被终止
LSF job 失败原因分析(转)