ZorinOSのサスペンド不具合/意外な伏兵(?)猫バンド

2026年6月25日

数日前からサスペンドが機能しなくなった

ZorinOSのPCを4月初旬から常用していて完全にLinuxユーザーになれたと思っているが、細かなトラブルが忘れた頃にあらわれるので AI サポーターは欠かせない。
少しでも不明なことがあれば当たり前のように使っていたGoogle検索と縁が切れたPC生活がこんなに早くくるなんて考えもしなかったが、今やチャットAI のない生活も考えられない。それはともかく･･･夜中でも画面が光っているPCがあるのは気に入らない。設定はカンタンだし、変更した記憶もないのだ。

本日も4時間以上放置していて、時折りメッセージは出るが｢自動｣のはずなのに電源は切れない。
ネット情報をいくら調べても分からないのでアタマを抱えていた。スリープで電源が切れないなんて初歩的なトラブルを抱えたままでは夜も眠れない･･･

PCトラブルで10分以上悩んだ･困った時は、迷う前にさっさとClaude探偵に調査依頼の習慣が身についている。
最近たまに役に立たないことだってあるが、今回は一発回答だった。この程度なら当たり前だけど(^。^)

原因はYoutubeでお気に入り猫バンドのエンドレスライブ演奏だった

｢何や、その程度のことか･･･｣となるところだが、どうしても自力解決出来なかった。
“灯台もと暗し”の見えないところでライブが続いていたのだ。Youtubeもライブ番組では止まらない仕様。
などと、もったいぶらずにさっさと根本原因を書いておこう。
思うところがあって、1週間ほどまえから常用とは別のユーザーを追加してログインを切り替えていた。
常用とは別のユーザーを作成してログインすると、ほぼOSインストール直後の状態にすべての環境がリセットされることを知ったのだ。
一つの環境で長く使っていて解決困難な細かなトラブルを抱えるようになってきていたのでこれは都合が良い。
｢ブログ管理専用の環境｣を作りたかったのだ。OSの基本機能を利用するだけなのでうまく運用できていた。
常時、複数ユーザーでログインする状態になったのだが、問題は｢ユーザー切り替え｣を多用していたこと。

眼の前で見ている画面からはまったく想像もしていなかった

Claudeはいつもどおり沈着冷静だった。
不具合解決ではGUIでなんていってられないので、ターミナル主体になるのは当然なので躊躇なく承諾。
以下、臨場感を共有してもらいたいので実際のやり取りをそのまま載せる。

systemd-inhibit --list

これを実行すると、サスペンドやシャットダウンをブロックしているプロセス一覧が表示されます。Braveブラウザや何かのアプリがリストに出てくれば、それが原因です。
もし何か気になる出力が出たら、貼ってもらえれば一緒に見ますね😊

実行するとこんな感じで延々と続く。

hikosama@hiko-7090:~$ systemd-inhibit --list
WHO                          UID  USER     PID    COMM            WHAT         >
ModemManager                 0    root     1042   ModemManager    sleep        >
NetworkManager               0    root     1025   NetworkManager  sleep        >
UPower                       0    root     1636   upowerd         sleep        >
Unattended Upgrades Shutdown 0    root     1272   unattended-upgr shutdown     >
GNOME Shell                  1000 hikosama 11117  gnome-shell     sleep        >
hikosama                     1000 hikosama 11266  gsd-power       handle-lid-sw>

ふむふむ、なるほど〜( ´･ω･`)これは結構重要な情報が出てきました。
注目ポイント
このリストを見ると、怪しいブラウザやアプリは見当たりません。ModemManager、NetworkManager、UPower、gnome-shellなど、すべて「正常なシステムプロセス」です。これらは普段から常に出てくるもので、サスペンドを妨害しているわけではなく、単に「サスペンド/シャットダウン時に通知を受け取る」ためにリストされているだけのものがほとんどです。
ただ、ここで気になるのがもう一人のユーザー「paradox」さんのセッションです。

paradox    1002  paradox  107997 gsd-media-keys  handle-power-> sleep
paradox    1002  paradox  108006 gsd-power       sleep
paradox    1002  paradox  107786 gnome-session-b sleep

これは、paradoxユーザーのセッションがバックグラウンドでまだ起動したままになっている可能性を示しています。マルチユーザー環境（hikosama／paradox）を組まれているとのことでしたが、もしparadoxさんが「ログアウトしたつもりで実は画面を切り替えただけ（高速ユーザー切り替え）」になっていると、そのセッションがアクティブなままサスペンドを妨害することがあります。
確認方法
ターミナルで以下を打ってみてください。

loginctl list-sessions

これで現在動いているセッションが全部出ます。paradoxのセッションが「Active」や「Online」になっていたら、それが今回の主犯の可能性が高いです。
もしparadoxのセッションがアクティブだったら、一度paradox側にログインしてちゃんとログアウトする（または再起動する）と直る可能性があります。

ちなみに「電源」設定画面（今回の画像）を見ると、サスペンドの時間設定そのものがメニュー上には見当たりませんね。ZorinOS（GNOME）はバージョンによって「画面のブランク」の時間＝そのままサスペンドに直結する設計になっていることもあるので、この画面に出ている「15分」がそのままサスペンドまでの時間として使われている可能性があります。
まずはloginctl list-sessionsの結果を見せてもらえますか？

— ログアウトしたつもりで実は画面を切り替えただけ
ピンポンです。まさにそれをやってる。発生したタイミングもおそらくぴったり。
別ユーザーがアクティブのままの可能性高いです。ならハナシは早い。

hikosama@hiko-7090:~$ loginctl list-sessions
SESSION UID USER SEAT TTY STATE IDLE SINCE
10 1000 hikosama seat0 tty3 active no -
209 1002 paradox seat0 tty2 online yes 23h ago
2 sessions listed.
hikosama@hiko-7090:~$

15:58Claudeが返答しました: ビンゴでした〜🎯やっぱりparadoxさんのセッションが裏で生き続けてましたね。23時間前からidle yesで待機しっぱなしというのが、まさに今回の発生タイミングと一致します。ビンゴでした〜🎯やっぱりparadoxさんのセッションが裏で生き続けてましたね。23時間前からidle yesで待機しっぱなしというのが、まさに今回の発生タイミングと一致します。
状態の説明
hikosama (tty3) → active = 今あなたが使っている画面
paradox (tty2) → online = ログイン状態のままバックグラウンドに残っている（GNOMEの「ユーザーの切り替え」でtty2に画面ロックされたまま放置されている状態）
GNOMEは「すべてのセッションがアイドルでないと本当のサスペンドに入らない」という保護的な仕様があるので、paradoxのセッションが残っている限りサスペンドが阻害される、というのは非常に納得感のある話です。

対処方法（2択）
① paradoxのセッションだけを終了する（ログアウトはせず強制終了）

loginctl terminate-session 209

これでセッション209（paradox側）だけを切ります。paradox側で作業中のものがあれば保存されていない可能性があるので、もし何か開いていたら先に保存を確認したほうが安全です。
② paradoxにいったん切り替えて、ちゃんとログアウトする
画面右上から「ユーザーを切り替え」→ paradoxの画面に入る → そこで「ログアウト」を選ぶ、という王道パターンです。作業中のファイルなどがある場合はこちらが安全です。
今回みたいに「セッションを残したまま切り替えた」ケースは今後も起こりがちなので、もし定期的に発生するなら、サスペンド前に簡単にチェックする習慣（loginctl list-sessionsを都度叩く）か、あるいはparadoxを使い終わったら必ずログアウトするルールにしておくと安心です。
どちらの方法で片付けますか？それとも今すぐterminate-session 209を試してみます？

間違いはないと思われるが、ユーザー切り替えてとりあえず確認はしてみる。

16:00Claudeが返答しました: 了解です👍その確認の仕方が一番安全ですね。paradox側で何か作業中のものが残っていないかも同時に見れるので、一石二鳥です。
確認できたら、結果を教えてください。paradox側で特に開いているものがなければ、そのままログアウトしてしまってOKです。もし何か中途半端な作業が残っていたら、保存してからログアウトする形で大丈夫です。

Paradox です。キャットバンドが絶賛ライブ中でしたわ。ヾ(o´∀｀o)

16:04Claudeが返答しました: あー、これは完全に確定犯ですね（笑）
24時間近く猫バンドのジャズライブを延々と流し続けていたわけですね。Jazz Meowlodyが律儀に演奏を続けている間、paradoxセッションも律儀に「起きてます」とOSに報告し続けていた、というオチでした。サスペンドが阻害されるのも当然の状況です。
YouTube（特にライブ配信）はブラウザのインヒビター機能で「再生中はサスペンドさせない」という制御をかけるのが普通なので、systemd-inhibit –listのparadoxセッション側に直接ブラウザの名前が出てこなかったのは少し意外でしたが、gsd-powerがセッション単位でブロックしていたなら筋は通ります。

– 中略 –

ちゃんとログアウトして戻ってきたよ。
何も考えずユーザー切り替えしてたので、いいクスリになりました。( ´･ω･`)

hikosama@hiko-7090:~$ loginctl list-sessions
SESSION UID USER SEAT TTY STATE IDLE SINCE
10 1000 hikosama seat0 tty3 active no -
1 sessions listed.
hikosama@hiko-7090:~$

16:11Claudeが返答しました: パーフェクトです🎉セッションが1つだけ（hikosamaのみ）になりましたね。これでparadoxの生き残りセッションは完全に消えました。パーフェクトです🎉セッションが1つだけ（hikosamaのみ）になりましたね。これでparadoxの生き残りセッションは完全に消えました。
これで数日来のサスペンド不調の原因は特定・解決完了です。まとめると、
ユーザー切り替えでparadoxに移動→ログアウトせず放置
paradoxセッションが「online（アイドルだけど存在している）」状態のままYouTubeライブを再生し続ける
GNOMEの仕様で「全セッションがアイドルにならないとサスペンドしない」ため、paradox側の存在自体（＋再生中の動画）がブロック要因になっていた
という流れですね。
今後は、ユーザー切り替えで一時的に他ユーザーに移ったときは「使い終わったらちゃんとログアウトする」を習慣にすれば再発しないはずです。マルチユーザー環境特有の落とし穴で、これは知らないと気づきにくいパターンでした。
このあと数時間くらい放置してみて、ちゃんとサスペンドに入るか確認してみてください。問題なければ今回の件は完全クリアです👍

Linuxのスタンバイ不具合についてたいがいネット情報を調べたけど一般的な設定方法の説明ばかりで、対処方法を見つけられなかった。やはり対話相談はありがたいな。
同一PCでマルチユーザーって特殊な利用方法でもないと思うのだが。
トラブル解決にターミナルコマンド前提とはいえ、役に立つコマンドを知れたので、これはいいTipsになるね。(^。^)

16:17Claudeが返答しました: 同感です(^。^)これは確かに「ググっても出てこない」タイプの不具合でしたね。検索すると大抵「画面のブランク時間の設定方法」みたいな基本設定の説明に行き着いてしまって、「セッションが残ってるとサスペンドがブロックされる」という挙動そのものはあまり言及されていない印象があります。GNOMEの公式ドキュメントにも明記され…同感です(^。^)これは確かに「ググっても出てこない」タイプの不具合でしたね。検索すると大抵「画面のブランク時間の設定方法」みたいな基本設定の説明に行き着いてしまって、「セッションが残ってるとサスペンドがブロックされる」という挙動そのものはあまり言及されていない印象があります。GNOMEの公式ドキュメントにも明記されていない、いわば実装上の仕様という感じなので、表に出にくいんでしょうね。

– 後略 –

ほとんどの読者にとって関心がないことは分かっているが、自分のためのトラブルシューターとして、意訳して書くよりも、チャットの単純コピペが資料として最高の教材になるな、書きながら気づいたのだ。
まぁこんな感じでサポーターと共同作業してる。今の自分は、Claudeは万能の人工知能でもなければ、万年若年性認知症のようなおそまつな記憶機能しかないなど、付き合うにもコツが必要なことも分かっている。
※この点だけでいえばChatGPTの方にかなり分があることは事実。ヤツもあまり信用はならないが関連チャットや過去のチャットも横断して対処してくれるのは助けられることも少なくない。
以上、編集後記のひとりごとでした。(^。^)

よかったらシェアしてね！