プロが教えるわが家の防犯対策術！

ubuntuのシャットダウンが進まず、途中で止まってしまう（シャットダウンできない）＿２

締切済

  • 質問者：ubuntutatatata
  • 質問日時：
  • 回答数：10件

Ubuntu 22.04.3 LTSを使いqiime2で腸内細菌研究をしています。
PCはまだまだ初学者です。申し訳ないのですが、その上でご返答いただけますと嬉しいです。

Ubuntuデスクトップの右上（GUI）の「電源オフ」を選択し電源を落としておりました。
しかし、今回同様に電源オフをしてもはじめは通常通りシャットダウン作業が進んでいるのですが
画面がブラックバックになりPCメーカーのロゴとその下にubuntuの文字が出る画面で止まってしまいます。
通常はPCメーカーのロゴとubuntu文字の間にくるくると円形のものが動いて（おそらく動作中のやつ）、すぐ画面が暗くなりPCの電源も落ちるのですが
今は、PCメーカーのロゴとubuntu文字の間にくるくると円形のものが動いてすぐその円形が消え、
そのままの画面でずーっと止まってしまいます。３０分以上放置でも何も変わりませんでした。（ファンなども動いたままです）
やむを得ず、本体の物理的にある電源ボタンで電源を落としています。
ちなみに再起動も同様の箇所でストップしてしまい、できません。
ターミナルの$shutdown -h nowでも同様の症状です。

そこで下記HPを参考に
https://forums.ubuntulinux.jp/viewtopic.php?pid= …

1. /etc/modules　に
apm power_off=1　を加えた。
→だめでした。
２． /etc/modules　に
lp
acpi=off apm=power_off　を加えた。
→だめでした
３．/boot/grub/menu.lst
→ありませんでした。作成もしていません。

また、
・「shutdown -h now」でエラーメッセージはでず、シャットダウンへ移行します。（もちろん途中でフリーズしてしまいます。）
Ubuntuのソフトウェアとアップデートで「セキュリティーアップデートがあるとき」を「ダウンロードとインストールを自動的に行う」以外にはすでになっております。「プロンプトを出して止まってる。」状態ではないのかもしれません。

そしてこの問題が生じたきっかけですが
心当たりがございますのは
・システムの更新(apt upgradeなど)　を行いました。
しかし、その際docker関連でエラーを起こしているようなエラーメッセージが頻発し、dockerを始めたいと導入しましたがやむを得ず一旦諦めアンインストールいたしました。
「docker」と名のついているものを手当り次第削除したところ
apt upgrade　でエラーはなくなりました。
が、その後シャットダウンできなくなったように思います。
しかし「docker消したところで関係あるかな？docker導入前は正常に電源オフで来ていたわけだし」と考えておりました。
(ちなみにubuntuでdockerを導入に関してはhttps://kinsta.com/jp/blog/install-docker-ubuntu/を参考にいたしましたが、Docker Desktopが正常にインストールできませんでした。)

以上です。/var/log/dmesgの一部をスクショしたものを添付します。
(log文の提供に際し、内容が全くわからないため最適箇所を提示することができません。そのあたりもご指示いただけましたらありがたいです。）

「ubuntuのシャットダウンが進まず、途」の質問画像

質問者からの補足コメント

  • どう思う？

    ご回答ありがとうございます
    yesです
    インストールしたUSBメモリから起動やってみました。
    まず、BIOS設定からUSBを最優先にして　起動
    「Try or ~~Ubuntu」を選択したのですが、その後PCメーカーのロゴの画面でフリーズしました。（フリーズ画面はシャットダウンできず止まる画面と同じです）
    お時間ございましたら、再度ご指示おねがいいたします

    No.2の回答に寄せられた補足コメントです。 補足日時：2023/10/05 16:52
    通報する

  • ご回答ありがとうございます。また、前回もご回答していただき大変感謝しております。
    今回もアイディアをいただき大変嬉しく思っております。

    1.キーボード"Caps.Lock"でランプは変わりませんでした。"NumLock"はないタイプです
    2.Ctrl+F1, Ctrl+F2,Ctrl+Alt+Delete 変化ありません
    キーボードは生きてないと思います

    3.次回の電源ON でワーニングメッセージは全く出ておりません
    シャットダウンはほぼ完了し、電源offの操作（ファンは動いたままです）だけができていない状態かもしれません。

    5./var/log/kernl.log1を添付します。ご参考になればよいのですが。

    ご興味いただき感謝してもしきれません。お時間ございましたら返答をお願いいたします。

    「ubuntuのシャットダウンが進まず、途」の補足画像2
    No.1の回答に寄せられた補足コメントです。 補足日時：2023/10/05 17:00
    通報する

  • つらい・・・

    trka様
    いつもありがとうございます。
    "shutdown -r now"実行してみましたが、再起動できませんでした。
    いつもと同じ画面、同じタイミングでフリーズいたしました。

    また、画像イメージが見えない件もご指摘ありがとうございます。
    確認不足でございました。
    乏しい知識と経験の私にご指示いただき感謝いたします。

    No.4の回答に寄せられた補足コメントです。 補足日時：2023/10/06 10:42
    通報する

  • うーん・・・

    いつも親身になってご対応くださりありがとうございます。ご丁寧な対応に頭が下がるばかりです。

    2.ログ参照-2
    私のPCではCtrl + Alt + F3でCUIでした。　$sudo shutdown -h now で実行してもシャットダウンプロセスは全く変わらず、今までどおりフリーズ致してしまいました。
    "シングルユーザモード"ですが、方法など調べておりますがシングルユーザーモードでの起動に成功できておりません。

    1.ログ参照-1
    私のubuntuには　journalctl > /tmp/tmp1　がございませんでした。
    /var/log のシャットダウン後のもので、エラーっぽいなーと判断したものを以下に載せさせていただきます。（大した情報はないのかもしれませんが、、申し訳ありません）

    No.5の回答に寄せられた補足コメントです。 補足日時：2023/10/12 11:51
    通報する

  • へこむわー

    Oct 6 16:51:53 kyouken1 gnome-shell[1298]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.

      補足日時：2023/10/12 11:53
    通報する

  • へこむわー

    Oct 6 16:51:53 kyouken1 gnome-shell[1298]: The offending signal was destroy on Gjs_ui_appDisplay_AppIcon 0x55ef09f6d1c0
    Attempting to run a JS callback during garbage collection. This is most likely caused by destroying a Clutter actor or GTK widget with ::destroy signal connected, or using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked.

      補足日時：2023/10/12 11:54
    通報する

  • へこむわー

    Oct 6 16:51:53 kyouken1 nautilus[7882]: Error reading events from display: Broken pipe
    Oct 6 16:51:53 kyouken1 [1953]: Error reading events from display: Broken pipe

    ちなみにこれら文章を検索してみましたが、よくわかりませんでした。

      補足日時：2023/10/12 11:58
    通報する

  • どう思う？

    いつもありがとうございます。
    早速実施してみましたが、残念ながら、shutdown -h nowの後全く同じ挙動になりました。一瞬でいつものフリーズです。

    関係ないかな、とも思うのですがお伝えさせていただきます。
    CUIでのブート中以下のようなメッセージが出てました

    AER: Corrected error received: id=00e7
    PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
    device [10de:2504] error status/mask=00001000/00002000
    [0] RxErr

    結局無視し、エンター押して、shutdown -h now...と手順に進んだのですが。
    ご検討の一考になれば幸いです。お暇でしたらお力を貸していただきたく存じます

    No.8の回答に寄せられた補足コメントです。 補足日時：2023/10/12 17:09
    通報する
通報する

この質問への回答は締め切られました。

質問の本文を隠す

A 回答 (10件)

参考程度に

No.10

  • 回答者： trka
  • 回答日時：

No8です。

補足を有難うございました。
今回テストしていただいた件について2点ほど質問させていただきます。

1.AER: Corrected error received: メッセージ
GUIを起動させないように設定した所為ではないかと思われるのですが、設定を元に戻しても表示されるのでしょうか。

2.CUI画面からのshutdown...
「...一瞬でいつものフリーズ...」とお書きになっていますが、添付の画像のようにシャットダウンメッセージが現れないのでしょうか。つまり、shutdown -h nowコマンドを実行後、何も表示されずにフリーズしてしまうのでしょうか。
「ubuntuのシャットダウンが進まず、途」の回答画像10
    • good
    • 0
    • 件
通報する

参考程度に

No.9

  • 回答者： trka
  • 回答日時：

ごめんなさい。


先の回答、最初のsystemctlコマンドは...

sudo systemctl set-default

ではなくて...

sudo systemctl get-default

でした。訂正致します。
    • good
    • 0
    • 件
通報する

参考程度に

No.8

  • 回答者： trka
  • 回答日時：

補足説明をありがとうございます。


問題はご提示のメッセージがパソコンのフリーズに結びついているのかどうか、今ひとつはっきりしません。
但し、関係があるのだと仮定すれば、"gnome"はご使用中のデスクトップソフトウエアですし、"nautilus"はgnomeデスクトップで使用するファイルマネージャです。
つまり「GUI環境を終了できなくなっている。」ことがフリーズに結びついているのかも知れません。
そこで少し調べてみたのですが...

https://tek2tech.com/ubuntu-2004-desktop-environ …

上記ブログでは最初からGUI環境を起動させない方法が説明されています。前回の回答で「シングルユーザモードで...」などとご説明しましたが、こちらの方法のほうが確実ではないかと思われます。
また上記ブログはubuntu向けの説明ですが、私の環境(Debian)でも同じコマンドを使用できましたので、確実にご質問者様の環境で利用できると思います。

sudo systemctl set-default

私の環境でも確かに"graphical.target"と表示されました。
そこで...

sudo systemctl set-default multi-user

を実行後"shutdown -h now"でシャットダウン、電源off-onを行います。
ブート後の画面はCUI画面に代わるはずですが、ログイン後そのまま"shutdown -h now"を実行、シャットダウンができるか、できなければフリーズ直前のメッセージに気づく点はないか、などを確認すれば良いと思います。

確認作業終了後は...

sudo systemctl set-default graphical

を実行すれば元に戻ります。
この回答への補足あり
    • good
    • 0
    • 件
通報する

No.7

  • 回答者： davidfox
  • 回答日時：

No.2です。


補足ありがとうございます。
USBメモリから起動するが、お試し Ubuntu を起動出来ないんですね…

ん〜　PCに依っては、USB等外部メディアからの起動（インストール）を抑止する物も有るようなので、それが阻害している風にも思えます。
　BIOSのセキュリティ関係の項目で Off に出来るかも知れませんが…（私は詳しくなく orz）
    • good
    • 0
    • 件
通報する
この回答へのお礼

ご丁寧に返答いただきありがとうございます。
多様なアイディアをいただけて感謝しております。
この度はありがとうございました。

通報する
お礼日時：2023/10/12 10:06

No.6

  • 回答者： tacjiji
  • 回答日時：

NO.3です。



＞ただ、手間を考えると極力避けたいので引き続き他にアイディアがございましたらご回答いただけますと幸いです。

修復出来るぁどうかも分からないシステムを修復に膨大な時間を掛けるぐらいなら、インストールし直す方が如何に簡単かという結論に至ります。
    • good
    • 0
    • 件
通報する
この回答へのお礼

ご返答ありがとうございます。
おっしゃる通りかもしれません。
ただ、初学者なもので再度同じ環境をスムーズに構築できる自身がなくウジウジしております。（anaconda,qiime2,R,などなど）
一案いただきありがとうございました。

通報する
お礼日時：2023/10/12 11:06

参考程度に

No.5

  • 回答者： trka
  • 回答日時：

No1です。


うーん。そうするとやっぱりログを見ないと何処で止まっているのか確認できないのでしょうか。幾つか方法がありそうに思うのですが、私自身はUbuntuを使っておらず、Debianですので何処まで同一の手順が有効になるか判りません。但し、ご参考にはなると思いますので、また説明が長くなりますがご容赦ください。

1.ログ参照-1
私が使用するDebianでは既に/var/logの中身が簡略化されており、ログファイルを直接参照してもたいした情報は得られません。
代わりにroot権限でコマンド...

# journalctl > /tmp/tmp1; vi /tmp/tmp1

で開かれるファイルに対し、キーワード"Linux version"で検索をかけると電源offから次回ブートの状態を沢山参照することができます。
　　　　　|　　　　　　|　　　　　　|　　　　　|
　　　　　|　　　　　　|　　　　　　|　　　　　|
　　　　　|　　　　　　|　　　　　　|　　　　　|
1 8月 21 18:56:53 Bookworm systemd[1]: Unmounted run-credentials-systemd\x...
2 8月 21 18:56:53 Bookworm systemd[1]: Stopped target local-fs-pre.target - Pre...
3 8月 21 18:56:53 Bookworm systemd[1]: Reached target umount.target - Unmount All Filesystems.
4 8月 21 18:56:53 Bookworm systemd[1]: systemd-tmpfiles-setup-dev.service: Deactivated successfully.
5 8月 21 18:56:53 Bookworm systemd[1]: Stopped systemd-tmpfiles-setup-dev.service - Create St....
6 8月 21 18:56:53 Bookworm systemd[1]: systemd-sysusers.service: Deactivated successfully.
7 8月 21 18:56:53 Bookworm systemd[1]: Stopped systemd-sysusers.service - Create System Users.
8 8月 21 18:56:53 Bookworm systemd[1]: systemd-remount-fs.service: Deactivated successfully.
9 8月 21 18:56:53 Bookworm systemd[1]: Stopped systemd-remount-fs.service - Remount Root and Kernel File Systems .
10 8月 21 18:56:53 Bookworm systemd[1]: Reached target shutdown.target - System Shutdown.
11 8月 21 18:56:53 Bookworm systemd[1]: Reached target final.target - Late Shutdown Services.
12 8月 21 18:56:53 Bookworm systemd[1]: systemd-poweroff.service: Deactivated successfully.
13 8月 21 18:56:53 Bookworm systemd[1]: Finished systemd-poweroff.service - System Power Off.
14 8月 21 18:56:53 Bookworm systemd[1]: Reached target poweroff.target - System Power O 15 8月 21 18:56:53 Bookworm systemd[1]: Shutting down.
16 8月 21 18:56:53 Bookworm systemd-shutdown[1]: Syncing filesystems and block devices.
17 8月 21 18:56:53 Bookworm systemd-shutdown[1]: Sending SIGTERM to remaining processes...
18 8月 21 18:56:53 Bookworm systemd-journald[290]: Received SIGTERM from PID 1 (systemd-shutdow).
19 8月 21 18:56:53 Bookworm systemd-journald[290]: Journal stopped
20 -- Boot 4c6e12a1b480485a9c97902e5f57e8dd --
21 8月 22 08:13:44 Bookworm kernel: Linux version 6.1.0-11-amd64 (debian-kernel@lists.deb...
22 8月 22 08:13:44 Bookworm kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-11-amd64 r...
23 8月 22 08:13:44 Bookworm kernel: BIOS-provided physical RAM map:
24 8月 22 08:13:44 Bookworm kernel: BIOS-e820: [mem 0x00000000000000-0x000000000009fbff] usable
25 8月 22 08:13:44 Bookworm kernel: BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
26 8月 22 08:13:44 Bookworm kernel: BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
27 8月 22 08:13:44 Bookworm kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000dffeffff] usable
28 8月 22 08:13:44 Bookworm kernel: BIOS-e820: [mem 0x00000000dfff0000-0x00000000dfffffff] ACPI data
　　　　　|　　　　　　|　　　　　　|　　　　　|
　　　　　|　　　　　　|　　　　　　|　　　　　|
　　　　　|　　　　　　|　　　　　　|　　　　　|
3行目でUnmount All Filesystemsが実行されています。
9行目でStopped.....Remount Root and...と言ってますが、Remount Root機能をkillした、ということだと思います。
16行目ではファイルシステムの整合性を取り、アンマウントが完了したことを意味しているのだと思います。
その後は起動中のプロセス全部にkillを送り、最後に自分自身をkillしてJournal stoppedとなります。
左側の日時を見れば、この時点でパソコン電源もoffしています。
20行目以降は新たに電源投入、ブートを開始しています。

もしご質問者様の環境でも同様のログを参照できれば、シャットダウンプロセスの何処かで停止、できれば同時にエラーが発生してるかも知れません。

2.ログ参照-2
ファイルシステムのアンマウント後にフリーズしているのですから、もしかしたら肝心の部分はログに残らないかも知れないと思います。その場合GUI画面でなくCUI画面上で"shutdown -h now"を実行することでシャットダウンプロセスが直にモニター上に表示されるのを見ることができるかも知れません。

●パソコンのブートを完了した時点で(GUI画面)、昨日のCtrl+F1, Ctrl+F2,...キー及びCtrl+F7を試してください。CUI画面とGUI画面が交互に表示されると思います。
これのCUI画面でログインした後、root権限で"shutdown -h now"を実行したら、シャットダウンプロセスが直に表示されないでしょうか。そしてフリーズした段階の最後のプロセスはどの様になっているでしょうか。

●上のCUI画面でうまくいかなければ、さらに"シングルユーザモード"で起動することができます。その手順は、Ubuntuでは少しややこしい様ですが、参考になるurlを下に示します。

https://gihyo.jp/admin/serial/01/ubuntu-recipe/0 …

この状態で"shutdown -h now"を実行する時、シャットダウンプロセスを直に参照することができないでしょうか。
この回答への補足あり
    • good
    • 0
    • 件
通報する

参考程度に

No.4

  • 回答者： trka
  • 回答日時：

No1です。


ご返答いただいたキーボードの反応、及びファイルシステムの状態から推測すると、シャットダウン処理はかなり進んだ状態でフリーズしていること、おそらくはファイルシステムのアンマウント後にフリーズしているのではないかと推測します。
更にダメ押しでご確認いただきたいのですが...

●"shutdown -r now"をコマンドラインから実行してみましょう。

これはご存知と思いますがリブート指令です。つまり、システムをシャットダウンした後続けてブート指令を行う、パソコン電源のoff指令を行いません。
発生しているトラブルは、恐らく一連のシャットダウン処理ではなく、パソコンの電源offそのものだと想定すれば、シャットダウンに続けてブートが開始され、ファイルシステムの異常も発生せず再起動を完了できるはずです。

尚、蛇足ですがせっかく画面のハードコピーを添付していただいておりますが、最初のハーコピーも含めて全く読めません。ご自身でご確認ください。
この回答への補足あり
    • good
    • 0
    • 件
通報する

No.3

  • 回答者： tacjiji
  • 回答日時：

＞・システムの更新(apt upgradeなど)　を行いました。



ubuntuは使いませんが、症状から判断すればubuntuのシステムの一部が壊れていると推測します。

更新じゃシステムは修復までしないので、インストールし直しですね。
    • good
    • 0
    • 件
通報する
この回答へのお礼

ご回答有り難うございます。
インストールし直すしかないのか、なんとなく自分もそんな気がしてきています。
ただ、手間を考えると極力避けたいので引き続き他にアイディアがございましたらご回答いただけますと幸いです。

通報する
お礼日時：2023/10/06 10:19

参考程度に

No.2

  • 回答者： davidfox
  • 回答日時：

Ubuntu 22のインストールは、そちらで実施しましたか？


仮に YESであり、USBメモリを使ってインストールしたのなら、そのUSBメモリから起動（Boot）〜シャットダウンさせてみるとどうなりますかね？
　それでもシャットダウン完了しないならば…
この回答への補足あり
    • good
    • 0
    • 件
通報する

参考程度に

No.1

  • 回答者： trka
  • 回答日時：

前回のお問い合わせ時にも回答した者です。


私自身考えてみると、どうもご質問からは『どの様な状態で止まってるか解らない』の思いを強くします。
そこで、私が特に問題解決の案を持っているわけではないのですが、質問も含めご連絡しますので、補足などでお答えいただければ他の方からの回答も期待できると思います。
内容は取り留めのないものになりますが、ご興味あるならお応えください。

恐らくフリーズした状態では「キーボード上のキーを押しても、画面にその文字は出ない。」状態だと想像します。そこで...

1.キーボードは死んでるか?
通常キーボードの"Caps.."や"NumLock"を押すとランプがついたり消えたりしますが、フリーズした状態ではどうなのでしょうか。

2.キーボードは生きている...
キーボードランプがon-offできる状態なら、フリーズ状態でもキーボードは生きていることになります。
Ctrl+F1, Ctrl+F2,...キーを押すことで、CUI画面が表示されLoginプロンプトが出てくるかも知れません。
さらにCtrl+F7で元に戻るはずですが、これらのキー操作は効くのでしょうか。または Ctrl+Alt+Delete キーで強制的にリブートできるでしょうか。

3.通常OSはシャットダウンを開始すると、ファイルシステムをアンマウントする作業を必ず行います。アンマウントせずに(その前にフリーズするために)電源をoffすると、ファイルシステムの整合性が取れぬままとなってしまい、次回のブート時(電源on時)にはfsckなるプログラムが沢山のワーニングを発生し、ひと目でわかるほどの沢山のメッセージを目にすると思います。

ご質問者様のパソコンはその様な状態なのでしょうか。ブート時に沢山のワーニングメッセージが発生しているのでしょうか。

「そうだ。」ということならファイルシステムを壊す可能性が高いので、早急な対処が必要です。「そうでない。」ということなら、シャットダウンはかなり進んだ状態でフリーズしていることになります。
もしかしたらですがシャットダウンはほぼ完了し、電源offの操作ができないだけかも知れません。

4.dmesgファイル
dmesgファイルを直接覗くのでは、イベント発生の時刻がはっきり判らないはずです。"dmesg -T"コマンドの実行で時刻を確認することができますが、但し電源再投入前の時刻を参照することができるでしょうか。私の環境では電源投入後のイベントしか参照できません。

dmesgファイルを直接覗くのは、あまり問題解決に繋がらないかも知れません。

5.その他の/var/logファイル
通常のlogファイルでは、イベントの(各行の)左側に時刻が挿入されているはずです。シャットダウンを実行した時刻を頼りにログファイルの中身を参照します。
この回答への補足あり
    • good
    • 0
    • 件
通報する

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう！

Q質問する（無料）

このQ&Aを見た人はこんなQ&Aも見ています

関連するカテゴリからQ&Aを探す

ページトップページトップ

Q質問する（無料）

このQ&Aを見た人がよく見るQ&A

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング

おすすめ情報