6

我有一个通过 SSH 运行的 nodejs 应用程序：

$ tmux
$ node server.js

这将在 tmux 会话中启动我的节点应用程序。

显然，我并没有一直打开 SSH 会话。

我一直在发现，有时我的应用程序可能会处于无法提供任何页面的状态。这可能与应用程序本身有关，或者可能只是断开连接不佳的 SSH 会话。

无论哪种方式，只需登录 SSH，运行：

$ tmux attach

将焦点放在窗格上会使所有内容再次响应。

我认为 node.js 的全部意义在于一切都是非阻塞的——那么这里发生了什么？

4

1 回答 1

3

当窗格处于复制模式时，tmux不会从其 tty 读取。如果某个在 tty 中“运行”的程序继续生成输出，那么操作系统的 tty 缓冲区最终将填满并导致写入进程/线程阻塞。我不知道 Node.js 的内部结构，但它可能不会期望写入 stdout/stderr 会阻塞：这些console函数似乎没有回调，所以它们实际上可能会阻塞。

因此，如果在您的 SSH 连接断开时运行它的窗格处于复制模式，Node.js 很可能最终被阻止。

如果您需要确保非阻塞日志记录，那么您可能希望将您的 stdout 和 stderr 重定向（或 tee）到一个文件并使用类似的东西less查看以前的日志（避免tmux的复制模式，因为它可能会导致阻塞）。

也许是这样的：

# Redirect stdout/stderr to a file, running Node.js in the background.
# Start a "less +F" on the log so that we immediately have a "tail" running.
node app.js >>app.log 2>&1 & less +F app.log

或者

# This pane will act as a 'tail -f', but do not use copy-mode here.
# Instead, run e.g. 'less app.log' in another pane to review prior logs.
node app.js 2>&1 | tee -a app.log

或者，如果您使用的是日志库，它可能有一些东西可以用来自动写入文件。

于 2013-01-29T02:47:32.037 回答