LinuxのSSH接続が切れて長時間処理が消えた日の話|SE時代のtmux未知期と現役講師が語るセッション管理の鉄則

HOMEリナックスマスター.JP 公式ブログLinux学習ガイド > LinuxのSSH接続が切れて長時間処理が消えた日の話|SE時代のtmux未知期と現役講師が語るセッション管理の鉄則
宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
「SSHを切ったら動かしていた処理が全部消えていた。一晩かけた作業がゼロになった。なぜですか?」

Linuxサーバーに慣れてきた頃、誰もが一度はこの落とし穴にはまります。夜中に動かし始めた重い処理が翌朝消えていた経験は、私も20年以上のサーバー運用の中で何度か体験しました。SE時代(2001年~2006年)に遭遇したある事件がきっかけで、SSHのセッション管理を真剣に学ぶことになりました。

この記事では、SSH切断で処理が止まる仕組みから、nohup・screen・tmuxを使った対策まで、現役講師の実体験とともに解説します。バックアップ処理や時間のかかるビルド作業を安全に動かすための「型」として、ぜひ身につけてください。

この記事のポイント

・SSH切断でプロセスが止まる原因はSIGHUP(シグナル)の連鎖にある
・nohupは「SIGHUP無視」でシンプルな長時間処理に有効
・tmuxはデタッチ・アタッチで処理中のセッションに再接続できる
・SSH設定(ServerAliveInterval)でそもそもの切断を防ぐことも重要


LinuxのSSH接続が切れて長時間処理が消えた日の話|SE時代のtmux未知期と現役講師が語るセッション管理の鉄則
「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

なぜSSH接続が切れると実行中の処理も止まるのか

Linuxには「シグナル(signal)」という、プロセスに通知を送る仕組みがあります。その中でも、SSH切断に深く関わるのがSIGHUP(Signal Hang UP)です。

仕組みはこうです。SSHでサーバーに接続してコマンドを実行すると、そのコマンドは「SSHセッションのターミナル」を親プロセスとして動き始めます。ネットワーク障害やPCのスリープでSSH接続が切断されると、カーネルはセッションの親プロセス(シェル)へSIGHUPを送ります。SIGHUPを受け取ったシェルは終了し、その子プロセスとして動いていたコマンドも連鎖的に強制終了されます。

「SSH接続が親で、コマンドが子」という親子関係があるため、親が終了すると子も道連れになる。これはLinuxの基本設計であり、バグではありません。知らなければ事故が起き、知っていれば確実に回避できる仕組みです。

私が現場でよく見かけるのが、この仕組みを理解せずに「タイムアウトで処理が終わった」「コマンドがバグっていた」と勘違いしてしまうケースです。長時間処理が途中で止まっている場合、原因の大半はSSH切断によるSIGHUPです。まずここを疑ってください。

なお、SIGHUPの「HUP」は昔の電話回線(ハングアップ)に由来します。端末との接続が切れたことをプロセスに通知するために設計されたシグナルで、Linuxが電話回線の時代から引き継いだ歴史的な仕組みです。初出の補足として触れておくと、シグナル番号は1番(SIGHUP=1)で、killコマンドでも送出できます。

SE時代に経験した「一晩かけた処理が翌朝全部消えていた」事件

2004年頃の話です。客先のサーバーで大規模なMySQLデータのマイグレーション作業を担当していました。データ量は数十ギガ。当時のサーバースペックと回線状況では、mysqldumpの実行に5~6時間かかる見積もりでした。

業務終了後にSSHで接続してコマンドを実行し、ターミナルには順調に処理の経過が出力されています。「このまま朝まで動いているはずだ」と確認してPCを机の上に置いたまま帰宅しました。

翌朝、出社して確認したところ、ターミナルには何も残っていません。バックアップファイルも存在しない。ログを確認すると、深夜2時頃に処理が途切れていました。後から判明したのは、社内ネットワークのスイッチが深夜に自動メンテナンスで再起動していたことでした。そのタイミングでSSH接続が切断され、SIGHUPによってmysqldumpプロセスが強制終了されていたのです。

結果、作業は最初からやり直しになりました。当時の私はnohupもscreenも知らなかった。先輩エンジニアに相談したところ「そんな長い処理をSSH直接で動かすな、nohupかscreenを使え」と一言。その日から私のLinuxの学び方が変わりました。

受講生からよく聞かれる質問が「SSHでコマンドを実行してから帰っても大丈夫ですか?」というものです。答えはケースによって違いますが、基本的に「そのままでは止まります」です。これを知らずに現場に入ると、同じ失敗を繰り返すことになります。セミナーで3,100名以上を指導してきた中で、このSSH切断トラブルは「あるある失敗談」として毎回必ず出てくる話題です。

nohupコマンドでSSH切断に備える基本の手順

まず一番シンプルな対策が、nohupコマンドです。nohup(no hang up)はコマンドの前に付けるだけでSIGHUPを無視させることができます。書き方はシンプルです。

# nohupの基本的な使い方 # コマンドの前に nohup を付けるだけ nohup mysqldump -u root -p mydb > /backup/mydb_backup.sql & # & でバックグラウンド実行にすることでプロンプトが戻ってくる # 実行後、プロセスIDが表示される(例: [1] 12345) # 出力は自動でカレントディレクトリの nohup.out に書き出される tail -f nohup.out

nohupでコマンドを実行すると、SSH接続が切れても該当プロセスは動き続けます。長時間処理の出力を別のログファイルに保存したい場合は、リダイレクトを使います。

# 出力先を明示的に指定する書き方 nohup rsync -avz /data/source/ /backup/dest/ > /var/log/rsync_backup.log 2>&1 & # バックグラウンドのジョブ確認 jobs -l # プロセスが動いているか確認(プロセス名で検索) # ps aux | grep rsync | grep -v grep ps aux | grep rsync

ただし、nohupはあくまで「SIGHUP無視」の機能です。セッションへの「再接続」はできません。コマンドを実行してSSH切断後に別のターミナルから接続し直しても、nohupで実行中のプロセスに対話的に操作する手段はありません。進捗確認はtailコマンドでログファイルを確認するしかないです。

それで十分なケースも多いですが、「実行中の処理に後から操作したい」「複数のコマンドを並行して管理したい」場合には不十分です。そこで登場するのがscreenとtmuxです。

screenとtmuxで「セッションを永続化する」という発想転換

screenとtmuxは「ターミナルマルチプレクサ」と呼ばれるソフトウェアです。仕組みはシンプルで、SSHとコマンドの間に仮想セッションを挟むことで、SSH接続が切れてもコマンドが動き続けるようにします。

さらに重要な特徴が「デタッチ(detach)」と「アタッチ(attach)」です。セッションからデタッチするとSSH接続を切っても処理は継続します。後から別のSSHセッションでアタッチすれば、まるで離席前の画面に戻ったかのように操作を再開できます。

現在の主流はtmuxです。screenよりも機能が豊富で、RHEL 9・AlmaLinux 9・Ubuntu 24.04 LTSではdnfまたはaptでインストールできます。tmuxの基本的な使い方は以下のとおりです。

# tmuxのインストール(RHEL9/AlmaLinux9/Rocky Linux 9系) # sudo dnf install -y tmux # tmuxのインストール(Ubuntu 24.04 LTS) # sudo apt install -y tmux # 新しいセッションを名前付きで開始 tmux new-session -s backup_work # セッション内でコマンドを実行 mysqldump -u root -p mydb > /backup/mydb_backup.sql # セッションからデタッチ(SSH接続を切っても処理は継続) # Ctrl + b を押してから d キー # 別のSSHセッションから再接続してアタッチ tmux attach-session -t backup_work # 実行中のセッション一覧を確認 tmux list-sessions

私がセミナー受講生にtmuxを教えるとき必ず強調するのは「Ctrl+b の後に d」というデタッチ操作です。これだけ覚えれば、長時間処理をセッションに預けてSSH接続を安全に切ることができます。実務で毎日使う操作ですが、現場に入るまで知らなかったというエンジニアが意外と多いです。

また、tmuxにはウィンドウ分割機能もあります。一つのSSH接続の中でターミナルを縦・横に分割して複数のコマンドを同時に見ながら作業できます。サーバー構築作業でログをtailで流しながら別ウィンドウでコマンドを打つ、というスタイルは現場では当たり前になっています。

tmux new-session -s 名前:名前付きセッションを新規作成
tmux attach-session -t 名前:既存セッションにアタッチ
Ctrl+b → d:セッションからデタッチ(処理継続)
tmux kill-session -t 名前:セッションを終了する

SSH切断やtmux接続に関するよくあるトラブルとエラーの対処

tmuxやnohupを使い始めると、次は別のトラブルに出会います。現場でよく見かける問題と対処をまとめます。

「Write failed: Broken pipe」が出てSSHが頻繁に切れる
SSHの接続タイムアウトで発生します。サーバー側またはクライアント側の設定でキープアライブを有効にするのが対処法です。クライアント側(自分のPC)の ~/.ssh/config に以下を追記します。

# ~/.ssh/config に追記(クライアント側の設定) Host * ServerAliveInterval 60 ServerAliveCountMax 3 # ServerAliveInterval: 60秒ごとにキープアライブパケットを送る # ServerAliveCountMax: 3回応答がなければ接続を切る # この設定により、アイドル中のSSH接続が自動切断されにくくなる

「sessions should be nested with care」というtmuxの警告が出る
tmuxセッションの中でさらにtmuxを起動しようとすると出ます。tmuxは入れ子(ネスト)にできますが、通常は不要です。既存のセッションにアタッチするつもりであれば、まず tmux list-sessions でセッション名を確認してから tmux attach-session -t 名前 でアタッチしてください。

nohupで実行したはずなのにプロセスが止まっている
nohupを付けてもSIGTERM(kill)やSIGKILLには無力です。システムの再起動・リソース枯渇・OOM Killerによる強制終了は防げません。また、コマンドの出力先がいっぱい(ディスクフル)になった場合も処理が止まります。長時間処理を動かす前には df -h でディスク空き容量を確認するのが鉄則です。【注意】nohupを過信せず、処理の進捗確認とディスク残量チェックを定期的に行ってください。

tmuxセッションが終わらずゾンビプロセス化している
tmuxのセッション内で実行したコマンドが終了しているのにセッションが残り続けることがあります。tmux list-sessions で一覧を確認し、不要なセッションは tmux kill-session -t セッション名 で終了します。本番サーバーではセッションの残骸がリソースを占有することがあるので、作業後の後片付けも大事です。

まとめ:SSH切断から処理を守るための選択肢と使い分け

SSH接続が切れると処理が止まる理由と、それを防ぐための3つの手段を解説しました。どの方法を選ぶかは作業の性質によって変わります。以下のまとめ表を参考にしてください。

場面・目的 推奨する方法 特徴
シンプルな一発コマンドを放置したい nohup コマンド & ツールのインストール不要。最小構成で使える
実行中のセッションに後から再接続したい tmux new-session -s 名前 デタッチ・アタッチで作業の継続が可能
SSH接続が頻繁に切れて困っている ~/.ssh/config に ServerAliveInterval 設定 根本的な切断防止。全接続に適用できる
複数コマンドを並行して管理したい tmux のウィンドウ分割機能 一画面で複数ターミナルを扱える
長時間処理のログを後で確認したい nohup コマンド > ログファイル 2>&1 & 出力をファイルに保存してtailで追跡

「SSHを切ったら処理が消えた」は初心者が必ずぶつかる壁ですが、nohupとtmuxのどちらかを知っているだけで確実に回避できます。20年以上サーバーを運用してきた経験から言うと、この2つは現場エンジニアが毎日使うツールです。コマンドを覚えるよりも「仕組み(SIGHUPの連鎖)」から理解しておくと、応用が利きます。

関連記事として、プロセス管理の基本は「Linuxのpsコマンドでプロセスを確認する方法」を、ファイアウォール設定でSSH接続をロックアウトしてしまった際の対処は「LinuxでSSHが繋がらなくなった日の話」も合わせて読んでみてください。

SSHセッション管理も含めた「現場の型」を体系的に学びませんか?

「nohupもtmuxも知らないまま現場に入ってしまった」という状況は、Linuxサーバーの基本的な仕組みを体系的に学ぶことで防げます。断片的なコマンドを覚えるのではなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。