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

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

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

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

これは、通常[ OK ]メッセージが表示されない場合でも機能します。たとえばquiet、Debianで使用されるカーネルコマンドラインが原因です。最初の失敗時に、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のRequiredリストに自動的に追加されるため、失敗します（それらがなければDefaultDependencies=no）。

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

たまに「メンテナンスモード」プロンプトが表示され、エラーについてもジャーナルをスクロールする必要があります。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/