私はsystemdに慣れていません。この質問について私が求める答えは次のとおりです。
どうやって作ることができますか？システム単にシステムを応答しない状態にするのではなく、「ユーザーを一種の緊急シェルに配置」して問題に対応しますか？
明確な例：ThinkPadにArch Linuxをインストールした場合、x-org-server、wayland、systemd、またはlightdmにいくつかの構成エラーがあるようです。エラーメッセージは表示されませんが、ユーザーがハングアップします。これは、ユーザーがエラーメッセージを生成せずに停止したtty1のサービス/開始メッセージ出力を表示できることを意味します（存在する場合は光栄です）。システムログ食べましたか？ ）キーの組み合わせなしでルートシェルを作成して、ユーザーがエラーを確認して修正することもできます。
したがって、答えは、エラーが原因でシステムがクラッシュするのを防ぐために緊急シェルに入るようにsystemdを設定する方法です。グラフィックターゲット
たとえば、このU&L質問でこのような停止状況がどのように発生するのか」アーチ - Linux - ジャム - 到達 - ターゲット - グラフィックス - インターフェース」
答え1
systemd構成のどの部分にも応答しないシステムは、意図的なパスとして含まれていません。
システムするプロセス管理専用の設定がたくさんあります。例を見るRestart=そしてOnFailure=。
問題を解決し、システムが応答しないようにするには、原因が何であるかをよりよく理解する必要があります。確認はjournalctl -xe良い開始点です（おそらく再起動後）。出力で「致命的」または「エラー」を検索してみてください。
カーネルパニックやメモリ破損が発生した場合、systemdどのような状況でも役に立ちません。
答え2
Emergency.targetは、デバイスがエラー状態に入ったときにOnFailure=emergency.targetこのセクション[Unit]でそれを使用してトリガーできます。つまり、サービス「停止」（永久に使用されているループ）はエラー状態をトリガーせず、サービスが終了するかタイムアウトに達するまで実行され続けます。
Systemdは、「停止」プログラムが意図したとおりに機能するか失敗するかを知る方法はありません。これはシステム管理者によって異なります。