この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
この記事では、nohupの存在を知らずに長時間処理を途中で止めてしまった失敗談と、そこで学んだLinuxの「SIGHUP」という仕組みをお話しします。
20年以上Linuxサーバーを運用してきた経験から言うと、この失敗はLinuxの「プロセスとシグナル」という設計思想を体で覚えるきっかけになりました。
この記事のポイント
・SSH切断でバッチ処理が止まる原因はSIGHUPシグナルにある
・nohupコマンドで起動すれば切断後もプロセスは動き続ける
・screenまたはtmuxはSSHセッション管理の現場標準ツール
・長時間処理は事前に「何分かかるか」を見積もる習慣が大切
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
SE時代に経験した「朝来たら処理が止まっていた」という失敗
私がnohupの存在を知ったのは、SE時代（2001年～2006年）の終わり頃でした。それまでの数年間、SSHでサーバーに接続してコマンドを実行し、接続を切るだけで処理が止まるということを、全く理解していませんでした。
1. 深夜に走らせた圧縮処理が翌朝消えていた
当時、私は社内のファイルサーバーから大量のログデータをアーカイブする作業を担当していました。ファイルの圧縮だけで数時間かかる見込みだったので、夜遅くにオフィスを出る前に自分のPCからSSHでサーバーに接続し、tarコマンドで圧縮を開始してそのまま帰宅しました。
# 当時、こんな形でtarコマンドを実行して帰宅した tar czf /backup/logs-archive.tar.gz /var/log/archive/
「途中でエラーになったのか」と思ってログを確認しても、異常な記録は何もありません。
残っていたのは、処理が開始されたログと、その直後に接続が切れた形跡だけでした。
2. 「接続を切ると処理も止まる」という事実を知らなかった
先輩に相談したところ、一言でこう言われました。「SSHを切ったら処理も終わるぞ。nohupを使え」
当時の私には「なぜSSHを切ると処理が止まるのか」という根本的な理由が分かっていませんでした。
「接続が切れる」ことと「プロセスが終了する」ことは、別の話だと思い込んでいたのです。
先輩に教えてもらった使い方は単純でした。
# nohupを付けてバックグラウンドで実行する nohup tar czf /backup/logs-archive.tar.gz /var/log/archive/ &
3. 同じ失敗を2回やらかしていた
実はこの失敗、私は2回やっています。最初の失敗は、ネットワーク障害で自分のPCとサーバーの接続が途切れたケースでした。
「たまたまネットワークが落ちたせいだ」と思ってやり直し、翌日にまた同じ状況になって、ようやく「これは自分の知識不足だ」と気づきました。
セミナーで3,100名以上を指導してきた中でも、同じパターンの方に何人も出会ってきました。
「再実行したら今度はうまくいった」と思い込んだまま、根本原因に気づかずに同じ失敗を繰り返してしまうパターンです。
なぜSSHが切れると処理が止まるのか
この経験で私が疑問に思ったのは「なぜSSHが切れると処理まで止まるのか」ということでした。先輩から教えてもらった内容をもとに、ここで整理しておきます。
1. 端末が閉じられるとSIGHUPシグナルが送られる
Linuxでは、SSH接続（ターミナルセッション）が閉じられると、そのセッションで起動されたプロセスに「SIGHUP（Signal Hangup）」というシグナルが送信されます。SIGHUPを受け取ったプロセスは、デフォルトの挙動として終了します。
つまり、SSH接続を切ると、そのシェルから起動した全てのプロセスに終了命令が届くわけです。
私が帰宅した後に圧縮処理が止まっていたのは、自分のPCとサーバーの接続が切れたことでSIGHUPが発生し、tarコマンドが終了していたからでした。
20年以上サーバーを運用してきた経験から言うと、「シグナルという仕組みでプロセスを制御する」という考え方が分かってくると、Linuxの動作がぐっと見えてきます。
2. nohupはSIGHUPを無視させるコマンド
nohupという名前は「no hangup（ハングアップしない）」の略です。このコマンドを付けてプロセスを起動すると、SIGHUPシグナルを無視して動き続けるよう設定された状態でプロセスが起動します。
SSH接続が切れても、プロセスは独立して動作を続けてくれます。
出力は標準でカレントディレクトリの「nohup.out」に保存されます。
出力先のファイルを指定したい場合は、リダイレクトで書き出し先を変えてください。
# nohup.outに出力を保存しながらバックグラウンド実行 nohup tar czf /backup/logs-archive.tar.gz /var/log/archive/ & # 出力ファイルを指定する場合（標準出力とエラー出力をまとめる） nohup tar czf /backup/logs-archive.tar.gz /var/log/archive/ > /tmp/backup.log 2>&1 & # バックグラウンドのプロセスを確認する jobs ps aux | grep tar | grep -v grep
「プロセスが動かない」と気づいた時の確認と対処
SSH切断でプロセスが終了していた場合は、まずプロセスの生存確認から始めてください。# バックグラウンドジョブを確認する（同じセッション内の場合） jobs # プロセス名で検索して生存を確認する ps aux | grep tar | grep -v grep # 特定のプロセスIDが動いているか確認する（PIDが分かる場合） ps -p 12345
tar.gzは途中で終了すると破損している可能性があるため、ファイルが生成されていても再実行してください。
次はnohupを使って実行しましょう。途中まで生成されたファイルがある場合は、削除してから始めてください。
# 途中まで作成されたファイルを削除する rm -f /backup/logs-archive.tar.gz # nohupで再実行する nohup tar czf /backup/logs-archive.tar.gz /var/log/archive/ > /tmp/backup.log 2>&1 & # 実行後、プロセスIDを記録する（ターミナルに表示される） # 例: [1] 14728
私が現場でよく見かけるのが、再実行した後も「本当に動いているのか」が分からず不安になってしまうケースです。
プロセスIDを記録しておき、定期的にps -pで確認する習慣をつけるだけで、その不安はなくなります。
現役講師が今も守る長時間処理の3つの鉄則
この経験以来、私は長時間かかるコマンドを実行する前に、必ず意識していることがあります。鉄則1：nohup + &でバックグラウンド実行する
処理時間が5分以上かかりそうなコマンドは、必ずnohupとバックグラウンド実行（&）をセットで使ってください。nohupはSSH切断でも処理を継続させ、&はバックグラウンドで実行させてターミナルを解放します。
nohupだけでは接続が生きている間は処理を待ち続けることになるので、セットで使うのが基本です。
nohupの詳しい使い方については「nohupコマンドでSSH切断後もコマンドを実行し続ける方法」も参考にしてください。
鉄則2：長時間の作業はscreenかtmuxのセッションで行う
nohupより一段上の管理ができるのが、screenコマンドやtmuxです。screenやtmuxは「セッション」という仮想端末を作るため、SSH接続を切ってもセッションはサーバー上で生き続けます。
再接続してアタッチするだけで、切断前の状態のターミナルがそのまま戻ってきます。
# screenで新しいセッションを作成して名前を付ける screen -S backup-job # （Ctrl+A、Dキー）でデタッチ（セッションを維持したまま切断できる） # 後から同じセッションに再接続する screen -r backup-job # セッション一覧を確認する screen -ls
「SSHが切れるかもしれない」という状況での作業では、screenかtmuxを使うのが現場の標準だと考えてください。
鉄則3：実行前に処理時間を見積もる
nohupやscreenを使うかどうかを判断するには、処理時間の見積もりが必要です。私が現場でよく見かけるのが、「すぐ終わると思った」という思い込みで、長時間処理を素のSSHで流してしまうケースです。
事前に小さいデータで試すか、処理対象のデータ量から時間を概算する習慣があれば防げます。
timeコマンドを使えば、コマンドの実行時間を計測できます。
# テストデータで処理時間を計測する time tar czf /tmp/test.tar.gz /var/log/messages # 本番データのサイズと比率から実際の処理時間を見積もる du -sh /var/log/archive/
10分、30分を超えるような処理であれば、最初からnohupかscreenを使う習慣をつけましょう。
まとめ
SSH接続が切れてバッチ処理が止まる原因は、「端末が閉じられるとSIGHUPシグナルが全子プロセスに送られる」というLinuxの仕様にあります。| 方法 | 特徴 | 使いどころ |
|---|---|---|
| nohup コマンド & | SIGHUPを無視してバックグラウンド実行 | 単発の長時間処理 |
| screen -S セッション名 | セッション維持・デタッチ・再アタッチ | インタラクティブな長時間作業 |
| tmux new -s セッション名 | 画面分割・複数ウィンドウ管理 | 複数処理の並行管理 |
長時間処理の失敗は、Linuxの「プロセスとシグナル」という設計思想を理解すれば、二度と繰り返さなくなります。
基礎から体系的に学びたい方は、ぜひ下のリンクから無料マニュアルを受け取ってください。
「nohupを知らなかった」を繰り返さないために——Linuxの現場作法を体系的に身につけませんか？
nohupやscreenの知識は「使い方を検索すれば分かる」ですが、「どんな場面で必要かを先に知っておく」ことが現場では重要です。まずはサーバー構築の全体像を掴んでください。
ネットの断片的な情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます