Hinemos: ジョブエラー時のジョブの挙動について


###### 実施環境：

```Linux:Linux
[root@testhost ~]# uname -a
Linux testhost 4.18.0-338.el8.x86_64 #1 SMP Fri Aug 27 17:32:14 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
[root@testhost ~]# cat /etc/redhat-release
CentOS Stream release 8
[root@testhost ~]# yum list installed | grep hinemos
hinemos-7.0-agent.noarch                           7.0.1-1.el                                                 @@commandline
hinemos-7.0-manager.x86_64                         7.0.1-1.el8                                                @@commandline
hinemos-7.0-web.x86_64                             7.0.1-1.el8                                                @@commandline
```

### 0. 概要

ジョブは、必ずしも正常に動作するものではありません。
設定ミス、サーバの故障、リソースの枯渇など、様々な原因でエラーとなることがあります。
ではそのとき、 Hinemos で作成したジョブはどのように動作するのでしょうか。
今回は Hinemos のジョブについて、エラー時の動作に関する設定を見ていきます。

### 1. 今回使用するジョブ

今回使用するジョブは、以下の通りです。

#### 1.1. ジョブユニット

* ジョブ ID : `job_unit_00`
* ジョブ名：ジョブユニット_00

![WS000110.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/0e0ed2ac-11b1-e338-d620-13350421049e.jpeg "jobunit")

#### 1.2. ジョブネット

* ジョブ ID : `jobnet_00`
* ジョブ名：ジョブネット_00

![WS000111.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/e915831e-1360-0649-90f4-b8ebbf4413ca.jpeg "jobnet")

#### 1.3. ジョブ

##### 1.3.1. 1 番目のジョブ

* ジョブ ID : `job_01`
* ジョブ名：ジョブ_01
* 起動コマンド： `echo "01" >> /tmp/00.log`

![WS000112.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/5bffb8a9-9313-3a5b-d5ca-8555fde9a78f.jpeg "job1")

##### 1.3.2. 2 番目のジョブ

* ジョブ ID : `job_02`
* ジョブ名：ジョブ_02
* 起動コマンド： `echo "02" >> /tmp/00.log`
* 待ち条件 - 名前：ジョブ(終了状態)
* 待ち条件 - ジョブ ID ： `job_01`
* 待ち条件 - 値：正常

![WS000113.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/3e399327-4c65-39e0-3e58-c4fa4570ba66.jpeg "job2_1")

![WS000115.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/dd9e8c88-9050-3c81-aa27-b2c6017f8918.jpeg "job2_2")

##### 1.3.3. 3 番目のジョブ

* ジョブ ID : `job_03`
* ジョブ名：ジョブ_03
* 起動コマンド： `test -f /tmp/00.txt`
* 待ち条件 - 名前：ジョブ(終了状態)
* 待ち条件 - ジョブ ID ： `job_02`
* 待ち条件 - 値：正常

![WS000123.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/d78ddae5-1e98-9867-fbec-aa31dbb624ee.jpeg "job3_1")

![WS000116.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/d11fbce8-b6e6-ec30-b1f7-49889d4b3069.jpeg "job3_2")

 `/tmp/00.txt` が無ければ、コマンドが戻り値「 1 」を返してこのジョブがエラー終了します。
 (厳密には、デフォルトの設定だと戻り値「 1 」の場合の終了状態は「警告」という扱いになります。)

##### 1.3.4. 4 番目のジョブ

* ジョブ ID : `job_04`
* ジョブ名：ジョブ_04
* 起動コマンド： `echo "04" >> /tmp/00.log`
* 待ち条件 - 名前：ジョブ(終了状態)
* 待ち条件 - ジョブ ID ： `job_03`
* 待ち条件 - 値：正常

![WS000119.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/d3d28918-8d16-6c97-d2da-e59b133acfa9.jpeg "job4_1")

![WS000118.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/4d1d891e-2944-2eeb-65b7-36df6cbcdf40.jpeg "job4_2")

##### 1.3.5. 5 番目のジョブ

* ジョブ ID : `job_05`
* ジョブ名：ジョブ_05
* 起動コマンド： `echo "05" >> /tmp/00.log`
* 待ち条件 - 名前：ジョブ(終了状態)
* 待ち条件 - ジョブ ID ： `job_04`
* 待ち条件 - 値：正常

![WS000121.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/308bed0f-40f7-8b17-4e38-17e746bd4ee0.jpeg "job5_1")

![WS000120.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/6f8b97bf-c936-6087-52cc-396a1709f28f.jpeg "job5_2")

### 2. 中止

上記の設定で、 3 番目のジョブがエラー(警告)となるようにしてジョブネットを起動してみましょう。
すると、以下のような結果となります。

![WS000128.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/7d74df29-1502-e723-45e2-e4de1dd57b6c.jpeg "2_1")

 3 番目のジョブがエラー(警告)となると、後ろの 4 番目と 5 番目のジョブは実行されないままエラー(異常)扱いとなり終了しています。
 OS 側からファイルを見ても、 1 番目のジョブと 2 番目のジョブの分しかファイルに書き込みがなされていないので、 3 番目のジョブより後ろのジョブは実行されていないことがわかります。

```Linux:Linux
[root@testhost tmp]# cat 00.log
01
02
[root@testhost tmp]#
```

デフォルトではこのように、「エラーとなったジョブの後ろのジョブは実行されない」ことになります。
エラーとなった際に「最初のジョブから実行をやり直したい」場合は、この設定を使用します。

### 3. 保留

では次に、 4 番目のジョブについて、「待ち条件」タブの「条件を満たさなければ終了する」のチェックを外して、先ほどと同様に 3 番目のジョブをエラー(警告)にしてみましょう。

![WS000129.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/c33881b6-b656-0b7c-1bb0-436856246c74.jpeg "3_1")

結果は以下の通りです。

![WS000131.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/9b818068-9aa1-0504-0834-d62502ac76ba.jpeg "3_2")

エラー(警告)となった 3 番目のジョブの後ろのジョブは、「待機」となっています。
ジョブネット全体も、まだ「実行中」という扱いになっています。

ではここで、 `/tmp/00.txt` を作成して 3 番目のジョブが正常終了するようにして、 3 番目のジョブを再度実行してみましょう。

![WS000133.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/5de86df2-418c-9194-e07d-3aef91c3fadf.jpeg "3_3")

![WS000134.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/5fa14b37-1f7b-36e6-4a95-3c7a4011a6cc.jpeg "3_4")

すると、最後のジョブまで正常に動作しました。

![WS000136.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/80a208e5-e2f6-678d-3ad4-64836f0b0b84.jpeg "3_5")

 OS 側からファイルを見ても、全てのジョブ分の書き込みが正しく動作していることがわかります。

```Linux:Linux
[root@testhost tmp]# cat 00.log
01
02
04
05
[root@testhost tmp]#
```

一方、ジョブネット全体を停止させることで、後ろのジョブの実行を取りやめることも可能です。

![WS000150.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/f11e8198-0d05-a11d-93ab-0dae60dcecff.jpeg "3_6")

![WS000151.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/e5131bef-ddd9-7722-105f-be30bdfde266.jpeg "3_7")

![WS000153.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/7a29085d-bc61-62e5-657c-0e3cf8950261.jpeg "3_8")

このように、「条件を満たさなければ終了する」のチェックを外すことで、「エラーとなったジョブの後ろのジョブは一旦実行を保留し、エラーの原因が解消されたら手動でジョブを再実行できる」ようにすることができます。
エラーとなった際に「エラーとなったジョブから実行をやり直したい」場合は、この設定を使用します。

なお、「条件を満たさなければ終了する」が機能するのは、この設定を入れたジョブがエラーとなった場合ではなく、この設定を入れたジョブの「前のジョブが」エラーとなった場合であることに注意してください。

### 4. スキップ

最後に、 4 番目のジョブについて、「待ち条件」タブの「条件を満たさなければ終了する」のチェックを入れた状態に戻したうえで、待ち条件の「値」を「 * 」に変更します。
この状態で 3 番目のジョブをエラー(警告)にしてみましょう。

![WS000158.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/71362223-64ba-e2d7-abde-c4cd5908089f.jpeg "4_1")

結果は以下の通りです。

![WS000160.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1465018/3b17ac66-48d5-c0ff-7e95-0e08121bee4f.jpeg "4_2")

エラー(警告)となった 3 番目のジョブの後ろのジョブも、問題なく動作しています。
 OS 側からファイルを見ても、 3 番目のジョブの後ろの 4 番目と 5 番目のジョブ分の書き込みが実行されていることがわかります。

```Linux:Linux
[root@testhost tmp]# cat 00.log
01
02
04
05
[root@testhost tmp]#
```

このように、待ち条件の「値」を「 * 」に変更することで、「エラーとなったジョブの後ろのジョブも通常通り実行される」形となります。
エラーとなった際も「エラーとなったジョブの後ろのジョブを通常通り実行したい」場合は、この設定を使用します。

先ほどと同様、この設定が機能するのは設定を入れたジョブの「前のジョブが」エラーとなった場合であることに注意してください。

### 5. まとめ

エラーとなったジョブの後ろのジョブを

* __実行させたくない(中止)__
__⇒ デフォルト設定のまま__

* __エラーが解消するまで待機させたい(保留)__
__⇒ エラーとなったジョブの後ろのジョブの「待ち条件」タブの「条件を満たさなければ終了する」のチェックを外す__

* __そのまま実行させたい(スキップ)__
__⇒ エラーとなったジョブの後ろのジョブの待ち条件の「値」を「 * 」に変更__