ログイン中のユーザーへ通知してからサーバーを安全にシャットダウンする手順

まず結論 — コマンド一発で通知とシャットダウンを同時に行う

Linuxサーバーを停止する際、ログイン中のユーザーへブロードキャストメッセージを送りながらシャットダウンを予約するには、shutdown コマンドにメッセージを続けて渡すだけです。

# 5分後にシャットダウン＋メッセージをブロードキャスト
sudo shutdown -h +5 "5分後にメンテナンスのため停止します。作業中のデータを保存してください。"

実行すると、ログイン中のすべてのユーザー端末に次のようなメッセージが届きます。

Broadcast message from root@web01 (pts/0) (Mon Jul 14 10:00:00 2025):

5分後にメンテナンスのため停止します。作業中のデータを保存してください。

The system is going down for poweroff at Mon 2025-07-14 10:05:00 JST!

メッセージはシャットダウン予約と同時に一度届き、その後 systemd が独自のカウントダウン通知（残り70分・60分・45分・30分・15分・5分・1分のタイミング）を自動的にブロードキャストします。

ブロードキャストメッセージが届く仕組み

内部的には wall（write all）コマンドが使われています。wall は /dev/pts/* や /dev/tty* に対してメッセージを書き込む仕組みで、SSH ログイン中のユーザーの端末（pts）にも届きます。

ただし、ユーザーが mesg n で端末へのメッセージ受信を拒否している場合、一般ユーザーからの wall は届きません。shutdown が内部で呼び出す wall は root 権限で動作するため、mesg n の設定に関わらずほとんどの環境でメッセージが届きます。

実務でよく使うシャットダウンパターン

時刻の指定方法は「相対時間（分）」「絶対時刻（HH:MM）」「即時（now）」の3通りです。それぞれ実際の操作例を示します。

# 10分後にシャットダウン（メッセージあり）
sudo shutdown -h +10 "10分後にOS更新のため再起動します。"

# 特定の時刻にシャットダウン（翌朝3時）
sudo shutdown -h 03:00 "深夜メンテナンスのため03:00に停止します。"

# 即時シャットダウン（メッセージなし、緊急時）
sudo shutdown -h now

# 再起動（シャットダウンではなくリブート）
sudo shutdown -r +5 "5分後にカーネル更新のため再起動します。"

ある運用現場では、深夜バッチの完了後に自動的にシャットダウンするスクリプト内で shutdown -h +2 "バッチ完了。2分後に停止します。" を使い、直前まで作業していた担当者が意図せず接続したままになっているケースを防いでいます。

なお、systemd 環境では shutdown コマンドは内部的に systemctl と連携しています。sudo systemctl poweroff は即時シャットダウンに相当しますが、事前通知やカウントダウン機能がないため、ユーザーへの配慮が必要な場面では shutdown コマンドのほうが適しています。

予約したシャットダウンをキャンセルする

予約をキャンセルするには -c オプションを使います。キャンセル時にもメッセージを添えることができます。

# シャットダウン予約をキャンセル
sudo shutdown -c "シャットダウンをキャンセルしました。作業を再開してください。"

ログイン中のユーザーに次のようなブロードキャストが届きます。

Broadcast message from root@web01 (pts/0):

The system shutdown has been cancelled!

予約が入っているかどうかは shutdown --show で確認できます。スクリプトから確認する場合は終了コードを使うよりも、systemctl list-jobs | grep shutdown のほうがパース不要で確実です。

wall コマンドでシャットダウンと切り離してメッセージだけ送る

シャットダウンを伴わず、ログイン中ユーザーへ任意のタイミングでメッセージを届けたい場合は wall を単独で使います。

# 全ユーザーへメッセージをブロードキャスト
sudo wall "18:00からネットワーク工事のため一時的に接続が切断されます。"

# ファイルの内容をブロードキャスト（長文向け）
sudo wall < /etc/motd.d/maintenance.txt

wall は root 権限なしでも実行できますが、前述のとおり受信側の mesg 設定によってはブロックされます。運用上の重要通知は必ず sudo を付けて実行するのが安全です。

注意点と環境差

いくつか実務でハマりやすいポイントをまとめます。

SSH セッションが pts に紐づいていない場合
一部のコンテナ環境や非対話セッション（nohup、screen、tmux 内でデタッチ中のセッションなど）では、端末が割り当てられていないため wall メッセージが届きません。こうした環境では Slack や監視ツールへの通知を別途組み合わせることを検討してください。

メッセージに特殊文字を含む場合
シングルクォートを含むメッセージはシェルのクォーティングに注意が必要です。ダブルクォートで全体を囲んだうえで、内部のダブルクォートをバックスラッシュでエスケープするか、ヒアドキュメントを使ってください。

# ヒアドキュメントを使う例（特殊文字が含まれる場合に安全）
sudo wall <<'EOF'
22:00からDBメンテナンスを行います。
ファイルの保存・ログアウトをお願いします。
EOF

systemd の依存関係でサービスが正しく停止されるか確認する
shutdown 実行前にクリティカルなサービスが安全に停止されるかどうかは、systemctl list-dependencies --reverse <unit> で事前に依存関係を確認しておくと安心です。特にデータベースや NFSマウントを抱えているサーバーでは、サービスの停止順序が問題になることがあります。

RHEL 系と Debian 系でのコマンドパスの違い
現代のほとんどのディストリビューションでは /usr/sbin/shutdown が systemd-shutdown ラッパーへのシンボリックリンクになっており、動作は統一されています。古い SysVinit ベースの環境と混在している場合は ls -la $(which shutdown) でリンク先を確認してください。