１．ありがちな定常ジョブネットワークを構築
1-1.盛り込むこと（ポイント）
・「ジョブグループ－ルートジョブネット－ネストジョブネット－ジョブ」のように階層構造にする
※親ジョブグループ－子ジョブグループ（複数）ってする
※ルートジョブネット－ネストジョブネット（複数）ってする
・別のジョブネットにイベントを送信する「イベント送信ジョブ」を含める
・別のジョブネットからイベントを受信する「イベント受信ジョブ」を含める
・何をするときにどのリソースをどのくらい使うか？
リソースはメモリとCPU
1-2.構築
・ジョブグループ
※ジョブグループはカレンダー情報を保有するユニット
・カレンダー
- 複数のカレンダーの合成
・ルートジョブネット
- 日時指定
・スケジュール
- 複数のスケジュールの使い分け
- 複数のスケジュールの合成
・ネストジョブネット
・UNIXジョブ
- 待ち合わせ実行とは
- 分岐と合流
-
1-3.テスト
・
２．1．で作成した定常ジョブネットワークを操作してみる
※「実行制御」は下記のとおり
①実行登録、②実行登録解除、③遅延監視一時変更、④計画日時変更（日時変更）、⑤計画一時変更（即時実行）、⑥計画一時変更（実行中止）、⑦保留、⑧保留解除、⑨優先順位の一時変更、⑩中断、⑪強制終了、⑫再実行、⑬状態変更
※「状態」は下記の通り
未登録、開始時刻待ち、先行終了待ち、保留中、実行待ち、未実行終了（実行予定なし）、未実行終了（実行予定あり）、計画未実行、実行中、キューイング、異常検出実行中、異常警告検出実行中、正常終了、警告検出終了、異常検出終了、繰越未実行（実行予定なし）、繰越未実行（実行予定あり）、順序不正、中断、強制終了、起動失敗、終了状態不明、閉塞、開始遅延、ネスト開始遅延、終了遅延、ネスト終了遅延
2-1.保留からの再実行
2-2.ジョブネットを中断してスケジュール一時変更して再開して翌日に元のスケジュールに戻す
・
2-3.実行中止して一日分スキップして2日後から平常に実行
2-4.ジョブをわざとこけさせて次のジョブから実行
2-5.ジョブをわざとこけさせてジョブスクリプトを修正後こけたジョブから再開
2-6.予定通り終わらないジョブを強制終了して次のジョブから再開
2-7.開始遅延監視検証
・ノーマルな遅延監視
・遅延開始一時変更からの戻し
2-8.終了遅延監視検証
・ノーマルな遅延監視
・遅延開始一時変更からの戻し
2-9.監視静観
2-10.強制停止
■ジョブのフォアグラウンドプロセスへの強制終了
→強制終了が発行された時点までの処理が完了し発行以後の処理が未済になることを確認
■ジョブのバックグラウンドプロセスへの強制終了
→強制終了が発行された後も処理が最後まで完了してから子プロセスが終了することを確認
３．１．で作成したジョブネットワークを別のJP1/AJS3マネージャホストに移行する
3-0.バックアップとリストア
■ジョブグループ1のリソースを別のジョブグループ2にコピー（バックアップ&リストア）
・操作
・動作確認
■JP1/AJS3のエクスポートとかインポートのような機能でリソースのバックアップとリストア
・操作
・動作確認
3-1.単純移行
3-2.ホスト名とIPアドレスを変更して移行
3-3.
4．通信やプロセスに関して2～3のリバースエンジニアリングもどき
4-1.マネージャホストとエージェントホスト間の通信を覗く
マネージャとエージェントのファイアウォールの透過方向（=通信の方向とport番号一覧）
4-2.プロセスにメスを入れてみる
・UNIXジョブの環境変数調査
・UNIXジョブの実行ユーザ調査
- トラバースできるディレクトリ、できないディレクトリ
- 書き込めるディレクトリ、できないディレクトリ
・フォアグランド実行するジョブ
・バックグラウンド実行するジョブ（振り逃げジョブ）
・主なプロセスに関してlsofしてみる
・メモリやFDの使い方が気になるプロセスをstraceしてみる
4-3.変なカーネルモジュールの使い方してるプロセスは居るか？
4-4.変なライブラリとリンクしてるプロセスは居るか？
4-5.変なプロセス間通信してるプロセスは居るか？
・共有メモリ
・パイプ
・ソケット
・その他
4-6.ログの種類と持ち方
4-7.スケジューラサービスのリバースエンジニアリングもどき
※エージェントホストがマネージャホストの名前解決に失敗してエージェントからマネージャへジョブ終了通知が届かなかった際に一定期間マネージャ側でキューイングされていた。
途中で通信断があった際にジョブの状態はタイムアウトまで（もし設定されていれば）キューイングされるっぽい。
→どこにキューが居るのか？ジョブマネージャもメールサーバやプリンタサーバやメッセージキューのようにメッセージや文書のロストを防ぐのと同様にジョブの状態の情報をロストしないように先入先出なキューが居るんだよね（たぶん）
→ジョブスケジューラがロスとしてはいけないのはマネージャ⇔エージェント間で取り交わされる情報のうち何？ マネージャから→エージェントは実行命令？ エージェントからマネージャは実行結果？ ジョブスケジューラにとってすべてのユニットの状態が「未確定」であることは許されない？ 成功、失敗、実行中、キューイング中、・・・など必ず状態が確定する必要がある？ ジョブスケジューラでもっともやってはいけないことはジョブの多重実行、ジョブ実行漏れ、ジョブ状態通知ミス、ジョブ結果通知ミス？ほかに何？ もし2重実行してはいけないプロセスを2重実行してしまったらホスト上のデータやシステムを破損しかねない
契約上その日にやらなければならないジョブは確実に正しくやれてる必要がある一方、万一異常があった場合には確実に把握される必要がある？ 正しくやれるというのはただ実行すればいいだけじゃなくて順序性が定義通り守られたうえで実行される必要がある
これらのジョブスケジューラに求められる要件を満たすためにジョブスケジューラにはいろいろな七面倒くさい仕様があるのだと思う。てへぺろ。
5.イベントジョブの動作を調べる
5-1.JP1イベント受信監視ジョブ
5-2.ファイル監視ジョブ
5-3.ログファイル監視ジョブ
5-4.実行間隔制御ジョブ
----これ以降はやれればやる----
6.JP1/AJS3 Managerクラスタ構成
6-1.設計
6-2.構築
6-3.動作確認
■TKOしてみる
■
１．ありがちな定常ジョブネットワークを構築
1-1.盛り込むこと（ポイント）
・「ジョブグループ－ルートジョブネット－ネストジョブネット－ジョブ」のように階層構造にする
※親ジョブグループ－子ジョブグループ（複数）ってする
※ルートジョブネット－ネストジョブネット（複数）ってする
・別のジョブネットにイベントを送信する「イベント送信ジョブ」を含める
・別のジョブネットからイベントを受信する「イベント受信ジョブ」を含める
・何をするときにどのリソースをどのくらい使うか？
リソースはメモリとCPU
1-2.構築
・ジョブグループ
・カレンダー
- 複数のカレンダーの合成
・ルートジョブネット
- 日時指定
・スケジュール
- 複数のスケジュールの使い分け
- 複数のスケジュールの合成
・ネストジョブネット
・UNIXジョブ
- 待ち合わせ実行とは
- 分岐と合流
-
1-3.テスト
・
２．1．で作成した定常ジョブネットワークを操作してみる
2-1.保留からの再実行
2-2.ジョブネットを中断してスケジュール一時変更して再開して翌日に元のスケジュールに戻す
・
2-3.実行中止して一日分スキップして2日後から平常に実行
2-4.ジョブをわざとこけさせて次のジョブから実行
2-5.ジョブをわざとこけさせてジョブスクリプトを修正後こけたジョブから再開
2-6.予定通り終わらないジョブを強制終了して次のジョブから再開
2-7.開始遅延監視検証
・ノーマルな遅延監視
・遅延開始一時変更からの戻し
2-8.終了遅延監視検証
・ノーマルな遅延監視
・遅延開始一時変更からの戻し
2-9.監視静観
2-10.
３．１．で作成したジョブネットワークを別のJP1/AJS3マネージャホストに移行する
3-0.バックアップとリストア
■ジョブグループ1のリソースを別のジョブグループ2にコピー（バックアップ&リストア）
・操作
・動作確認
■JP1/AJS3のエクスポートとかインポートのような機能でリソースのバックアップとリストア
・操作
・動作確認
3-1.単純移行
3-2.ホスト名とIPアドレスを変更して移行
3-3.リグレ環境でテスト後ホスト名等を変えて本番環境にジョブネットワーク資源をリリース
4．通信やプロセスに関して2～3のリバースエンジニアリングもどき
4-1.マネージャホストとエージェントホスト間の通信を覗く
マネージャとエージェントのファイアウォールの透過方向（=通信の方向とport番号一覧）
4-2.プロセスにメスを入れてみる
・主なプロセスに関してlsofしてみる
・メモリやFDの使い方が気になるプロセスをstraceしてみる
4-3.変なカーネルモジュールの使い方してるプロセスは居るか？
4-4.変なライブラリとリンクしてるプロセスは居るか？
4-5.変なプロセス間通信してるプロセスは居るか？
・共有メモリ
・パイプ
・ソケット
・その他
4-6.ログの種類と持ち方
4-7.スケジューラサービスのリバースエンジニアリングもどき
※エージェントホストがマネージャホストの名前解決に失敗してエージェントからマネージャへジョブ終了通知が届かなかった際に一定期間マネージャ側でキューイングされていた。
途中で通信断があった際にジョブの状態はタイムアウトまで（もし設定されていれば）キューイングされるっぽい。
→どこにキューが居るのか？ジョブマネージャもメールサーバやプリンタサーバやメッセージキューのようにメッセージや文書のロストを防ぐのと同様にジョブの状態の情報をロストしないように先入先出なキューが居るんだよね（たぶん）
→ジョブスケジューラがロストしてはいけないのはマネージャ⇔エージェント間で取り交わされる情報のうち何？ マネージャから→エージェントは実行命令？ エージェントからマネージャは実行結果？ ジョブスケジューラにとってすべてのユニットの状態が「未確定」であることは許されない？ 成功、失敗、実行中、キューイング中、・・・など必ず状態が確定する必要がある？ ジョブスケジューラでもっともやってはいけないことはジョブの多重実行、ジョブ実行漏れ、ジョブ状態通知ミス、ジョブ結果通知ミス？ほかに何？ もし2重実行してはいけないプロセスを2重実行してしまったらホスト上のデータやシステムを破損しかねない
契約上その日にやらなければならないジョブは確実に正しくやれてる必要がある一方、万一異常があった場合には確実に把握される必要がある？ 正しくやれるというのはただ実行すればいいだけじゃなくて順序性が定義通り守られたうえで実行される必要がある
これらのジョブスケジューラに求められる要件を満たすためにジョブスケジューラにはいろいろな七面倒くさい仕様があるのだと思う。てへぺろ。
5.イベントジョブの動作を調べる
5-1.JP1イベント受信監視ジョブ
5-2.ファイル監視ジョブ
5-3.ログファイル監視ジョブ
5-4.実行間隔制御ジョブ
----これ以降はやれればやる----
6.JP1/AJS3 Agenthostクラスタ構成
6-1.設計
■論理ホスト
■物理ホスト
6-2.構築
■論理ホストと物理ホストが共存するジョブネットワーク
※例えばデータバックアップは共有ディスク（共有ディスク方式の場合）にアクセス権がある方のノード（アクティブな論理ホスト）上でジョブを実行する
一方、システムバックアップはプライマリホストとセカンダリホストの両方のホスト（物理ホスト）上のジョブを実行する。
6-3.動作確認
■TKOしてみる
■
のつづき
・リモートホストはManagerのhostsに登録済
[root@centos7_local ~]# grep centos7_2_local /etc/hosts
192.168.72.4 centos7_2_local
192.168.101.4 centos7_2_local
[root@centos7_local ~]# ping -c 1 centos7_2_local
PING centos7_2_local (192.168.72.4) 56(84) bytes of data.
64 bytes from centos7_2_local (192.168.72.4): icmp_seq=1 ttl=64 time=0.563 ms
--- centos7_2_local ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.563/0.563/0.563/0.000 ms
・リモートホストをManagerにAgentとして登録
[root@centos7_local ~]# /opt/jp1ajs2/bin/ajsagtadd -a centos7_2_local-agt -s centos7_2_local -c 00:00-00:00=5
KNAC1100-I コマンドが正常終了しました
[root@centos7_local ~]# /opt/jp1ajs2/bin/ajsagtshow -l
KNAC1101-I エージェント管理の情報の出力を開始します
HOSTNAME:centos7_local
AGENT STATUS HOST CON-EXE QUE JOB EVENT DESCRIPTION
--------------- ------ -------------- -------- ----- ----- ----- --------------------
@SYSTEM Ef centos7_local 5 0 0 0
centos7_local-agt Ef centos7_local 5 0 0 0
centos7_2_local-agt Ef centos7_2_local 5 0 0 0
KNAC1102-I エージェント管理の情報の出力を終了します
JP1/Viewから実行登録したジョブがAgentでも実行できた
※Managerのrootのssh公開鍵をAgentのauthorized_keysに登録しなくてもリモートジョブを
Agent側で実行できた
→（ここから20211207追記）しかしなぜかエージェント側でジョブを実行してもステータスが「実行中」のままで「終了」にならない。
ジョブネットのステータスを見たらジョブがなぜかキューイングしてた
後続ジョブも「先行ジョブ終了待ち」のまま
エージェントからマネージャにジョブの終了コードが送信できてない？
もしかしたらJP1/AJS3 - Agentのセットアップで何かやれてない部分がありそう
【とりあえず試したこと】
■エージェント側ホストにもrootにjp1adminと同じJP1の権限を付与
/etc/opt/jp1base/conf/user_acl/JP1_UserLevel にrootのエントリを追記
→依然解決せず
■エージェント側とマネージャ側の両方で互いを許可する接続許可設定
/etc/opt/jp1ajs2/conf/
- マネージャー用接続許可設定ファイル
-
permitted_host_manager.conf
- エージェント用接続許可設定ファイル
-
permitted_host_agent.conf
に互いのIPアドレスを追記して保存してシステムリブート
→依然解決せず
■これを見たけどどれもまずってない
マネージャホストもエージェントホストもリスニングすべきポートではすべてリスニングしてた。
サービスもどっちも全部起動してる
・マネージャホスト側
[root@centos7_local log]# /opt/jp1ajs2/bin/jajs_spmd_status
KNAD3690-I JP1/AJS3 の状態通知処理を開始します
稼働中のプロセスを表示します
プロセス名称 プロセスID 属性
jajs_dbmd 1679 _JF0
ajsdbmgrd 1680 _JF0
jajs_hstd 1985
ajshlogd 1986
ajsinetd 1988
ajsnetwd 1990
ajsagtmd 1995
jpqman_hst 1996
jpomanager_hst 1997
ajscdinetd 1999
ajsgwmasterd 1987
jajs_agtd 2022
jpqmon 2023
jpoagent 2024
jajs_schd 2051 AJSROOT1
ajslogd 2052 AJSROOT1
jpqman 2053 AJSROOT1
jpomanager 2077 AJSROOT1
ajsmasterd 2079 AJSROOT1
KNAD3691-I プロセスは全て起動しています
・エージェントホスト側
[root@centos7_2_local ~]# /opt/jp1ajs2/bin/jajs_spmd_status
KNAD3690-I JP1/AJS3 の状態通知処理を開始します
稼働中のプロセスを表示します
プロセス名称 プロセスID
jpqmon 3368
jpoagent 3369
KNAD3691-I プロセスは全て起動しています
もう一度JP1/AJS3 Viewでジョブの状態や結果を確認する
※UNIX0ジョブはマネージャホスト側で実行するジョブでUNIX1とUNIX2はエージェントホスト側で実行されるジョブ
UNIX1ジョブをダブルクリックして
「詳細...」をクリックしたら
「KAVU4597-W エージェント(centos7_2_local)で消失したジョブを強制終了します」
となっていた！
「KAVU4597-W」をググると、下記サイトが見つかった
上記によると、次のことが考えられるらしい。
-
エージェントホストからジョブの終了通知が失敗している状態でエージェントホストのJP1/AJS3サービスが停止した。
-
エージェントホストでジョブを実行中のまま，JP1/AJS3サービスが異常終了した。
「終了通知が失敗している」とはなんぞ・・・
たしかにＵＮＩＸ1ジョブは終了状態にならないがＵＮＩＸ1ジョブスクリプトはエージェントホスト側でちゃんと実行されていた。そこで「エージェントホストからジョブの終了通知が失敗」でググると下記が見つかった
上記サイトによると、ジョブ実行結果の詳細画面で「終了コード」が「-1」の場合は、JP1の設定や環境に起因する異常終了で、「-1」以外の場合は、実行しているアプリケーションが出力している終了コードになるらしい（この場合は終了コードを元にアプリケーション側のコードをご確認する必要がある）。
→やはり設定でやらかしてたみたいw
さらに上記サイトを読み進めると、マネージャホストとエージェントホスト双方に存在する「統合トレースログ」を見ると内容を把握できるらしい。
エージェントホストが終了通知に失敗してる臭いのでエージェントホスト側の統合トレースログを確認すると、
[root@centos7_2_local tmp]# tail -30 /var/opt/hitachi/HNTRLib2/spool/hntr22.log
0009 2021/12/08 16:42:16.618 jpqagtchild 00000D57 C2C238C0 KAVU2245-W TCP/IP通信で接続エラーが発生したためリトライします(接続先ホスト名:localhost,IPアドレス:127.0.0.1,ポート番号:20241,システムエラー番号:111)
0014 2021/12/08 16:42:26.926 jpqagt 00000D36 E5023700 KAVU2245-W TCP/IP通信で接続エラーが発生したためリトライします(接続先ホスト名:localhost,IPアドレス:127.0.0.1,ポート番号:20241,システムエラー番号:111)
0010 2021/12/08 16:42:36.621 jpqagtchild 00000D57 C2C238C0 KAVU2227-E TCP/IP通信で接続エラーが発生しました(接続先ホスト名:localhost,IPア ドレス:127.0.0.1,ポート番号:20241,システムエラー番号:111)
0011 2021/12/08 16:42:36.622 jpqagtchild 00000D57 C2C238C0 KAVU3530-W マネージャー(localhost)が停止もしくは障害が発生したと思われます
0015 2021/12/08 16:42:46.930 jpqagt 00000D36 E5023700 KAVU2227-E TCP/IP通信で接続エラーが発生しました(接続先ホスト名:localhost,IPア ドレス:127.0.0.1,ポート番号:20241,システムエラー番号:111)
0016 2021/12/08 16:42:46.930 jpqagt 00000D36 E5023700 KAVU3530-W マネージャー(localhost)が停止もしくは障害が発生したと思われます
----(略)----
→エージェントホスト側でマネージャホスト名を「localhost」と認識してる臭い（ペタワロス）
下記のサイトにjp1pingとかいうツールがあるらしい
エージェントホスト側からマネージャホスト側にjp1pingを打つと
[root@centos7_2_local opt]# ./jp1base/bin/jp1ping centos7_local
LogicalHostnameKey : no define. use JP1_DEFAULT
jp1hosts : no entry. extract hostlist is disabled.
Search jp1hosts : centos7_local is not found.
Resolved Host List : centos7_local -> centos7_local(192.168.72.3), centos7_local(192.168.101.3)
Check with ping command ---
PING 192.168.72.3 (192.168.72.3) 56(84) bytes of data.
64 bytes from 192.168.72.3: icmp_seq=1 ttl=64 time=0.374 ms
64 bytes from 192.168.72.3: icmp_seq=2 ttl=64 time=1.08 ms
64 bytes from 192.168.72.3: icmp_seq=3 ttl=64 time=0.916 ms
64 bytes from 192.168.72.3: icmp_seq=4 ttl=64 time=0.549 ms
--- 192.168.72.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3009ms
rtt min/avg/max/mdev = 0.374/0.729/1.080/0.283 ms
PING 192.168.101.3 (192.168.101.3) 56(84) bytes of data.
64 bytes from 192.168.101.3: icmp_seq=1 ttl=64 time=1.36 ms
64 bytes from 192.168.101.3: icmp_seq=2 ttl=64 time=0.377 ms
64 bytes from 192.168.101.3: icmp_seq=3 ttl=64 time=0.910 ms
64 bytes from 192.168.101.3: icmp_seq=4 ttl=64 time=0.999 ms
--- 192.168.101.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3007ms
rtt min/avg/max/mdev = 0.377/0.912/1.362/0.352 ms
→普通のpingだけ疎通した（/etc/hostsにはちゃんと書いたのｗ）どうやらJP1の設定的には、エージェントホストからマネージャホストのホスト名(centos7_local)は解決できてないらしいｗ
[root@centos7_2_local opt]# ./jp1base/bin/jbshosts2export -h centos7_local
KAVA0418-E 論理ホスト(centos7_local)が設定されていません
KAVA0444-E 共通定義アクセスでエラーが発生したため，jp1hosts2の出力に失敗しました
KAVA0435-E 処理が失敗しました
[root@centos7_2_local opt]# ./jp1base/bin/jbshostsexport -h centos7_local
KAVA0418-E 論理ホスト(centos7_local)が設定されていません
KAVA0417-E 共通定義アクセスでエラーが発生したため，jp1hostsの出力に失敗しました
KAVA0435-E 処理が失敗しました
[root@centos7_2_local opt]# ./jp1base/bin/jbshostsexport
KAVA0419-E jp1hostsが設定されていません
[root@centos7_2_local opt]# ./jp1base/bin/jbshosts2export
KAVA0470-I jp1hosts2が設定されていません
[root@centos7_2_local opt]# cat /etc/opt/jp1base/conf/jp1hosts2.conf
#
# jp1hosts2
#
# Hostname Internet Address # Comments
# samplehost 2001:db8::1 , 192.168.0.1 # Sample
[root@centos7_2_local opt]# cat /etc/opt/jp1base/conf/jp1hosts
#
# jp1hosts
#
# Hostname Internet Address # Comments
# samplehost 192.168.10.10 , 172.16.20.20 # Sample description
ちなみにマネージャホスト側で実行すると、
[root@centos7_local bin]# /opt/jp1base/bin/jbshosts2export
KAVA0470-I jp1hosts2が設定されていません
[root@centos7_local bin]# /opt/jp1base/bin/jbshostsexport
KAVA0419-E jp1hostsが設定されていません
[root@centos7_local bin]# cat /etc/opt/jp1base/conf/jp1hosts2.conf
#
# jp1hosts2
#
# Hostname Internet Address # Comments
# samplehost 2001:db8::1 , 192.168.0.1 # Sample
[root@centos7_local bin]# cat /etc/opt/jp1base/conf/jp1hosts
#
# jp1hosts
#
# Hostname Internet Address # Comments
# samplehost 192.168.10.10 , 172.16.20.20 # Sample description
下記に従ってjp1hosts情報を登録する
・マネージャホスト側
[root@centos7_local bin]# cp -p /etc/opt/jp1base/conf/jp1hosts{,bak}
[root@centos7_local bin]# vi /etc/opt/jp1base/conf/jp1hosts
[root@centos7_local bin]# diff /etc/opt/jp1base/conf/jp1hosts{,bak}
6,7d5
< centos7_local 192.168.72.3,192.168.101.3
< centos7_2_local 192.168.72.4,192.168.101.4
[root@centos7_local bin]# /opt/jp1base/bin/jbshostsimport -o /etc/opt/jp1base/conf/jp1hosts
KAVA0436-I 処理が成功しました
・エージェントホスト側
[root@centos7_2_local opt]# cp -p /etc/opt/jp1base/conf/jp1hosts{,bak}
[root@centos7_2_local opt]# vi /etc/opt/jp1base/conf/jp1hosts
[root@centos7_2_local opt]# diff /etc/opt/jp1base/conf/jp1hosts{,bak}
6,8d5
< centos7_local 192.168.72.3,192.168.101.3
< centos7_2_local 192.168.72.4,192.168.101.4
<
[root@centos7_2_local opt]# /opt/jp1base/bin/jbshostsimport -o /etc/opt/jp1base/conf/jp1hosts
KAVA0436-I 処理が成功しました
面倒くさいからマネージャホストとエージェントホストどっちもシステムリブート
やっとできた臭い
順番は逆になったがUNIX0、UNIX1、UNIX2の各ジョブは下記の通り
・UNIX0ジョブ
・UNIX1ジョブ
・UNIX2ジョブ
・マネージャホスト側ジョブスクリプトと実行結果
[root@centos7_local tmp]# cat /tmp/test0.sh
echo "This is test0" >> /tmp/hello0.txt
/usr/bin/sleep 20
[root@centos7_local tmp]# cat /tmp/hello0.txt
This is test0
・エージェントホスト側ジョブスクリプトと実行結果
[root@centos7_2_local tmp]# cat /tmp/test1.sh
echo "This is test1その1"
echo "This is test1その2"
#/usr/bin/sleep 3600
exit 0
[root@centos7_2_local tmp]# cat /tmp/test2.sh
#!/bin/bash
echo "This is test2" `/usr/bin/date "+%Y/%m/%d %H:%M:%S"`
/usr/bin/sleep 5
[root@centos7_2_local tmp]# cat /tmp/hello.txt
This is test1その1
This is test1その2
This is test2 2021/12/08 18:57:44