Linux后台进程

进程组

引入的原因: 用于控制向多个进程进行信号的分发，发给一个进程组是信号会发生给进程组中每一个进程

• 每个进程除了有一个进程ID之外,还属于一个进程组
• 进程组是一个或多个进程的集合,同一进程组中的各进程接收来自同一终端的各种信号
• 每个进程组有一个组长进程。组长进程的进程组ID等于其进程ID

会话

会话是一个或者多个进程组的集合，进程调用setsid函数建立一个会话。
进程调用setsid函数建立一个新的会话，会发生下面几件事

• 改进程变成新会话的首进程(session leader)。此时,该进程是新会话的唯一进程
• 该进程成为一个新进程的组长进程，新进程ID是该调用进程的进程ID
• 该进程没有控制终端。如果调用setsid之前该进程有一个控制终端，那么这种联系也被切断

什么是守护进程(daemon)

守护进程是生存期长的一种进程，没有控制终端。他们常常在系统引导装入时启动，系统关闭是终止。守护进程程序通常以字母d结尾。
用户层的守护进程的父进程是init进程。内核的守护进程并非init进程。

前台进程& 后台进程

以&方式运行的为后台进程
比如: ping www.baidu.com &
通过jobs命令查看

[root@iZbp1ge7stkcnj5044oa81Z ~]# jobs
[1]+  Done                    sleep 50

将后台程序放到前台

[root@iZbp1ge7stkcnj5044oa81Z ~]# fg 1
sleep 50

通过control+c命名发送’hupinit‘信号kill掉进程

以&方式运行有什么问题?

• 以&方式可以将一个前台进程以后台方式运行，但是如果它是一个终端的job,则如果终端收到SIGHUP信号。终端也会向他所有的job发送SIGHUP。这样以&方式运行的进程则会因收到SIGHUP信号而退出。
• 当用户注销或者网络切开时，终端会收到SIGHUP信号而关闭所有子进程

实现长时间运行的进程

终端被挂断或者用户注销，SIGHUP信号会被发送到该终端相关的控制程序,而SIGHUP的默认行为是终止程序的运行。
需要实现终端退出后进程依然在后台运行，有两种途径

• 进程收到SIGHUP后忽略该信号(nohup)
• 进程根本没有收到SIGHUP信号(setsid)

nohup VS setsid

1. nohup
   nohup在收到进程的sighup信号之后忽略该信号,除此之外还做了以下几件事

• 关闭进程的stdin,当进程尝试读取输入时候，只会得到EOF
• 重定向进程的stdout和stderr到nohup.out中
  由于进程的stdin,stdout,stderr都脱离了终端，因此让它在前台运行意义不大，一般我们在后面加上& 让它在后台运行。

[root@iZbp1ge7stkcnj5044oa81Z ~]# ps -ef | grep ping
root     26157 26114  0 10:53 pts/6    00:00:00 ping www.baidu.com

2. setsid
   nohup是通过忽略HUP信息来使我们的进程避免中断，setsid可以使我们的进程不接受HUP信号
   调用setsid函数的进程如果不是一个进程组长就会创建一个新会话，具体来说发生3件事

• 该进程会变成新会话的首进程，此时新会话只有该进程这么一个进程
• 该进程会变成一个新进程组的组长进程，新进程组ID就是该进程的PID
• 该进程与控制终端的联系被切断

如果setid函数的进程就是一个进程组的组长，则函数会返回出错。为了解决这样情况，通常函数需要先fork,然后父进程退出，由子进程执行setsid。由于子进程继承的是父进程的进程组ID，而其PID是新分配的ID，因此这两者不可能相等，即子进程不可能是进程组的组长。 这种情况下，由于父进程先于子进程退出，因此子进程的父进程会有init进程接管。 而这就是sid命令的实现原理。
设置setsid www.baidu.com
我们对比下和nohup

[root@iZbp1ge7stkcnj5044oa81Z ~]# ps -ef | grep ping
root     26157 26114  0 10:53 pts/6    00:00:00 ping www.baidu.com
root     26241     1  0 11:31 ?        00:00:00 ping www.baidu.com

我们可以看到setsid的父进程变成了init进程。由于会话和父进程和shell无关了，因此无论如何shell都无法向该进程发送SIGHUP命令