Nextflow结合SLURM运行时tr命令返回Exit Code 140的排查求助

数据老陈

2026-4-21

我来帮你梳理下这个问题的排查方向，毕竟exit code 140确实不是tr本身会返回的标准错误码，大概率是SLURM调度器或者Nextflow层面的信号传递、环境问题导致的，给你几个具体的排查步骤：

先确认SLURM任务是否被信号终止：Unix系统里，进程被信号杀死时，exit code通常是128 + 信号编号。140对应的是128 + 12，也就是信号SIGUSR2，不过也有可能是其他信号的特殊情况。你可以用SLURM的命令查任务状态：
```
sacct -j <你的任务ID> --format=ExitCode,State,Reason
```
同时查看SLURM生成的任务stderr日志文件，里面可能会有“Killed”或者信号相关的提示，比如是不是因为内存不足、任务超时被调度器终止了。
检查输入文件的完整性与访问性：如果你的in_file存在分布式存储（比如Lustre、GPFS）上，有可能出现文件未完全同步、权限不足的情况。可以在你的Nextflow进程里先加一些前置检查，比如：
```
ls -l ${in_file} && wc -l ${in_file}
```
另外还要注意，会不会是上游进程刚生成in_file，下游进程就开始处理，导致文件还没完全落地到计算节点？可以试试在这个进程里加个短暂的等待，或者用Nextflow的publishDir确保文件完全写入后再触发下游。
简化命令排除管道问题：你现在用的是cat in_file | tr "\t" "\n" > out_file，其实可以简化成tr "\t" "\n" < ${in_file} > ${out_file}，去掉多余的cat减少管道的复杂度，看看是不是管道环节出了问题。也可以把命令拆成两步单独测试，先输出cat ${in_file}看内容是否正常，再用tr处理，逐步定位故障点。
深挖Nextflow的日志细节：运行Nextflow的时候加上-log nextflow.log参数，然后查看日志里关于这个失败进程的详细记录，有没有资源不足、IO错误的提示。另外可以调整这个进程的错误策略，比如：
```
process yourProcess {
    errorStrategy 'retry'
    maxRetries 2
    // 其他配置
    script:
    """
    tr "\t" "\n" < ${in_file} > ${out_file}
    """
}
```
看看是不是偶发的集群资源波动导致的失败。
本地环境对比测试：把相同的in_file拿到本地机器上，运行同样的tr命令，看看会不会出现同样的exit code 140。如果本地完全正常，那基本可以确定问题出在SLURM集群的环境或者调度环节，和tr命令本身无关。

备注：内容来源于stack exchange，提问作者Alexlok