web-dev-qa-db-ja.com

Systemdが緊急モードに入る理由を正確に判断する方法

Debian Jessieを実行しているデスクトップコンピュータは、起動するたびに緊急モードのシェルにドロップし始めました。画面には、journalctl -xbを使用して理由を見つけ、systemctl defaultを使用して起動を続行するように指示されています。 systemctl defaultを実行すると、システムは起動し続け、システムを数週間使用した後、明らかに問題はありません。

journalctl -xbを見ると、緊急シェルにドロップする理由として何も目立ちません。 正確にが緊急モードに移行することを決定した理由を決定する簡単な方法はありますか？問題がどこにあるかを明らかにする他のフラグまたは起動オプションはありますか？

debiansystemdsystemd-journald
10
jordanm

失敗すると、コンソールに（[ FAIL ]ではなく）赤い[ OK ]が表示され、その横にユニットの説明が表示されます。通常、最初の障害が最も重要です。コンソールでshift + pageupを使用して上にスクロールし、過去数画面の出力を表示します。出力が多すぎる場合、これは機能しない可能性があります。

これは、通常[ OK ]メッセージが表示されない場合でも機能します。 Debianで使用されるカーネルコマンドラインのquietが原因です。最初の失敗時に、systemdは詳細モードに切り替わります。

それ以外の場合は、systemctlを使用できます。オプションを指定しない場合、既知のユニットの大規模なリストが表示され、障害が赤で強調表示されます。失敗したものだけを表示するには、systemctl --state=failedまたはsystemctl --failedを使用します。

ユニットファイルを検索する場合、ブートがemergency.targetにフォールバックする方法はほとんどありません。これは通常、ローカルファイルシステムの.mountユニットが失敗し、local-fs.targetが失敗した場合に発生します。または、initramfsがsystemdを使用している場合、initramfsがルートファイルシステムのマウントに失敗した場合。

local-fs.targetにはOnFailure=emergency.targetがあります。また、ローカルファイルシステムのユニットがlocal-fs.targetのRequiresリストに自動的に追加されるため、失敗します（DefaultDependencies=noがない場合）。

$ systemctl show --property Requires local-fs.target
Requires=-.mount home.mount boot.mount boot-efi.mount
6
sourcejedi

時々、「メンテナンスモード」のプロンプトが表示され、エラーについても、journaldをスクロールする必要があります。 journalctlはポケットベルとしてlessを使用するので、検索により少ないショートカットを適用できるはずです。

通常、私は検索機能（/）を使用して、「エラー」、「警告」、または「失敗」に相当するものを検索します。また、大文字と小文字を区別しない検索を強制するには、必ず-iを使用してください。

したがって、私のキーストロークは次のようになる傾向があります。

-i (case insensitive)
g (move to start)
/error
nnnn (skip through results)
g (move to start)
/fail
nnnn (skip through results)
g (move to start)
/warn
nnnn (skip through results)

厳密には、厳密な問題を網羅的または正確に検索するものではありませんが、この方法でブートの問題を見逃したことはありません。

以下の関連性の低いキーボードショートカット：

http://www.thegeekstuff.com/2010/02/unix-less-command-10-tips-for-effective-navigation/

2
madumlao