はじめに：SSH切断に強いターミナル環境を作る
クラウドやオンプレミスのUbuntuサーバーをリモート管理する際、回線トラブルやクライアント端末のスリープによるSSH切断で、実行中のバッチ処理が強制終了してしまった経験はないでしょうか。GNU screenを導入すれば、ネットワーク接続が失われても仮想端末セッションがサーバー上で稼働し続けるため、長時間のビルドやデータ移行を安全に完遂できます。本記事では、セッションの新規立ち上げからデタッチ操作、クラッシュしたセッションの修復手順、さらには実用性を高める.screenrcのカスタマイズまで、現場で役立つ運用ノウハウを体系的に解説します。
パッケージ導入と仮想セッションの起動・一覧確認
Ubuntu環境にツールを準備するため、APTリポジトリ情報を同期した上でscreenをセットアップします。以下のコマンドを入力してインストールを実行してください。
正常にバイナリが配置されたかどうかを確かめるには、screen -versionを実行してリリース情報を出力させます。端末上にバージョン番号が返ってくれば、環境構築は完了です。
⚙️ [頻出コマンドライン引数一覧]
-S : セッション識別用のカスタム名を任意に割り当てます。-ls : バックグラウンドを含む全アクティブセッションの状態を表示します。-d : 稼働中のセッションから一時的に抜けてデタッチ（切り離し）状態へ移行します。-m : 既存セッションの有無にかかわらず新規セッションの強制立ち上げを指示します。-r : デタッチ済みのバックグラウンドセッションへ再接続（アタッチ）します。-wipe : 異常終了などで応答不能（Dead）になったソケットファイルを一括消去します。
対話型の画面を開かず、直接バックグラウンドジョブとしてプロセスを走らせたい場合には、-d -mフラグを組み合わせて起動します。たとえばscreen -S backup_task -d -m sleep 60を実行すると、識別名backup_taskが割り当てられた仮想セッションが裏側で即座に生成され、60秒間の待機処理が独立して開始されます。
サーバー上で現在稼働しているセッション群を点検するには、screen -lsを呼び出します。実行結果を見ると、先ほど立ち上げたbackup_taskが固有のPIDとともに一覧へ現れ、ステータスが切り離し状態を示すDetachedとして正しくバックグラウンド保持されていることが把握できます。
独立プロセスの実行とログ監視
検証環境として、バックグラウンド処理の進行状況を記録するための作業フォルダとログファイルを準備します。mkdir -p ~/screen_demo && echo '작업 준비 완료' > ~/screen_demo/task.logを実行し、出力先の基盤を用意しておきましょう。
ループ処理を伴うシェルスクリプトを別スレッドのように動かす実践例として、screen -S build_job -d -m bash -c 'for i in {1..5}; do echo "진행 단계: $i" >> ~/screen_demo/task.log; sleep 1; done'を発行します。これにより、ターミナルフォアグラウンドを占有することなく、セッション名build_jobの配下で1秒ごとにログを追記するタスクが非同期にスタートします。
改めてscreen -lsを入力し、稼働プロセス全体のステータスを確認します。先ほど追加したbuild_jobに加え、先ほどから動いているbackup_taskの双方がDetachedとして並列で安定稼働している様子が確認可能です。
バックグラウンドセッション内の処理が滞りなく動いているかを実証するため、sleep 2 && cat ~/screen_demo/task.logで2秒待機後にログファイルを読み出します。画面の出力から、ステップごとの記録が順次蓄積されており、仮想セッション内で意図通りコマンドが進行している事実を確かめられます。
ゾンビセッションの強制終了とソケット清掃
停止処理の検証用ターゲットとして、長時間のスリープを抱えるテストセッションを仕込みます。screen -S zombie_task -d -m sleep 100を実行し、100秒間の停止ジョブを持つzombie_taskセッションをバックグラウンドへ投入してください。
screen -lsでシステム全体の現況を照会すると、新設したzombie_taskが加わり、合計3つの仮想端末がデタッチ状態で並行動作している状況が一覧表示されます。
対象セッションへ一度もアタッチすることなく外部シェルからクローズさせたい場合は、-Xオプションを活用します。screen -S zombie_task -X quitを送信すると、zombie_taskへ直接終了シグナルが伝達され、バックグラウンドジョブの停止とともにセッション自体が破棄されます。
不慮のクラッシュや通信断絶によって残留した不要なソケット情報（デッドセッション）をクリーンアップするには、screen -wipeを実行します。無効化したセッション痕跡が自動でパージされ、生存しているbuild_jobとbackup_taskのみが健全な状態で維持されていることが確認できます。
仕上げにscreen -lsでソケット一覧を再スキャンします。強制破棄したzombie_taskがきれいに除外され、計画通りの2セッションだけが正常稼働を続けていることが実証されます。
スクロールバッファ拡張と.screenrcによる環境最適化
screenの利便性を引き上げるため、ユーザー固有の設定ファイルを初期生成します。touch ~/.screenrcを実行して、ホームディレクトリ配下にコンフィグファイルを作成しましょう。
標準のままでは過去のコンソールログがすぐに押し流されてしまうため、履歴保持行数を拡大します。echo 'defscrollback 5000' >> ~/.screenrcを追記することで、バッファを5,000行まで引き上げ、大量のログ出力も遡って点検できるようになります。
ターミナル最下部にウィンドウ番号、タブ名、ホスト名を常時可視化するステータスラインを組み込みます。echo 'caption always "%{= kw}%-w%{= wk}%n %t%{-}%+w = %H"' >> ~/.screenrcを流し込むことで、現在作業中のセッション位置が一目で把握できる使い勝手の良いUIへ強化されます。
末尾に追記されたディレクティブをチェックするため、tail -n 2 ~/.screenrcを実行します。ターミナル上に先ほど指定したバッファ定義とキャプション指定が正しく書き込まれていることが確認できれば完了です。
Ubuntu環境におけるGNU screenを駆使したセッション管理とプロセス保護の手法について解説しました。ネットワークの切断リスクを回避し、夜間バッチや重い処理も安心して裏で任せられるよう、ぜひ日常のサーバー運用に取り入れてみてください。