「ジョブを停止しています...」のように、「ジョブを停止」とは正確には何ですか?


28

シャットダウンコマンドが発行された後、次のようなステータスメッセージが表示されることがあります。

A stop job is running for Session 1 of user xy

そして、システムがしばらくハングアップするか、???

それで、「ストップジョブ」とは正確には何ですか?

また、なぜそれがかかる時間を非常に正確に推定し、他の時間を永遠に実行できるのかを推定するのはなぜですか?


1
たぶんそれは仕事を止めるべきですか?セッションは、実際に実行されていないジョブを停止したため、終了シグナルに応答する機会がありません。
カズ

回答:


27

systemdは、「ジョブ」のキューに関して内部的に動作します。各ジョブ(少し簡略化)は、実行するアクションです:特定のユニットを停止、確認、開始、または再起動します。

(たとえば)systemdにサービスユニットの開始を指示すると、その目標を達成するために必要なユニット(サービスユニット、マウントユニット、デバイスユニットなど)の停止および開始ジョブのリストが作成されます。ユニットの要件と依存関係、ユニットの順序関係に従ってそれらを順序付け、解決し(可能な場合)自己矛盾を修正し、(その最終ステップが成功した場合)それらをキューに入れます。

次に、キューに入れられた「ジョブ」を実行しようとします。

ユーザーxyのセッション1で停止ジョブが実行されています

ここでのユニット表示名Session 1 of user xyです。これは(表示名から)サービスユニットではなくセッションユニットになります。これは、systemdのプログラムとそのPAMプラグインによって維持されるユーザー空間ログインセッションの抽象化です。(本質的に、理論的には)そのユーザーがどこかで「ログインセッション」として実行しているすべてのプロセスのグループ化です。logind

それに対してキューに入れられたジョブはstopです。systemdの人々がセッションのハングアップとセッションのシャットダウンを誤って混同しているため、おそらく長い時間がかかります。前者を壊して後者を機能させ、それに応じてsystemdを変更して後者を壊して前者を機能させます。systemdの人々は、彼らが2つの異なるものであることを本当に認識すべきです。

ログインセッションでは、を無視するSIGTERMか、終了してから終了するまでに時間がかかるものがありますSIGTERM。皮肉なことに、前者はいくつかのジョブ制御シェルの長年の振る舞いです。彼らはこれらの特定のジョブ制御シェルがあるときに、ログインセッションのリーダーを終了する正しい方法は、セッションがされたこと、それらを伝えることですハングアップ、彼らはすべて終了し、そこで、彼らのその後(内部にsystemdジョブにジョブの異なる種類の)仕事をし、自分自身を終了します。

実際に起こっているのは、systemdがに頼るまでユニットの停止タイムアウトを待っていることSIGKILLです。もちろん、このタイムアウトはユニットごとに設定可能で、タイムアウトしないように設定できます。したがって、なぜ異なる行動を潜在的に見ることができるのか。

参考文献


1
この回答、unix.stackexchange.com / a / 297318/224025によると、今回は変更できます。ゼロ秒に変更すると、安全になりますか?
ジプシー宇宙飛行士

1
実際、この回答の最後の段落と、さらに読み進めほしいユーザーマニュアルには、タイムアウトの変更についての説明があります。0sタイムアウトの意味と使用するのが安全かどうかについての質問は、「ジョブの停止」とは何か、タイムアウトが変化する理由の質問への後続の質問であるため、質問方法ごとに質問してください。良いかもしれないと思う。
JdeBP

2

これらのメッセージはsystemdからのものです。systemdは、ジョブを開始および停止するinitシステムです。ジョブはデーモンになる可能性がありますが、ディスクのマウントとアンマウント、/ tmpの削除、ブート全体の画面の明るさの保存と復元などの小さなタスクも可能です。systemctl list-unitsあなたにアイデアを与えます。Systemdは「ユニット」と「ジョブ」を使用してほぼ同じことを意味します。

のように、ジョブが停止しているsystemctl stop ...場合、問題は、失敗を宣言し、SIGKILLシグナルでジョブのプロセスを強制終了する前に、ジョブが完了するまでどのくらい待つかです。SIGKILLプロセスが正常に終了する機会を与えないため、必要な場合を除き、本当に使用したくありません。一部のプロセスでは、障害を宣言するのに十分な時間がかかる場合があります。データベースなどの他のプロセスでは、ジョブが正常に停止するためにかなりのネットワークおよびディスクI / Oがあります。 。

シャットダウン時に表示されるものは、systemctl stop $UNIT_NAME実行に時間がかかるのと同じです。SIGKILLが発行され、シャットダウンが続行されるまでの経過秒数と最大待機時間を示すカウンターがあります。

長い遅延が予想される正当な理由がない限り、これは通常何らかの誤動作を示します。これは、DHCPサーバーがリリースに応答しないため、リリースアクションがタイムアウトする必要があるか、デーモンが終了しない原因となる何らかのエラーが発生する可能性があります。


「Systemdは「ユニット」と「ジョブ」を使用してほぼ同じことを意味します。」私はそれが本当だとは思いません。大まかに言って、「ジョブ」は「ユニット」に対して何かをするリクエストです。詳細については、@ JdeBPの回答を参照してください。
トーマス

1

一部のサービスがスタックし、systemdは終了するのを待っています。Systemdはおそらく、かかる時間を正確に推定していません。時間(通常90秒)は、忍耐が尽きるまでsystemdが待機する時間です。この投稿を参照してください:

ユーザーのセッションc2に対して停止ジョブが実行されています


6
どのサービスがハングするのか、どうすればわかりますか?
naitsirch

0

「ジョブの停止」とはsystemd、特定の「ジョブ」の停止を待機している場合です。たとえば、先に進む前に完了を待機しているプロセスがあります。「ジョブを停止しています...」などの警告メッセージが表示された場合、技術的にはジョブキューで何かが保留されていることを意味します。

ただし、システムジョブキュー全体を掘り下げる前に、これらの警告メッセージが環境要因による間接的な結果である場合があることに注意してください(実際、メッセージはバグとしてGitHubリポジトリでも参照されます)。

たとえば、「ジョブを停止」関連のメッセージを受け取っていたが、その理由を理解できませんでした。結局、ディスクの容量がほとんどなくなり、OSの動作がおかしくなりました。

サーバーをより大きなディスクにアップグレードして再起動すると修正されました;)

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.