Linuxでプロセスをバックグラウンド実行する方法｜nohup・&・disown完全ガイド

Linux サーバー運用で必須の「プロセスをバックグラウンドで実行」する技術。

長時間かかる処理を実行する時、

# 大量データのバックアップ
./backup.sh

# データベースマイグレーション
bin/rails db:migrate RAILS_ENV=production

# 大量ファイルの一括処理
find /data -name "*.log" -exec gzip {} \;

これらをフォアグラウンドで実行すると、ターミナルが占有されて他の作業ができません。SSH 接続が切れたら処理も止まってしまいます。

そこで使うのが、

• &（アンパサンド）: バックグラウンドで起動
• nohup: SIGHUP を無視してログアウト後も継続
• disown: 既に動いているプロセスをジョブから切り離す
• screen / tmux: セッションごと永続化

しかし、いざ使おうとすると:

• & だけで SSH 切断後も動くの？
• nohup と disown の違いは？
• nohup.out って何？
• ログアウト後にプロセスが止まる…
• 出力をどこに出すべき？
• 起動済みのプロセスを切り離したい
• どれを使えばいいか分からない

など、混乱しやすいポイントが多くあります。

本記事では、Linux でプロセスをバックグラウンド実行する方法を、& / nohup / disown の3大ツールを中心にリファレンスとして完全網羅します。SIGHUP の仕組み、ジョブ管理、プロセス確認・終了、出力リダイレクト、SSH 切断耐性、screen/tmux/systemd との比較、実践パターン、FAQまで完全網羅。この1本でプロセス管理に自信を持てるようになります。

結論：今すぐ使える基本パターン10選

時間がない方向けに、頻出パターンを先に示します。

# ① バックグラウンドで起動（ターミナル開いてる間だけ）
./long_task.sh &

# ② ログアウト後も継続（推奨パターン）
nohup ./long_task.sh > task.log 2>&1 &

# ③ Ctrl+Z で一時停止 → バックグラウンドへ
./long_task.sh
# Ctrl+Z（停止）
bg              # バックグラウンドで再開

# ④ ジョブを切り離して SSH 切断後も継続
./long_task.sh &
disown          # シェルから切り離し

# ⑤ ジョブ一覧
jobs

# ⑥ バックグラウンド → フォアグラウンド
fg %1

# ⑦ プロセス確認
ps -ef | grep my_process

# ⑧ プロセス終了
kill <PID>
kill -9 <PID>   # 強制終了

# ⑨ 名前で一括終了
pkill -f "long_task"

# ⑩ 出力をログに書き出し
nohup ./task.sh >> log/task.log 2>&1 &

詳細は以下で順に解説します。

まず押さえる：SIGHUP の仕組み

SIGHUP とは

SIGHUP（Signal Hang Up、シグナル番号 1）は、Linux でターミナルが閉じられた時に親プロセスから子プロセスへ送信されるシグナル:

[SSH接続中]
ターミナル
   ↓ 起動
シェル (bash)
   ↓ 起動
プロセス (./task.sh)

[SSH切断]
ターミナルが消える
   ↓ SIGHUP 送信
シェル → プロセス
   ↓
プロセス終了

なぜ問題か

長時間処理（数時間〜数日）を実行中に SSH 接続が切れると、SIGHUP でプロセスが止まる。

対処の選択肢

詳細は以下で。

& の基本

使い方

./long_task.sh &

コマンドの末尾に & を付けると、シェルがすぐにプロンプトを返してプロセスを背景で実行。

$ ./long_task.sh &
[1] 12345
$

意味:

• [1]: ジョブ番号
• 12345: PID（プロセスID）

バックグラウンド = SIGHUP に強い、ではない

./long_task.sh &
# ターミナルを閉じる
# → SIGHUP でプロセス終了

& だけでは SSH 切断時にプロセスが止まる。これは多くの開発者が誤解するポイント。

標準出力との関係

./long_task.sh &
# プロンプトは返るが、stdout は引き続きターミナルに出力される
# 作業中に混乱する

→ リダイレクトと組み合わせる:

./long_task.sh > output.log 2>&1 &

• > output.log: stdout を output.log に
• 2>&1: stderr を stdout と同じ場所（つまりoutput.log）に

複数コマンドを連結

# 順次実行
(cmd1; cmd2; cmd3) &

# 並列実行
cmd1 &
cmd2 &
cmd3 &
wait   # 全部終わるまで待機

& の使いどころ

• ターミナルが開いている間だけバックグラウンド実行したい
• 一時的な並列処理
• 後で disown するつもり

SSH 切断耐性が必要なら nohup または disown を併用。

nohup の使い方

nohup とは

nohup（”no hang up”）は SIGHUP を無視してコマンドを実行するユーティリティ。GNU Coreutils の一部。

基本

nohup ./long_task.sh

出力:

nohup: ignoring input and appending output to 'nohup.out'

意味:

• 入力（stdin）は無視
• 出力（stdout, stderr）は nohup.out に追記

⚠️ & を付けないとフォアグラウンドで実行され、ターミナルが占有される。

推奨パターン

nohup ./long_task.sh > task.log 2>&1 &

これで:

• バックグラウンドで実行
• SIGHUP に強い
• 出力は task.log へ

nohup.out

リダイレクト指定がない場合、出力はカレントディレクトリの nohup.out に書き込まれます:

nohup ./task.sh &
# → ./nohup.out が作られる

# ホームディレクトリの nohup.out になることも（書き込み権限により）
nohup ./task.sh &
# → ~/nohup.out

PIDの取得

nohup ./task.sh > task.log 2>&1 &
echo $!   # 直前のバックグラウンドプロセスのPID
# 12345

# PIDをファイルに保存
nohup ./task.sh > task.log 2>&1 &
echo $! > task.pid

実行中の確認

# PID で確認
ps -p $(cat task.pid)

# 生存確認
kill -0 $(cat task.pid) && echo "Running" || echo "Not running"

# ログ追跡
tail -f task.log

nohup の使いどころ

• 長時間バッチ処理: バックアップ、データ移行
• SSH 経由のデプロイ: 切断耐性が必要
• 新しくコマンドを起動: 後述の disown は既存プロセス用

disown の使い方

disown とは

disown はシェルのビルトインコマンドで、実行中のジョブをシェルのジョブテーブルから削除します。削除されたジョブは SIGHUP を受け取らなくなります。

基本

# まずバックグラウンドで起動
./long_task.sh &
[1] 12345

# シェルから切り離し
disown

または特定のジョブを指定:

disown %1    # ジョブ番号1を切り離し

既に動いているプロセスを切り離す

これが disown の真価:

# フォアグラウンドで起動してしまった
./long_task.sh
# Ctrl+Z で一時停止
^Z
[1]+ Stopped  ./long_task.sh

# バックグラウンドで再開
bg %1
[1]+ ./long_task.sh &

# 切り離し
disown %1

「nohup を付け忘れた！」という時の救済策。

-h オプション

disown -h %1

-h でジョブテーブルからは削除せず、SIGHUP のみ無視するようマーク:

./long_task.sh &
disown -h %1
jobs
# [1]+ Running  ./long_task.sh &  ← まだ表示される

通常の disown（オプションなし）はジョブテーブルから削除するため jobs でも表示されなくなります。

-a / -r オプション

disown -a   # 全ジョブを切り離し
disown -r   # 実行中のジョブのみ切り離し

disown の落とし穴

./long_task.sh &
disown %1

# ターミナルを閉じる → プロセスは生きる（SIGHUP 受けない）
# しかし stdout が消えるので、出力は失われる

⚠️ disown する場合も出力リダイレクト推奨:

./long_task.sh > task.log 2>&1 &
disown %1

nohup vs disown

両方使うこともあります:

nohup ./task.sh > task.log 2>&1 &
disown %1   # 念のため

ジョブ管理コマンド

jobs

jobs

現在のシェルセッションのジョブ一覧:

[1]+ Running    ./task1.sh &
[2]- Stopped    ./task2.sh
[3]  Running    ./task3.sh &

fg（foreground）

バックグラウンドジョブをフォアグラウンドへ:

fg          # カレントジョブ（+）を前面に
fg %1       # ジョブ1を前面に
fg %task1   # 名前指定

bg（background）

停止中のジョブをバックグラウンドで再開:

bg          # カレントジョブを背景で
bg %1       # ジョブ1を背景で

Ctrl+Z（サスペンド）

実行中のフォアグラウンドジョブを一時停止:

./long_task.sh
# Ctrl+Z
^Z
[1]+ Stopped    ./long_task.sh

その後 bg でバックグラウンド再開、または fg で再びフォアグラウンド。

Ctrl+C（中断）

実行中のフォアグラウンドプロセスに SIGINT 送信（中断）。

kill（ジョブ単位）

kill %1     # ジョブ1を終了
kill -9 %1  # 強制終了

通常は次の項目のように PID で操作する方が確実。

プロセス確認

ps（process status）

# 全プロセス
ps aux
ps -ef

# 特定プロセス
ps -ef | grep "task.sh"

# 自分のプロセス
ps -u $USER

# プロセスツリー
ps -ejH
ps axjf

ps aux の主な列:

• USER: 実行ユーザー
• PID: プロセスID
• %CPU: CPU使用率
• %MEM: メモリ使用率
• VSZ: 仮想メモリサイズ
• RSS: 実メモリサイズ
• STAT: 状態（R=実行中、S=スリープ、Z=ゾンビ）
• TIME: CPU時間
• COMMAND: コマンド

pgrep

# プロセス名で検索
pgrep nginx
# 12345
# 12346

# パターンマッチ（完全コマンドラインも検索）
pgrep -f "long_task"

# ユーザー指定
pgrep -u alice

pstree

pstree -p
# プロセスのツリー表示

top / htop

top      # リアルタイムプロセス監視
htop     # 高機能版（要インストール）

詳細はLinux find オプション一覧の記事、Linux grep オプション一覧の記事も参照。

プロセス終了

kill

kill <PID>          # SIGTERM（緩やかな終了）
kill -9 <PID>       # SIGKILL（強制終了）
kill -15 <PID>      # SIGTERM 明示
kill -1 <PID>       # SIGHUP
kill -s SIGUSR1 <PID>  # ユーザー定義シグナル

主要シグナル一覧

killall

killall nginx       # 名前で全部終了
killall -9 nginx    # 強制終了

pkill

pkill nginx                # nginx 全部終了
pkill -f "long_task"      # コマンドラインパターン
pkill -u alice            # ユーザー指定
pkill -9 -f "long_task"   # 強制終了

pkill は コマンドライン全体を検索できるため柔軟。

推奨：段階的終了

# 1. 緩やかに終了要求
kill <PID>

# 2. 数秒待っても止まらないなら強制
sleep 5
kill -9 <PID>

突然 -9 ではなく、まず SIGTERM で graceful shutdown を試みる。

出力リダイレクト完全ガイド

基本

cmd > output.log         # stdout を file へ（上書き）
cmd >> output.log        # stdout を file へ（追記）
cmd 2> error.log         # stderr を file へ
cmd > output.log 2>&1    # stdout + stderr を同じ file へ
cmd &> output.log        # 同上（bash の省略形）
cmd 2>&1 | tee output.log # ターミナルにも表示しつつ file へ
cmd > /dev/null          # 捨てる
cmd > /dev/null 2>&1     # stderr も捨てる

バックグラウンドでの組み合わせ

# 標準パターン
./task.sh > task.log 2>&1 &

# 追記モード
./task.sh >> task.log 2>&1 &

# stdoutとstderrを別ファイルに
./task.sh > task.out 2> task.err &

# 出力を完全に捨てる
./task.sh > /dev/null 2>&1 &

日付付きログ

nohup ./task.sh > "task_$(date +%Y%m%d_%H%M%S).log" 2>&1 &
# task_20260620_143000.log のような名前

ローテーション

# 既存のログをローテーション
[ -f task.log ] && mv task.log task.log.$(date +%Y%m%d)
nohup ./task.sh > task.log 2>&1 &

詳細はcrontab 書き方 例の記事も参照。

SSH 切断耐性のパターン

パターン1：nohup（最もシンプル）

# SSH 接続
ssh user@server

# nohup でバックグラウンド起動
nohup ./long_task.sh > task.log 2>&1 &

# SSH 切断（exit / 接続切れ）
exit

# 再接続後、ログ確認
ssh user@server
tail -f task.log

パターン2：disown（起動後の救済）

# フォアグラウンドで起動してしまった
./long_task.sh
# Ctrl+Z
bg
disown -h %1

# SSH 切断後も継続

パターン3：screen（推奨度：高）

# screen インストール
sudo apt install screen

# screen セッション開始
screen -S mytask

# 中で作業
./long_task.sh

# デタッチ（screen から離れる）
# Ctrl+A → D

# SSH 切断
exit

# 再接続して復帰
ssh user@server
screen -r mytask

パターン4：tmux（モダンな代替）

# tmux インストール
sudo apt install tmux

# セッション開始
tmux new -s mytask

# 中で作業
./long_task.sh

# デタッチ
# Ctrl+B → D

# 再接続後
tmux attach -t mytask

パターン比較

長時間作業なら screen / tmux が圧倒的に便利。

screen / tmux の基本

screen の基本コマンド

# 新規セッション
screen -S session_name

# セッション一覧
screen -ls

# 既存セッションに接続
screen -r session_name

# 強制的に既存接続を奪う
screen -dr session_name

セッション内のショートカット:

• Ctrl+A → D: デタッチ
• Ctrl+A → C: 新しいウィンドウ
• Ctrl+A → N: 次のウィンドウ
• Ctrl+A → P: 前のウィンドウ
• Ctrl+A → ": ウィンドウ一覧

tmux の基本コマンド

# 新規セッション
tmux new -s session_name

# セッション一覧
tmux ls

# アタッチ
tmux attach -t session_name

# セッションを削除
tmux kill-session -t session_name

セッション内のショートカット（プレフィックス Ctrl+B）:

• Ctrl+B → D: デタッチ
• Ctrl+B → C: 新しいウィンドウ
• Ctrl+B → N: 次のウィンドウ
• Ctrl+B → P: 前のウィンドウ
• Ctrl+B → ": ペイン分割（水平）
• Ctrl+B → %: ペイン分割（垂直）

推奨：tmux

screen より新しく、機能豊富で設定が柔軟。多くの DevOps エンジニアが採用。

systemd でのサービス化

本格的に運用するなら systemd サービスとして登録するのが最も確実。

サービスファイルの作成

sudo nano /etc/systemd/system/myapp.service

[Unit]
Description=My Long Running Application
After=network.target

[Service]
Type=simple
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/run.sh
Restart=on-failure
RestartSec=10
StandardOutput=append:/var/log/myapp.log
StandardError=append:/var/log/myapp.error.log

[Install]
WantedBy=multi-user.target

サービスの登録・起動

# リロード
sudo systemctl daemon-reload

# 起動
sudo systemctl start myapp

# 自動起動を有効化
sudo systemctl enable myapp

# 状態確認
sudo systemctl status myapp

# 停止
sudo systemctl stop myapp

# 再起動
sudo systemctl restart myapp

# ログ確認
journalctl -u myapp -f

nohup/screen vs systemd

本格運用は systemd 推奨。

実践パターン

パターン1：バックアップ

nohup tar czf backup_$(date +%Y%m%d).tar.gz /data > backup.log 2>&1 &
echo $! > backup.pid

# 後で確認
ps -p $(cat backup.pid)
tail -f backup.log

パターン2：データベース移行

nohup bin/rails db:migrate RAILS_ENV=production > migrate.log 2>&1 &
echo $! > migrate.pid

# 進捗確認
tail -f migrate.log

詳細はrails db:migrate 使い方の記事も参照。

パターン3：rake task の長時間実行

nohup bin/rails reports:daily RAILS_ENV=production > reports.log 2>&1 &

詳細はrake task 作り方の記事も参照。

パターン4：ログ監視

nohup tail -f /var/log/syslog | grep ERROR > errors.log &
disown

詳細はLinux grep オプション一覧の記事も参照。

パターン5：定期実行（crontab との連携）

# crontab -e
0 3 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1

cron は別シェルで実行されるため、nohup は不要（cron 自身が SIGHUP を送らない）。

詳細はcrontab 書き方 例の記事も参照。

パターン6：並列処理

# 4並列でファイル処理
for file in *.txt; do
  process_file "$file" > "$file.log" 2>&1 &
done
wait   # 全部終わるまで待つ

パターン7：起動中のプロセスの引っ越し

# ローカルで起動した処理を切り離す
./long_task.sh
^Z
bg
disown -h
exit   # → プロセスは継続

パターン8：複数ステップの順次実行

nohup bash -c '
  ./step1.sh && \
  ./step2.sh && \
  ./step3.sh && \
  ./notify.sh
' > workflow.log 2>&1 &

トラブルシューティング

プロセスが終了してしまう

# ❌
./task.sh &
exit   # → プロセス止まる

# ✅
nohup ./task.sh > task.log 2>&1 &
exit   # → 継続

nohup.out が肥大化

# 出力を /dev/null に
nohup ./task.sh > /dev/null 2>&1 &

# または、ローテーション付き
nohup ./task.sh >> "task_$(date +%Y%m%d).log" 2>&1 &

PID が分からない

# 起動時に取得
nohup ./task.sh > task.log 2>&1 &
echo $!   # 直前のPID
echo $! > task.pid

# 後から検索
pgrep -f "task.sh"
ps -ef | grep "task.sh"

kill しても止まらない

# 段階的に
kill <PID>            # SIGTERM
sleep 5
kill -9 <PID>         # SIGKILL（強制）

ゾンビプロセス

STAT列に Z（zombie）が表示

親プロセスを再起動するか、システムを再起動。

too many processes

# プロセス数確認
ps -ef | wc -l

# ユーザー単位
ps -u $USER | wc -l

# 上限確認
ulimit -u

バックグラウンドで実行したい処理が出力されない

# Python 等でバッファリング問題
nohup python -u script.py > log.log 2>&1 &
#         ↑ unbuffered

stdbuf でも対応可能:

nohup stdbuf -oL ./task.sh > task.log 2>&1 &

SSH 切断で全プロセス停止

SSH host key verification failed の記事 等の SSH 設定問題と区別:

# 接続維持の設定
# ~/.ssh/config
ServerAliveInterval 60
ServerAliveCountMax 3

ただし長時間処理は 必ず nohup / screen / tmux を使用。

& vs nohup vs disown の決定的違い

早見表

推奨組み合わせ

よくある質問（FAQ）

Q1. nohup と & はどっちを使う？

両方併用が標準:

nohup ./task.sh > task.log 2>&1 &

& だけだと SIGHUP に弱い、nohup だけだとフォアグラウンドのまま。

Q2. nohup.out をディレクトリ指定

# リダイレクトで指定
nohup ./task.sh > /var/log/myapp/task.log 2>&1 &

# ディレクトリを事前作成
mkdir -p /var/log/myapp

Q3. 出力をリアルタイムで見たい

# 別ターミナルから
tail -f task.log

# screen を使う方が確実
screen -S task
./task.sh
# Ctrl+A → D でデタッチ

Q4. プロセスを再起動

# PIDで停止
kill $(cat task.pid)
sleep 2
nohup ./task.sh > task.log 2>&1 &
echo $! > task.pid

Q5. すべてのバックグラウンドジョブ確認

jobs       # 現在のシェルのジョブ
ps -ef     # 全プロセス
pgrep -u $USER -a   # 自分のプロセス

Q6. CPUを消費するプロセスを優先度下げる

# 起動時
nice -n 19 ./heavy_task.sh &

# 既に動いているプロセス
renice 19 <PID>

nice/renice で優先度を下げ、他処理に影響しないように。

Q7. メモリ使用量制限

# ulimit で
ulimit -v 1048576   # 仮想メモリ1GB制限
./task.sh

# cgroups でも制限可能（高度）

Q8. nohup を実行したのに stop する

考えられる原因:

• カレントディレクトリ問題（権限）
• nohup.out 書き込み失敗
• 別のシグナルで停止（OOM Killer等）

# システムログ確認
dmesg | tail
journalctl -xe

Q9. systemd と nohup どちらを使う？

Q10. プロセスがゾンビになった

ps aux | grep " Z "
# Z 状態 = ゾンビ

対処:

• 親プロセスを再起動
• システム再起動

Q11. 全てのバックグラウンドジョブを一括終了

# 自分のプロセス全部
pkill -u $USER

# 特定パターン
pkill -f "task.sh"

# 強制
pkill -9 -f "task.sh"

Q12. screen が無いサーバーで作業

# パッケージインストール
sudo apt install screen   # Ubuntu/Debian
sudo dnf install screen   # RHEL系

または tmux:

sudo apt install tmux

参考リンク・関連資料

公式

• GNU Coreutils nohup – nohup 公式
• Bash Reference Manual – Job Control – ジョブ制御
• systemd – systemd 公式

関連ツール

• tmux – tmux 公式
• GNU Screen – screen 公式
• supervisord – プロセス管理ツール

関連記事（本サイト）

• Linux find オプション一覧 – ファイル検索
• Linux grep オプション一覧 – 文字列検索
• Linux awk 使い方 – データ加工
• crontab 書き方 例 – 定期実行
• Linuxでファイル差分を確認する方法 – diff/colordiff/vimdiff
• SSH host key verification failed – SSH 接続
• Docker no space left on device – システム管理
• Address already in use – ポート競合
• Ubuntu パッケージ uninstall – パッケージ管理
• rake task 作り方 – Rails での長時間処理
• Solid Queue 使い方 – Rails のバックグラウンドジョブ
• rails db:migrate 使い方 – 長時間マイグレーション

まとめ

Linux でプロセスをバックグラウンド実行する方法、要点を再整理します。

3大ツールの使い分け

# 短時間・ターミナル開いている間
./task.sh &

# 長時間・SSH切断耐性必要（推奨）
nohup ./task.sh > task.log 2>&1 &

# 起動済みプロセスの救済
./task.sh
^Z
bg
disown -h

SIGHUP に強くなる選択肢

ジョブ管理コマンド

jobs        # ジョブ一覧
fg %1       # フォアグラウンド化
bg %1       # バックグラウンド再開
Ctrl+Z      # 一時停止
Ctrl+C      # 中断

プロセス確認・終了

ps aux                       # 全プロセス
pgrep -f "pattern"           # パターン検索
kill <PID>                   # SIGTERM
kill -9 <PID>                # SIGKILL
pkill -f "pattern"           # パターン一括終了

出力リダイレクト

> file       # stdout のみ
2> file      # stderr のみ
> file 2>&1  # 両方同じファイル
&> file      # bash の省略形
> /dev/null  # 捨てる

これらの知識は、Linux サーバー運用・デプロイ・バッチ処理・トラブルシューティングなど、あらゆる場面で活用できます。本記事をブックマークしておけば、長時間処理を安全かつ確実に実行できるようになります。

本記事は2026年6月時点の情報をもとに、GNU Coreutils 9.x、Bash 5.x、screen 4.x、tmux 3.x での動作確認・公式ドキュメントに基づき作成しています。ディストリビューションによって挙動が異なる場合があるため、最新の情報は各ツールの man ページ（man nohup、man bash、man screen、man tmux）もあわせてご確認ください。