Linux 技巧：让进程在后台运行更可靠的几种方法

开始概念之前首先上几个实战问答：

• 1 .如何过滤占用某个端口的进程并且kill掉？
  例答： kill -9 lsof -n -P -i TCP -s TCP:LISTEN | grep 8000 | awk '{print $2}'
  简答： kill -9 lsof -i:8000 | grep 8000 | awk '{print $2}'
• 2 .如何过滤出带有某些关键字符的运行程序并且kill掉？
  例答： kill -9 ps -ax | grep keywordsstring | awk '{print $1}'
• 3 .如何在后台启动一个服务并且将标准输出重定向到一个文件(以启动一个node服务为例)？
  例答： cd /project && (npm run dev > /project/logs/server_log_date +%Y-%m-%d.txt 2>&1 &)

一个服务的监测脚本示例：

#!/bin/bash

export PATH=$PATH:/usr/local/bin

cmd=`/usr/sbin/lsof -n -P -i TCP -s TCP:LISTEN | grep 8090`

if [ -z "$cmd" ]
then
  echo 'down...' `date` >> /project/down.txt && cd /project &&  (npm run dev > /project/logs/server_log_`date +%Y-%m-%d`.txt 2>&1 &)
else
  echo 'up...' `date` >> /project/down.txt
fi

场景：

如果我们需要一个命令或者服务处于后台运行的状态，什么方法能最简便的保证它在后台稳定运行呢？
如果们想要通过定时脚本来检测一个服务的运行状态并且在它挂掉的时候在后台重新启动它呢？

解决方法

我们知道，当用户注销（logout）或者网络断开时，终端会收到 HUP（hangup）信号从而关闭其所有子进程。因此，我们的解决办法就有两种途径：要么让进程忽略 HUP 信号，要么让进程运行在新的会话里从而成为不属于此终端的子进程。

1. nohup

[root@pvcent107 ~]# nohup ping www.ibm.com &
[1] 3059
nohup: appending output to `nohup.out'
[root@pvcent107 ~]# ps -ef |grep 3059
root      3059   984  0 21:06 pts/3    00:00:00 ping www.ibm.com
root      3067   984  0 21:06 pts/3    00:00:00 grep 3059
[root@pvcent107 ~]#

2. setsid

[root@pvcent107 ~]# setsid ping www.ibm.com
[root@pvcent107 ~]# ps -ef |grep www.ibm.com
root     31094     1  0 07:28 ?        00:00:00 ping www.ibm.com
root     31102 29217  0 07:29 pts/4    00:00:00 grep www.ibm.com
[root@pvcent107 ~]#

值得注意的是，上例中我们的进程 ID(PID)为31094，而它的父 ID（PPID）为1（即为 init 进程 ID），并不是当前终端的进程 ID。请将此例与nohup 例中的父 ID 做比较。

3. &

这里还有一个关于 subshell 的小技巧。我们知道，将一个或多个命名包含在“()”中就能让这些命令在子 shell 中运行中，从而扩展出很多有趣的功能，我们现在要讨论的就是其中之一。

当我们将"&"也放入“()”内之后，我们就会发现所提交的作业并不在作业列表中，也就是说，是无法通过jobs来查看的。让我们来看看为什么这样就能躲过 HUP 信号的影响吧。

[root@pvcent107 ~]# (ping www.ibm.com &)
[root@pvcent107 ~]# ps -ef |grep www.ibm.com
root     16270     1  0 14:13 pts/4    00:00:00 ping www.ibm.com
root     16278 15362  0 14:13 pts/4    00:00:00 grep www.ibm.com
[root@pvcent107 ~]#

从上例中可以看出，新提交的进程的父 ID（PPID）为1（init 进程的 PID），并不是当前终端的进程 ID。因此并不属于当前终端的子进程，从而也就不会受到当前终端的 HUP 信号的影响了。

还有一个常用的工具来实现这个功能： Screen，详情请参阅 Linux Screen 命令使用笔记

本文源链接 Linux 技巧：让进程在后台运行更可靠的几种方法