Debian 13 で稼働している端末を再起動しようとしたところ、shutdown -r now が Action suspend already in progress で拒否されました。
原因は再起動自体ではなく、約 1 時間前に開始された systemd-suspend.service が activating (start) のまま終了せず、systemd がサスペンド処理中と認識し続けていたことでした。
この場合は強制再起動を先に試すのではなく、残っているサスペンドのサービス、ジョブ、systemd-sleep の順に状態を確認します。今回の実機では、残存した systemd-sleep を終了した後、systemctl list-jobs が No jobs running. になりました。
発生した環境
本事象が発生したのは、iMac Retina 5K (2015) を Debian 13 に移行して運用している環境です[1]。
- iMac Retina 5K (2015)
- Debian 13
- GNOME
- Wayland
- systemd
systemd の実バージョンは次のコマンドで確認できます。
systemctl --version
以下では、実際に取得した サービス状態、ジョブ、PID をそのまま掲載します。ジョブ ID と PID は実行ごとに変わるため、手順では固定値として扱いません。
再起動が Action suspend already in progress で拒否された
通常どおり再起動しようとしました。
sudo shutdown -r now
しかし、次のエラーで拒否されました。
Call to Reboot failed: Action suspend already in progress, refusing requested reboot operation.
メッセージ上は再起動の失敗ですが、理由として明示されているのは suspend already in progress です。そこで再起動側ではなく、先行しているサスペンドの状態を確認しました。
systemd-suspend.service が約 1 時間 activating のまま残っていた
まず systemd-suspend.service を確認しました。
systemctl status systemd-suspend.service
実際の状態は次のとおりでした。
● systemd-suspend.service - System Suspend
Loaded: loaded (/usr/lib/systemd/system/systemd-suspend.service; static)
Active: activating (start) since Tue 2026-08-11 18:17:53 JST; 58min ago
Invocation: ff9db871af184b28bbbc547c154fda09
Docs: man:systemd-suspend.service(8)
Main PID: 7284 (systemd-sleep)
Tasks: 1 (limit: 38061)
Memory: 1.3M (peak: 2.7M)
CPU: 32ms
CGroup: /system.slice/systemd-suspend.service
└─7284 /usr/lib/systemd/systemd-sleep suspend
8月 11 18:17:53 orion systemd[1]: Starting systemd-suspend.service - System Suspend...
8月 11 18:17:53 orion systemd-sleep[7284]: Successfully froze unit 'user.slice'.
8月 11 18:17:53 orion systemd-sleep[7284]: Performing sleep operation 'suspend'...
systemd-suspend.service は suspend.target から起動され、実際のシステムサスペンドを実行するサービスです。また、既定では処理中に user.slice を freeze します[2]。
今回のログは Successfully froze unit 'user.slice'.、Performing sleep operation 'suspend'... まで進んだ後、約 1 時間 activating (start) のまま残っていました。通常の短時間の状態遷移ではなく、サスペンド処理が完了していないと判断しました。
systemctl list-jobs で残っているジョブを確認した
サービス単体だけでなく、systemd が保持しているジョブも確認しました。
systemctl list-jobs
結果は次のとおりでした。
JOB UNIT TYPE STATE
4525 systemd-suspend.service start running
4524 suspend.target start waiting
4529 grub-common.service start waiting
3 jobs listed.
systemctl list-jobs は進行中のジョブを表示します[3]。
今回のサスペンドに直接関係しているのは、次の 2 件です。
4525 systemd-suspend.service start running
4524 suspend.target start waiting
systemd-suspend.service の start が実行中で、その完了を待つ suspend.target の start も残っていました。
systemctl stop では止められなかった
通常のサービス停止を試しました。
sudo systemctl stop systemd-suspend.service
しかし、次のエラーになりました。
Failed to stop systemd-suspend.service: Transaction for systemd-suspend.service/stop is destructive (suspend.target has 'start' job queued, but 'stop' is included in transaction).
See system logs and 'systemctl status systemd-suspend.service' for details.
systemd-suspend.service を stop しようとしている一方で、suspend.target には start ジョブが残っています。systemd はジョブ間の依存関係をトランザクションとして扱うため、競合する操作がそのまま通るとは限りません[3]。
この時点では、単純な systemctl stop だけでは復旧できませんでした。
今後サスペンドさせないために sleep 系 target を mask した
この端末ではサスペンドとハイバネーションを使用しないため、sleep 系 target を mask しました。
sudo systemctl mask \
sleep.target \
suspend.target \
hibernate.target \
hybrid-sleep.target \
suspend-then-hibernate.target
systemctl mask は対象ユニットを /dev/null にリンクし、手動起動を含むすべての起動を禁止します。disable より強い無効化です[3]。
suspend.target、hibernate.target、hybrid-sleep.target、suspend-then-hibernate.target は systemd の sleep 処理に使われる特別な target ユニットで、これらは sleep.target と関係しています[4]。
確認には次を使います。
systemctl is-enabled \
sleep.target \
suspend.target \
hibernate.target \
hybrid-sleep.target \
suspend-then-hibernate.target
すべて masked になっていることを確認します。
ここで注意が必要なのは、mask は今後の起動を防ぐ操作であり、すでに実行中の systemd-sleep を終了する操作ではないことです。今回も mask 後に systemd-suspend.service は activating のまま残っていました。
ジョブの cancel だけでは解消しなかった
残っていたジョブ ID を指定して cancel も試しました。
sudo systemctl cancel 4524 4525
結果は次のとおりでした。
Failed to cancel job 4524, ignoring: Job 4524 does not exist.
systemctl cancel は数値のジョブ ID を指定して保留中のジョブを取り消すコマンドです[3]。
この時点では 4524 はすでに存在しませんでした。一方、systemd-suspend.service は引き続き activating のままでした。
ジョブ ID は一時的な値なので、記事中の 4524 や 4525 をそのまま別環境で指定するのではなく、その時点の systemctl list-jobs の結果を確認します。
systemd-sleep のプロセス状態を確認した
次に、systemd-suspend.service の Main PID として表示されていた PID 7284 を確認しました。
ps -o pid,ppid,stat,wchan:32,cmd -p 7284
結果は次のとおりでした。
PID PPID STAT WCHAN CMD
7284 1 Ss - /usr/lib/systemd/systemd-sleep suspend
ps の STAT では、S は割り込み可能な sleep、D は割り込み不能な sleep、追加文字の s は session leader を表します[5]。
今回は Ss であり、少なくとも D 状態ではありませんでした。この確認後、残っている systemd-sleep をユニット単位で終了しました。
systemd-suspend.service を終了してジョブを解消した
systemd-suspend.service に SIGKILL を送りました。
sudo systemctl kill --signal=KILL systemd-suspend.service
続いてユニットの failed 状態をリセットしました。
sudo systemctl reset-failed systemd-suspend.service
systemctl reset-failed はユニットに記録された failed 状態と関連する状態をリセットするコマンドです[3]。
最後にジョブを再確認しました。
systemctl list-jobs
結果は次のとおりです。
No jobs running.
これで、少なくとも Action suspend already in progress の原因になっていた残存したサスペンドジョブは解消しました。
SIGKILL は通常の停止処理を経由しません。実際にサスペンドへ遷移している最中の環境で無条件に実行するのではなく、端末が起動状態にあり、対話操作できること、systemd-suspend.service が長時間終了していないこと、systemd-sleep の状態を確認した上で、異常処理を除去する手段として扱います。
通常の再起動を再試行する
サスペンドに関係するジョブがなくなった後は、通常の再起動を再試行します。
sudo shutdown -r now
この段階では reboot -f や二重の --force を先に使う必要はありません。今回の障害では再起動自体が壊れていたのではなく、先行するサスペンド処理が残っていたため、まずその状態を解消するのが先です。
サスペンドをポリシーとして無効化する方法もある
今回実施した恒久対策は sleep 系 target の mask です。
systemd には別の設定として、/etc/systemd/sleep.conf または /etc/systemd/sleep.conf.d/*.conf の [Sleep] セクションで、各省電力モードを明示的に無効化する仕組みもあります[6]。
たとえば、次の設定です。
[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowHybridSleep=no
AllowSuspendThenHibernate=no
これは今回の復旧操作そのものではなく、「この端末ではサスペンドやハイバネーションを許可しない」というポリシーを設定する方法です。
既存の記事では、Debian 10 や Ubuntu 18.04 で logind.conf や GDM の設定を変更し、蓋閉じや自動サスペンドを事前に防ぐ方法を扱っています[7]。今回扱っているのは、それとは異なり、すでに開始されたサスペンド処理が途中で残り、再起動まで拒否された状態からの復旧です。
サスペンドが始まった原因は journal で別に調べる
今回確認できたのは、「サスペンド処理が完了せず残っていた」という状態です。何が最初にサスペンドを要求したのかまでは、このエラーメッセージだけでは分かりません。
障害対応中で、まだ再起動していない場合は 現在の起動の journal を時刻で絞ります。
sudo journalctl -b \
--since "2026-08-11 18:17:00" \
--until "2026-08-11 18:18:10"
journalctl -b は現在の起動、-b -1 は 1 つ前の起動を参照します。また、--since と --until で対象時刻を限定できます[8]。
今回、再起動前に次を実行したところ、対象を 1 つ前の起動 にしてしまったため何も表示されませんでした。
sudo journalctl -b -1 \
--since "2026-08-11 18:17:00" \
--until "2026-08-11 18:18:10"
-- No entries --
再起動前に今回の事象を見るなら -b が正しく、再起動後に直前の起動 を調べるなら -b -1 が対象になります。
「何がサスペンドを要求したか」と「なぜサスペンドが完了しなかったか」は別の問題です。前者を特定する場合は、サスペンド開始時刻の journal を追加で追います。
まとめ
今回の因果関係は次のとおりです。
- 何らかの契機でサスペンドが開始された。
-
systemd-suspend.serviceがsystemd-sleep suspendを実行した。 -
user.sliceを freeze した後、サスペンド処理が完了しなかった。 -
systemd-suspend.serviceが約 1 時間activating (start)のまま残った。 - systemd はサスペンド処理中と認識し続け、
shutdown -r nowによる再起動を拒否した。 -
systemctl list-jobsとpsで残存状態を確認した。 -
systemd-suspend.serviceのsystemd-sleepを終了した。 -
systemctl list-jobsがNo jobs running.になり、残存したサスペンドジョブ が解消した。 - 今後サスペンドさせないため、sleep 系 target を mask した。
Action suspend already in progress が出た場合、最初に見るべきなのは再起動のコマンドではなく、先行するサスペンドの状態です。systemd-suspend.service、systemctl list-jobs、systemd-sleep の順に確認すると、どこに処理が残っているかを切り分けられます。
参考文献
- id774, iMac Retina 5K (2015) を Debian 13 に移行した（2026-02-09）. https://blog.id774.net/entry/2026/02/09/3515/
- systemd, systemd-suspend.service(8) — System sleep state logic（2026-04-13）. https://manpages.debian.org/trixie/systemd/systemd-suspend.service.8.en.html
- systemd, systemctl(1) — Control the systemd system and service manager（2026-04-13）. https://manpages.debian.org/trixie/systemd/systemctl.1.en.html
- systemd, systemd.special(7) — Special systemd units（2026-04-13）. https://manpages.debian.org/trixie/systemd/systemd.special.7.en.html
- procps-ng, ps(1) — report a snapshot of the current processes（2025-07-30）. https://manpages.debian.org/trixie/procps/ps.1.en.html
- systemd, systemd-sleep.conf(5) — Suspend and hibernation configuration file（2026-04-13）. https://manpages.debian.org/trixie/systemd/systemd-sleep.conf.5.en.html
- id774, ノートパソコンのサスペンドを防止する（2020-02-03）. https://qiita.com/ynakayama/items/430355e392be9602a766
- systemd, journalctl(1) — Print log entries from the systemd journal（2026-04-13）. https://manpages.debian.org/trixie/systemd/journalctl.1.en.html