子进程

用 xargs 跑批量任务时，最让人头疼的问题之一就是退出码。脚本明明跑完了，但最后脚本的退出状态返回的到底是 xargs 自己的状态，还是某个子命令的状态？同样是退出码 123，为什么有时候表示"子命令失败了"，有时候又表示"xargs 自己出问题了"？这篇文章从三层架构的角度，把 xargs 的退出码归属关系讲清楚。 三层退出码架构：一张图说清楚归属关系 先说结论：xargs 的退出码体系其实分为三层，每一层对应不同的退出来源，搞清楚这个，调试效率至少翻倍。 第一...

用 xargs 跑并行任务，最怕遇到进程杀不掉的情况。按 Ctrl+C 有的任务正常退出，有的直接消失；给进程发 SIGTERM 没反应，换 SIGKILL 才强制终止——这两种信号的差别到底在哪？子进程对它们的行为为什么完全不同？今天彻底把这个事情讲清楚。 先搞懂两个信号的本质区别 Linux 里信号是内核向进程发送的通知机制，SIGTERM 和 SIGKILL 听着差不多，但本质完全不同： SIGTERM（信号编号 15）是温和请求：内核告诉进程请你体面地收场。进程...

批量任务跑久了，超时是家常便饭。但当超时真的发生，退出码显示124还是143、xargs报的错还是子进程自己的错——这些细节很多人搞不清楚。搞不清楚就没法针对性修复，只能干瞪眼。本文就来把这套逻辑彻底理顺。 先弄清退出码是谁的 理解xargs子进程退出码的前提，是分清楚三层身份：xargs本身、子进程、子进程里跑的真正命令。 一个典型的超时场景： echo "1 2 3" | xargs -P 3 timeout 2 sleep 这里的结构是：xargs → timeout...