回答:
systemdは、「ジョブ」のキューに関して内部的に動作します。各ジョブ(少し簡略化)は、実行するアクションです:特定のユニットを停止、確認、開始、または再起動します。
(たとえば)systemdにサービスユニットの開始を指示すると、その目標を達成するために必要なユニット(サービスユニット、マウントユニット、デバイスユニットなど)の停止および開始ジョブのリストが作成されます。ユニットの要件と依存関係、ユニットの順序関係に従ってそれらを順序付け、解決し(可能な場合)自己矛盾を修正し、(その最終ステップが成功した場合)それらをキューに入れます。
次に、キューに入れられた「ジョブ」を実行しようとします。
ユーザーxyのセッション1で停止ジョブが実行されています
ここでのユニット表示名はSession 1 of user xy
です。これは(表示名から)サービスユニットではなくセッションユニットになります。これは、systemdのプログラムとそのPAMプラグインによって維持されるユーザー空間ログインセッションの抽象化です。(本質的に、理論的には)そのユーザーがどこかで「ログインセッション」として実行しているすべてのプロセスのグループ化です。logind
それに対してキューに入れられたジョブはstop
です。systemdの人々がセッションのハングアップとセッションのシャットダウンを誤って混同しているため、おそらく長い時間がかかります。前者を壊して後者を機能させ、それに応じてsystemdを変更して後者を壊して前者を機能させます。systemdの人々は、彼らが2つの異なるものであることを本当に認識すべきです。
ログインセッションでは、を無視するSIGTERM
か、終了してから終了するまでに時間がかかるものがありますSIGTERM
。皮肉なことに、前者はいくつかのジョブ制御シェルの長年の振る舞いです。彼らはこれらの特定のジョブ制御シェルがあるときに、ログインセッションのリーダーを終了する正しい方法は、セッションがされたこと、それらを伝えることですハングアップ、彼らはすべて終了し、そこで、彼らのその後(内部にsystemdジョブにジョブの異なる種類の)仕事をし、自分自身を終了します。
実際に起こっているのは、systemdがに頼るまでユニットの停止タイムアウトを待っていることSIGKILL
です。もちろん、このタイムアウトはユニットごとに設定可能で、タイムアウトしないように設定できます。したがって、なぜ異なる行動を潜在的に見ることができるのか。
これらのメッセージはsystemdからのものです。systemdは、ジョブを開始および停止するinitシステムです。ジョブはデーモンになる可能性がありますが、ディスクのマウントとアンマウント、/ tmpの削除、ブート全体の画面の明るさの保存と復元などの小さなタスクも可能です。systemctl list-units
あなたにアイデアを与えます。Systemdは「ユニット」と「ジョブ」を使用してほぼ同じことを意味します。
のように、ジョブが停止しているsystemctl stop ...
場合、問題は、失敗を宣言し、SIGKILL
シグナルでジョブのプロセスを強制終了する前に、ジョブが完了するまでどのくらい待つかです。SIGKILL
プロセスが正常に終了する機会を与えないため、必要な場合を除き、本当に使用したくありません。一部のプロセスでは、障害を宣言するのに十分な時間がかかる場合があります。データベースなどの他のプロセスでは、ジョブが正常に停止するためにかなりのネットワークおよびディスクI / Oがあります。 。
シャットダウン時に表示されるものは、systemctl stop $UNIT_NAME
実行に時間がかかるのと同じです。SIGKILLが発行され、シャットダウンが続行されるまでの経過秒数と最大待機時間を示すカウンターがあります。
長い遅延が予想される正当な理由がない限り、これは通常何らかの誤動作を示します。これは、DHCPサーバーがリリースに応答しないため、リリースアクションがタイムアウトする必要があるか、デーモンが終了しない原因となる何らかのエラーが発生する可能性があります。
一部のサービスがスタックし、systemdは終了するのを待っています。Systemdはおそらく、かかる時間を正確に推定していません。時間(通常90秒)は、忍耐が尽きるまでsystemdが待機する時間です。この投稿を参照してください:
「ジョブの停止」とはsystemd
、特定の「ジョブ」の停止を待機している場合です。たとえば、先に進む前に完了を待機しているプロセスがあります。「ジョブを停止しています...」などの警告メッセージが表示された場合、技術的にはジョブキューで何かが保留されていることを意味します。
ただし、システムジョブキュー全体を掘り下げる前に、これらの警告メッセージが環境要因による間接的な結果である場合があることに注意してください(実際、メッセージはバグとしてGitHubリポジトリでも参照されます)。
たとえば、「ジョブを停止」関連のメッセージを受け取っていたが、その理由を理解できませんでした。結局、ディスクの容量がほとんどなくなり、OSの動作がおかしくなりました。
サーバーをより大きなディスクにアップグレードして再起動すると修正されました;)