"守护进程"(daemon)就是一直在后台运行的进程(daemon)。
本文介绍如何将一个 Web 应用,启动为守护进程。
一、问题的由来
Web应用写好后,下一件事就是启动,让它一直在后台运行。
这并不容易。举例来说,下面是一个最简单的Node应用server.js
,只有6行。
var http = require('http'); http.createServer(function(req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World'); }).listen(5000);
你在命令行下启动它。
$ node server.js
看上去一切正常,所有人都能快乐地访问 5000 端口了。但是,一旦你退出命令行窗口,这个应用就一起退出了,无法访问了。
怎么才能让它变成系统的守护进程(daemon),成为一种服务(service),一直在那里运行呢?
二、前台任务与后台任务
上面这样启动的脚本,称为"前台任务"(foreground job)。它会独占命令行窗口,只有运行完了或者手动中止,才能执行其他命令。
变成守护进程的第一步,就是把它改成"后台任务"(background job)。
$ node server.js &
只要在命令的尾部加上符号&
,启动的进程就会成为"后台任务"。如果要让正在运行的"前台任务"变为"后台任务",可以先按ctrl + z
,然后执行bg
命令(让最近一个暂停的"后台任务"继续执行)。
"后台任务"有两个特点。
- 继承当前 session (对话)的标准输出(stdout)和标准错误(stderr)。因此,后台任务的所有输出依然会同步地在命令行下显示。
- 不再继承当前 session 的标准输入(stdin)。你无法向这个任务输入指令了。如果它试图读取标准输入,就会暂停执行(halt)。
可以看到,"后台任务"与"前台任务"的本质区别只有一个:是否继承标准输入。所以,执行后台任务的同时,用户还可以输入其他命令。
三、SIGHUP信号
变为"后台任务"后,一个进程是否就成为了守护进程呢?或者说,用户退出 session 以后,"后台任务"是否还会继续执行?
Linux系统是这样设计的。
- 用户准备退出 session
- 系统向该 session 发出
SIGHUP
信号- session 将
SIGHUP
信号发给所有子进程- 子进程收到
SIGHUP
信号后,自动退出
上面的流程解释了,为什么"前台任务"会随着 session 的退出而退出:因为它收到了SIGHUP
信号。
那么,"后台任务"是否也会收到SIGHUP
信号?
这由 Shell 的huponexit
参数决定的。
$ shopt | grep huponexit
执行上面的命令,就会看到huponexit
参数的值。
大多数Linux系统,这个参数默认关闭(off
)。因此,session 退出的时候,不会把SIGHUP
信号发给"后台任务"。所以,一般来说,"后台任务"不会随着 session 一起退出。
四、disown 命令
通过"后台任务"启动"守护进程"并不保险,因为有的系统的huponexit
参数可能是打开的(on
)。
更保险的方法是使用disown
命令。它可以将指定任务从"后台任务"列表(jobs
命令的返回结果)之中移除。一个"后台任务"只要不在这个列表之中,session 就肯定不会向它发出SIGHUP
信号。
$ node server.js & $ disown
执行上面的命令以后,server.js
进程就被移出了"后台任务"列表。你可以执行jobs
命令验证,输出结果里面,不会有这个进程。
disown
的用法如下。
# 移出最近一个正在执行的后台任务 $ disown # 移出所有正在执行的后台任务 $ disown -r # 移出所有后台任务 $ disown -a # 不移出后台任务,但是让它们不会收到SIGHUP信号 $ disown -h # 根据jobId,移出指定的后台任务 $ disown %2 $ disown -h %2
五、标准 I/O
使用disown
命令之后,还有一个问题。那就是,退出 session 以后,如果后台进程与标准I/O有交互,它还是会挂掉。
还是以上面的脚本为例,现在加入一行。
var http = require('http'); http.createServer(function(req, res) { console.log('server starts...'); // 加入此行 res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World'); }).listen(5000);
启动上面的脚本,然后再执行disown
命令。
$ node server.js & $ disown
接着,你退出 session,访问5000端口,就会发现连不上。
这是因为"后台任务"的标准 I/O 继承自当前 session,disown
命令并没有改变这一点。一旦"后台任务"读写标准 I/O,就会发现它已经不存在了,所以就报错终止执行。
为了解决这个问题,需要对"后台任务"的标准 I/O 进行重定向。
$ node server.js > stdout.txt 2> stderr.txt < /dev/null & $ disown
上面这样执行,基本上就没有问题了。
六、nohup 命令
还有比disown
更方便的命令,就是nohup
。
$ nohup node server.js &
nohup
命令对server.js
进程做了三件事。
- 阻止
SIGHUP
信号发到这个进程。- 关闭标准输入。该进程不再能够接收任何输入,即使运行在前台。
- 重定向标准输出和标准错误到文件
nohup.out
。
也就是说,nohup
命令实际上将子进程与它所在的 session 分离了。
注意,nohup
命令不会自动把进程变为"后台任务",所以必须加上&
符号。
七、Screen 命令与 Tmux 命令
另一种思路是使用 terminal multiplexer (终端复用器:在同一个终端里面,管理多个session),典型的就是 Screen 命令和 Tmux 命令。
它们可以在当前 session 里面,新建另一个 session。这样的话,当前 session 一旦结束,不影响其他 session。而且,以后重新登录,还可以再连上早先新建的 session。
Screen 的用法如下。
# 新建一个 session $ screen $ node server.js
然后,按下ctrl + A
和ctrl + D
,回到原来的 session,从那里退出登录。下次登录时,再切回去。
$ screen -r
如果新建多个后台 session,就需要为它们指定名字。
$ screen -S name # 切回指定 session $ screen -r name $ screen -r pid_number # 列出所有 session $ screen -ls
如果要停掉某个 session,可以先切回它,然后按下ctrl + c
和ctrl + d
。
Tmux 比 Screen 功能更多、更强大,它的基本用法如下。
$ tmux $ node server.js # 返回原来的session $ tmux detach
除了tmux detach
,另一种方法是按下Ctrl + B
和d
,也可以回到原来的 session。
# 下次登录时,返回后台正在运行服务session $ tmux attach
如果新建多个 session,就需要为每个 session 指定名字。
# 新建 session $ tmux new -s session_name # 切换到指定 session $ tmux attach -t session_name # 列出所有 session $ tmux list-sessions # 退出当前 session,返回前一个 session $ tmux detach # 杀死指定 session $ tmux kill-session -t session-name
八、Node 工具
对于 Node 应用来说,可以不用上面的方法,有一些专门用来启动的工具:forever,nodemon 和 pm2。
forever 的功能很简单,就是保证进程退出时,应用会自动重启。
# 作为前台任务启动 $ forever server.js # 作为服务进程启动 $ forever start app.js # 停止服务进程 $ forever stop Id # 重启服务进程 $ forever restart Id # 监视当前目录的文件变动,一有变动就重启 $ forever -w server.js # -m 参数指定最多重启次数 $ forever -m 5 server.js # 列出所有进程 $ forever list
nodemon
一般只在开发时使用,它最大的长处在于 watch 功能,一旦文件发生变化,就自动重启进程。
# 默认监视当前目录的文件变化 $ nodemon server.js # 监视指定文件的变化 $ nodemon --watch app --watch libs server.js
pm2 的功能最强大,除了重启进程以外,还能实时收集日志和监控。
# 启动应用 $ pm2 start app.js # 指定同时起多少个进程(由CPU核心数决定),组成一个集群 $ pm2 start app.js -i max # 列出所有任务 $ pm2 list # 停止指定任务 $ pm2 stop 0 # 重启指定任务 $ pm2 restart 0 # 删除指定任务 $ pm2 delete 0 # 保存当前的所有任务,以后可以恢复 $ pm2 save # 列出每个进程的统计数据 $ pm2 monit # 查看所有日志 $ pm2 logs # 导出数据 $ pm2 dump # 重启所有进程 $ pm2 kill $ pm2 resurect # 启动web界面 http://localhost:9615 $ pm2 web
十、Systemd
除了专用工具以外,Linux系统有自己的守护进程管理工具 Systemd 。它是操作系统的一部分,直接与内核交互,性能出色,功能极其强大。我们完全可以将程序交给 Systemd ,让系统统一管理,成为真正意义上的系统服务。
下一篇文章,我就来介绍 Systemd。
(完)
石樱灯笼博客 说:
为何不提一下daemontools?
2016年2月28日 12:37 | # | 引用
invain 说:
第六小节标题和接下来的一行
nohup误为nohub
2016年2月28日 12:41 | # | 引用
阮一峰 说:
@invain:
谢谢指出,已经改正
2016年2月28日 12:43 | # | 引用
张骅 说:
赞一个,写得很详细。个人最喜欢screen,一直以来用的是他。
2016年2月28日 21:18 | # | 引用
hujiaxing 说:
setsid呢?
2016年2月28日 22:14 | # | 引用
macafee 说:
第六章有误,一会NOHUB,一会NOHUP。改改吧!
2016年2月29日 09:11 | # | 引用
antsword 说:
我在mac下,《五、标准 I/O》这一部分,disown后5000端口正常连接,页面访问也能成功,是平台原因么?
2016年2月29日 10:20 | # | 引用
antsword 说:
抱歉,是我出错了,没有关闭session,没看到哪里删除评论,添麻烦了
2016年2月29日 10:23 | # | 引用
阮一峰 说:
@ macafee:
谢谢指出,都改过来了。
2016年2月29日 11:20 | # | 引用
聚奇酷jqk6 说:
也可以用fork + waitpid的方法建立自己的守护进程,父进程对子进程的状态改变进行监控,从而实现完全自主控制的效果。
2016年2月29日 15:04 | # | 引用
RedMothball 说:
已阅 很赞 平时主要用 nohup ;-) 还有nohup可以加 2>1 这样的参数,把输出重新定向
2016年3月 1日 09:30 | # | 引用
dong4stop 说:
unix用daemon linux下用screen
2016年3月 1日 10:23 | # | 引用
gary 说:
最近正困惑着一块,太赞了!!
2016年3月 3日 09:14 | # | 引用
刀尖红叶 说:
期待systemd的讲解!
2016年3月 3日 15:16 | # | 引用
崔钢 说:
一般我用tmux
2016年3月 4日 10:27 | # | 引用
新一 说:
Systemd 用这个才是王道
2016年3月 4日 16:03 | # | 引用
Java 说:
搞Java开发的同学可以加QQ群479189837讨论
2016年3月17日 18:01 | # | 引用
nil 说:
pm2 resurect 拼写错误? 应为 pm2 resurrect
2016年4月11日 01:37 | # | 引用
lee 说:
第三小节有问题吧:我的测试结果,huponexit参数是off,退出session,后台任务也会退出
2016年4月29日 21:34 | # | 引用
如理 说:
`ctrl + z`,然后执行`bg`,这里应该是“然后执行`fg`吧? `jobs`可以查看进程,然后`fg 1`, `fg 2`等等。
2016年5月26日 17:39 | # | 引用
Robert Lee 说:
一直在用这些功能,但是没有一篇文章把这些功能的细节和不同讲解的如此清晰的,赞!
2016年5月31日 09:10 | # | 引用
胡卢 说:
同赞! 彻底捋清楚了. 谢谢!
2016年6月29日 00:15 | # | 引用
coderselftrain 说:
阮大好厉害
2016年10月13日 14:13 | # | 引用
FridaCai 说:
每次看完阮老师的文章,都忍不住拍手叫好。深入浅出,实用!
2016年11月 9日 08:55 | # | 引用
hong 说:
阮老师,请教一下.我pm2写成json配置文件,添加cwd属性就会报错,这是什么原因呢?下面是报错的提示,其中cwd我配置的是绝对路径(试过相对路径也不行)
# pm2 start myrtc.json
[PM2][WARN] Applications myrtc not running, starting...
/usr/lib/node_modules/pm2/lib/API.js:1004
Common.printOut(conf.PREFIX_MSG + 'App [%s] launched (%d instances)', data[0].pm2_env.name, data.length);
^
TypeError: Cannot read property 'pm2_env' of undefined
2017年1月10日 16:53 | # | 引用
zhangnew 说:
supervisord 呢
2017年5月 4日 15:30 | # | 引用
darnin 说:
阮老师您好,关于《五、标准 I/O》这一部分,有个问题请教:
我使用djanog框架的runserver命令启动服务器,访问页面时后天有print 'server start'语句,看起来与您的node服务器例子原理类似,但是放到后台断开终端后继续访问却没有出现进程停止响应的状况,请问下这是什么原因?
2018年1月31日 14:32 | # | 引用
zhengfc 说:
大神,能帮忙分析下;我一后台方式运行命令,但没用nohup方式运行;
出现以下情况:
1. 当我先关闭这个xshell的session,后台方式运行的程序依然存在
2. 当我直接关闭xhsell,后台运行的程序退出运行了
huponexit为off状态
2018年4月11日 10:06 | # | 引用
xushengbin 说:
介绍的很全面
2018年5月31日 14:05 | # | 引用
akamos 说:
如果后台进程与标准I/O有交互,它还是会“挂掉”,我觉得是“挂起”,因为进程并没有被结束,容易产生误解
2018年7月10日 10:25 | # | 引用
王岩 说:
感觉,这块是讲后台任务,以及后台任务如何脱离 session;
和守护进程的定义还不是一样的吧
2018年9月16日 14:56 | # | 引用
navy 说:
我也觉得守护进程和后台进程还是有区别的,一般有一套标准程序来创建一个守护进程。还请博主有时间阐述下这两者。
2020年4月 2日 19:20 | # | 引用
feitianzhu 说:
`ctrl + z`是放入后台挂起,`bg 工作号` 可以让它后台执行, `fg 工作号`是拉回前台
2021年4月 3日 20:15 | # | 引用
大玉儿 说:
我的也是啊,
2021年9月29日 16:47 | # | 引用
LQ 说:
“可以看到,"后台任务"与"前台任务"的本质区别只有一个:是否继承标准输入。所以,执行后台任务的同时,用户还可以输入其他命令。” -- 我觉得这两者的本质区别最关键的是:bash 进程是否等待子进程结束,即对于前台任务,bash 会调用 wait 等待前台任务结束而阻塞自己。而执行后台任务时, bash 不会阻塞自己,因此可以继续标准输入获取字符串,并解释执行。
2022年5月17日 12:13 | # | 引用