xshell查看sh脚本进程

登录服务器后敲下 ps aux | grep your_script.sh，脚本进程返回结果里只有一行 grep 自身的脚本进程进程——脚本没在跑。这种事我遇到过不下十次，脚本进程多数时候是脚本进程同事在 Xshell 里用 sh start.sh 启动后直接关了会话窗口，进程跟着 SIGHUP 一起消失了。脚本进程所以“查看 sh 脚本进程”这件事，脚本进程第一步不是脚本进程查，而是脚本进程先搞清楚它到底还在不在。

Xshell 本身没有进程管理面板，脚本进程它就是脚本进程个终端模拟器。真正干活的脚本进程是你连上的那台 Linux。查进程靠的脚本进程是 shell 命令，Xshell 只负责把命令送过去、脚本进程把结果画出来。脚本进程别在 Xshell 的脚本进程菜单里翻找什么“进程列表”，找不到的。

ps 组合拳，先定位再确认

最直接的写法：

ps -ef | grep -v grep | grep your_script.sh

-v grep 把那条烦人的 grep 自身过滤掉。如果输出里有 PID、启动时间、完整命令，说明进程活着。我习惯再加个 --color，命中行会高亮，眼睛舒服点。

但有个坑：脚本名太短会误伤。比如脚本叫 run.sh，系统里可能有一堆同名的。这时候看完整路径：

ps -ef | grep -v grep | grep "/opt/app/run.sh"

或者用 pgrep -af run.sh，-a 显示完整命令行，比 ps 管道清爽。pgrep 返回的是 PID 列表，拿去做后续操作很方便，比如 kill $(pgrep -f run.sh)。

进程在，但你看不到输出

另一个常见场景：ps 查到了进程，PID 是 12345，可你不知道它跑到哪一步了。脚本里如果没写日志，Xshell 窗口又关了，stdout 就丢了。这时候能做的有限——

ls -l /proc/12345/fd/ 看看它的文件描述符指向哪里。如果 1 和 2 指向 /dev/pts/0 这种伪终端，说明输出还挂在某个会话上；指向 /dev/null 就彻底没了。我一般会先 cat /proc/12345/cmdline | tr '\0' ' ' 确认命令行参数，再用 strace -p 12345 看它卡在哪个系统调用上。strace 输出很吵，加 -e trace=network,file 能收敛一些。

为什么关掉 Xshell 脚本就死了

因为 sh script.sh 启动的进程，父进程是当前 shell。Xshell 断开，shell 收到 SIGHUP，默认行为是把这个信号转发给它所有的子进程。脚本没做信号处理，直接退出。

解决办法不是“查看进程”，而是“让它别死”。nohup 是最省事的：

nohup sh your_script.sh > /var/log/your_script.log 2>&1 &

末尾的 & 让它进后台，nohup 屏蔽 SIGHUP。> log 2>&1 把标准输出和错误都重定向到日志文件。之后再用 ps 查，PID 稳定，日志也能随时 tail -f 看。

更稳妥的是 systemd 或 supervisor，但那是另一回事了。临时跑个脚本，nohup 够用。

一个真实翻车案例

上个月同事在 Xshell 里跑数据迁移脚本，sh migrate.sh，跑了四十分钟。他看进度条不动，以为卡死了，直接 Ctrl+C。实际上脚本在等一个慢查询返回。Ctrl+C 把整个进程组杀了，迁移到一半，表锁没释放。后来我们查 /var/log/messages 才定位到。如果当时他用的是 nohup ... &，再开一个 Xshell 窗口 tail -f 日志，根本不会出这事。

所以“查看 sh 脚本进程”这个动作，往往发生在出问题之后。与其事后 ps 翻找，不如启动时就把它扔进后台、写好日志。Xshell 只是个窗口，别让窗口的生死决定脚本的生死。