Linux守护进程的启动方法

Linux

问题由来

当Web应用写好后，下一件事就是启动，让它一直在后台运行，举例来说，你在命令行下启动一个rails server：

$ bundle exec rails server

看上去一切正常，所有人都能愉快地访问3000端口了。但是，一旦你退出命令行窗口，这个应用就跟着一起退出了，此时无法访问url。

怎么才能让它变成系统的守护进程（daemon），成为一种服务（service），一直在那里运行呢？

前台任务与后台任务

像上面那样启动网站，叫做”前台任务”（foreground job）。它会独占命令行窗口，只有运行完了或者手动中止，才能执行其他命令。

变成守护进程的第一步，就是把它改成”后台任务”（background job）。

$ bundle exec rails server &

只要在命令的尾部加上&，启动的进程就会变成“后台任务”。如果想让正在运行的“前台任务”变成“后台任务”，可以先按ctrl + z，然后执行bg命令（让最近一个暂停的“后台任务”继续执行）。

后台任务有两个特点：

  1. 继承当前 session （对话）的标准输出（stdout）和标准错误（stderr）。
    因此，后台任务的所有输出依然会同步地在命令行下显示。
  2. 不再继承当前 session 的标准输入（stdin）。你无法向这个任务输入指令了。
    如果它试图读取标准输入，就会暂停执行（halt）。

可以看到，”后台任务”与”前台任务”的本质区别只有一个：是否继承标准输入。所以，执行后台任务的同时，用户还可以输入其他命令。

SIGNUP信号

变为”后台任务”后，一个进程是否就成为了守护进程呢？或者说，用户退出 session 以后，”后台任务”是否还会继续执行？

Linux系统是这样设计的。

  1. 用户准备退出session
  2. 系统向该session发出SIGHUP信号
  3. session将SIGHUP信号发给所有子进程
  4. 子进程收到SIGHUP信号后，自动退出

上面的流程解释了，为什么”前台任务”会随着 session 的退出而退出：因为它收到了SIGNUP信号。

那么，“后台任务”是否也会收到SIGNUP信号？

这是由Shell的huponexit参数决定的。

$ shopt | grep huponexit

执行上面的命令，就会看到huponexit参数的值。

大多数Linux系统，这个参数默认关闭（off）。因此，session退出的时候，不会把SIGHUP信号发给”后台任务”。所以，一般来说，”后台任务”不会随着session一起退出。

disown命令

通过”后台任务”启动”守护进程”并不保险，因为有的系统的huponexit参数可能是打开的（on）。

更保险的方法是使用disown命令。它可以将指定任务从”后台任务”列表（jobs命令的返回结果）之中移除。一个”后台任务”只要不在这个列表之中，session就肯定不会向它发出SIGHUP信号。

$ bundle exec rails server &
$ disown

执行上面的命令以后，Rails进程就被移出了”后台任务”列表。你可以执行jobs命令验证，输出结果里面，不会有这个进程。

disown的用法如下：

# 移出最近一个正在执行的后台任务
$ disown

# 移出所有正在执行的后台任务
$ disown -r

# 移出所有后台任务
$ disown -a

# 不移出后台任务，但是让它们不会收到SIGHUP信号
$ disown -h

# 根据jobId，移出指定的后台任务
$ disown %2
$ disown -h %2

nohup命令

还有比disown更方便的命令，就是nohup。

$ nohup bundle exec rails server &

nohup命令对Rails进程做了三件事：

  1. 阻止SIGHUP信号发到这个进程。
  2. 关闭标准输入。该进程不再能够接收任何输入，即使运行在前台。
  3. 重定向标准输出和标准错误到文件nohup.out。

也就是说，nohup命令实际上将子进程与它所在的session分离了。

注意，nohup命令不会自动把进程变为”后台任务”，所以必须加上&符号。