9
28
2017
7

To hup or not to hup

故事起源于同事想在后台跑一个服务:

$ nohup node xxx.js &

一切如愿。

——是吗?

实际情况是,这时退出 bash 是如愿了,但是直接关掉终端窗口的话,那个服务会死掉。

bash 奇怪行为之五

(我好像没有写前四个耶。等有时间了简单写一下吧。)

man bash 然后搜索 SIGHUP,你会发现,其实默认设置,bash 正常退出时,根本不会杀害后台进程。它们会和从脚本里运行时一样欢快地继续跑下去。只有 bash 因为收到 SIGHUP 而退出时,它才会给后台进程发 SIGHUP。

所以,直接 Ctrl-D 或者 exit 退出的话,(处理好了重定向的话,)要不要 nohup 都一样,进程不会死。

zsh 默认退出时会给后台任务发送 SIGHUP(除非你 disown 了)。

但这还是不能解释关窗口的时候,服务为什么会死掉呀?nohup 不是已经忽略掉 SIGHUP 了么?

与众不同的 nodejs

通常情况下,nohup 工作得很好。但是,UNIX 世界里来了位不了解、也不愿意遵循 UNIX 传统惯例的年轻气盛的小伙子。

我还记得 npm 直接往 /usr 下安装东西。

我还记得 npm 把 http_proxy 当 https_proxy 而我的缓存代理不支持 HTTPS,造成无法安装任何东西。

现在,nodejs 将所有信号的处理重置为默认行为,除了它自己想处理的那几个。

「nohup?那是什么鬼?我搞不懂!」nodejs 说,然后它被 SIGHUP 杀死了。

结语

The devil is in the detail!

Category: Linux | Tags: nodejs linux bash shell
6
30
2017
3

nodejs 子进程的正确用法(你应该忽视函数名)

因为库太拙了,需要在 nodejs 里调用子进程来获取数据。然而看到 child_process 的文档真是头疼,这么多种启动子进程的方法直接推到人面前,也没个解释,命名也十分无用。只能一个个地查看详细说明来找到应该使用的那个……所以我整理了一下。

首先是同步创建子进程的那几个函数。会阻塞 nodejs 的主循环。无用。(要是写小脚本的话我直接上 shell 或者 Python 了,干嘛跟自己过不去呢。)

exec:调用 shell 来执行命令的。这部分跟「exec」这个词的 UNIX/C 语义刚好相反。

execFile:不调用 shell,直接执行命令。这命名不明所以。

fork:执行一个新的 nodejs 进程,并且建立一个专用的 IPC 通道。子进程除了 IPC 通道外与父进程无任何瓜葛!命名真是一如既往地误人子弟。默认使用与父进程相同的可执行文件(nodejs 版本),也可以另外指定。

spawn:相当于 Python 的 subprocess,可以指定是否使用 shell。默认不使用 shell。也支持 cwd 啊 env 啊 argv0 啊之类的参数。

结论:如果需要用 Python 的 subprocess.run / Popen 类似的功能,就使用 child_process.spawnexec 开头的那个函数似乎没啥大用,大概跟 subprocess 的 getoutput / check_call 之类的一样只是有一些预设而已吧。

Category: nodejs | Tags: nodejs
4
7
2015
5

疯狂的 npm(图)

以前这服务器就经常被 OOM Killer 大开杀戒,各种服务都被杀害。虽然早就通过日志和其它信息知道是 npm 惹的祸,今天才有幸看到如此疯狂的 npm(点击查看大图):

crazy npm htop screenshot

说明一下,此 npm install 是正在安装 gulp 相关的东西。在本地跑的时候倒是没发现 npm 有如此「牛力」,只是比较费时费内存而已,不知道在这服务器上是发了什么疯。

Category: Javascript | Tags: nodejs javascript npm

部分静态文件存储由又拍云存储提供。 | Theme: Aeros 2.0 by TheBuckmaker.com