SSH経由で次のように実行するnodejsアプリケーションがあります。
$ tmux
$ node server.js
これにより、ノードアプリケーションがtmuxセッションで起動します。
明らかに、SSHセッションを常に開いているわけではありません。
私が見つけたのは、アプリケーションがページをサーバー化しない状態になることがあるということです。これは、アプリケーション自体に関連している可能性があります。または、SSHセッションの切断が不十分である可能性があります。
いずれにせよ、SSHにログインして、以下を実行するだけです。
$ tmux attach
また、ペインにフォーカスを合わせると、すべてが再び応答します。
node.jsの全体的なポイントは、すべてが非ブロッキングであるということだと思いました。それでは、ここで何が起こっているのでしょうか。
ペインがコピー モードの場合、tmuxはその tty から読み取りません。tty 内で実行中のプログラムが引き続き出力を生成すると、OS の tty バッファーが最終的にいっぱいになり、書き込みプロセス/スレッドがブロックされます。Node.js の内部構造はわかりませんが、stdout/stderr への書き込みがブロックされるとは想定していない可能性があります。console関数にはコールバックがないように見えるため、実際にはブロックされている可能性があります。
そのため、SSH 接続が切断されたときに Node.js が実行されていたペインがコピー モードのままになっていると、Node.js がブロックされる可能性が非常に高くなります。
ノンブロッキング ロギングを保証する必要がある場合は、stdout と stderr をファイルにリダイレクト (またはティー) し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
または、ロギング ライブラリを使用している場合は、ファイルへの自動書き込みに使用できるものが含まれている可能性があります。