Shell脚本 第2页

写并行 Shell 脚本时，最常见的痛点是：起了一堆后台任务，想在「任何一个」任务结束时立刻拿到它的退出码，而不是傻等全部跑完。bash wait -n 就是干这个的。但这个选项有明显的版本门槛，macOS 自带的老 bash 直接不认识它。这篇把 wait -n 的用法、退出码规则和版本兼容一次讲清，全部内容都在真机上验证过。 一、wait -n 是干什么的 普通的 wait 不带参数时，会阻塞到所有后台任务结束，且返回值恒为 0——这意味着你根本不知道哪个任务失败了。而...

Shell脚本里用「&」把任务扔到后台跑，速度是快了，但退出码经常收不回来——脚本最后一行 wait 一执行，$? 永远是 0，哪个任务失败了根本不知道。这篇把 wait 后台任务退出码精确捕获的几种方法一次讲透，全是能直接抄的代码。 为什么直接 wait 拿不到退出码 先说清楚问题根源。不带参数的 wait 会等所有后台任务结束，但它的返回值和子任务的成败没有关系——在 bash 里，裸 wait 的退出码通常就是 0（除非 wait 本身被信号打断）。所以下面这...

xargs 是 Linux 批量处理离不开的工具，但任务一多，子进程各自返回什么状态、哪个环节出了问题，往往只能靠手动翻日志排查。有没有办法让退出码汇总自动化？本文提供 5 种实战方案，从最基础的逐行记录到专业的 CSV 报表，总有一款适合你。退出码基础：xargs 会返回什么？ 在动手写脚本之前，先搞清楚 xargs 的退出码规则： 0：所有子进程都成功执行 123：部分或全部子进程退出码非0 124：发生了超时（用了 timeout 或外部 timeout 命令） 125...

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

很多人只把 「timeout」 命令当成"到点就杀进程"的工具，默认发的是 SIGTERM。但如果被控制的是 Nginx、sshd 这类服务型进程，直接终止会中断正在处理的连接。其实 「timeout -s」 可以指定发送任意信号，配合 SIGHUP 就能实现"超时后不杀进程，而是触发一次优雅的重载/重启"。这篇把 SIGHUP 的语义、「timeout -s SIGHUP」 的正确写法和几个实战坑一次讲清楚。 为什么优雅重启要用 SIGHUP 而不是 SIGTERM Li...

为什么SIGTERM杀不掉的进程需要SIGKILL 在Linux运维中，timeout命令是控制任务执行时间的利器。默认情况下，timeout向目标进程发送SIGTERM（15号信号），相当于礼貌地说"请结束工作"。这个机制对正常进程有效，但如果遇到以下几类进程，SIGTERM就彻底失效了：无限循环且不响应信号的C程序、僵尸进程（Z状态）、处于不可中断睡眠（D状态）的进程、卡在系统调用中的进程。这时候只能动用SIGKILL（9号信号），它的特点是：不可捕获、不可忽略、不可阻挠...

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

做批量任务的时候，最怕的不是任务跑得慢，而是跑完了不知道发生了什么。超时了多少个？哪些是因为网络慢，哪些是因为程序本身卡住了？退出码是124还是143？如果用xargs配合timeout跑并行任务，这些信息默认只会打印到终端，关掉终端就没了。 本文给出3套实战脚本，把xargs并行任务的超时结果完整导出成CSV文件，配合awk、grep三秒定位问题任务，实现批量异常追踪自动化。 一、为什么并行任务超时必须有CSV日志 xargs配合timeout做并行处理时，默认行为是...

为什么要在 crontab 定时任务里加 timeout 定时任务最怕的不是报错，而是“卡死”。备份脚本、数据同步、远程 API 拉取这类任务，一旦遇到网络抖动或下游无响应，很可能一挂就是几个小时。更糟的是，cron 不管你上次跑没跑完，到点又拉起一个，进程层层叠加，CPU、内存、数据库连接数很快被打爆。给 crontab 任务套一层 timeout 超时控制，是成本最低、见效最快的解法——它本来就是 coreutils 自带的，绝大多数 Linux 发行版开箱即用，几乎零依...

Linux的timeout命令有个很实用的参数：-s。它允许你在超时时发送自定义信号，而不是默认的SIGTERM。这个功能看似简单，但在实际生产环境中能解决不少棘手问题。 为什么需要自定义信号 timeout默认发送SIGTERM信号(15号信号)。这个信号很"温和"——进程可以捕获它并做清理工作。但有些进程会忽略SIGTERM，或者你希望进程在超时前完成特定操作，这时候就需要自定义信号。 常见场景： 顽固进程：某些Java应用、数据库进程捕获了SIGTERM但拒绝...