Ansibleが理解できない理由はLinuxにあった【Shell編】第3回：なぜgrepで見つからないのか（stdin）

📚 連載：Ansibleが理解できない理由はLinuxにあった【Shell編】第3回：なぜgrepで見つからないのか（stdin）

※Shellの仕組みからAnsibleを理解するシリーズです。

① なぜShellを理解しないとAnsibleは使えないのか
② なぜAnsibleで出力が取得できないのか
③ なぜ結果が消えるのか
④ なぜgrepで見つからないのか
⑤ なぜ正規表現で壊れるのか
⑥ なぜ環境が違うのか
⑦ なぜ条件分岐が失敗するのか
⑧ なぜループがうまく動かないのか
⑨ なぜ途中で処理が止まるのか
⑩ なぜ変数が意図通りに展開されないのか
⑪ なぜAnsibleの挙動が読めるようになるのか

---

🗺️ 初めての方・シリーズの全体像を知りたい方はこちら

本記事は、OSの仕組みからAnsible設計までを繋ぐ連載シリーズの一部です。
「どこから読み始めればいいか」あるいは、「OS/Shell/Ansible編の関係性」 について把握されたい場合は、以下の統合ガイドで整理しています。

→ Ansibleが理解できない理由はLinuxにあった｜統合ガイド

---

📑 【Shell編】全体のまとめはこちら
→ Ansibleが理解できない理由はLinuxにあった【Shell編】まとめ

---

📑 連載の移動
前の記事：【Shell編】第2回 ｜ 次の記事：【Shell編】第4回

---

📋 目次

1. 前回の振り返り（第2回）
2. 逆引き辞典との連動
3. Shellの入力構造：データ読み込み元の決定
4. なぜ見つからないのか：入力源判定の「2つのステップ」
5. 観測方法：コマンドが「何を待っているか」を特定する
6. 【実機検証】入力源の決定プロセス：引数と標準入力の優先順位
   
7. まとめ：入力ソースの判定に基づくトラブルシューティング
8. 次回予告
9. 連載一覧：Ansibleが理解できない理由はLinuxにあった【Shell編】

---

※本記事の位置とシリーズ全体の関係を先に確認します。

---

シリーズ全体構造（学習 × 問題解決）

本シリーズは
「理解（各記事）」と「問題解決（逆引き辞典）」を組み合わせて
スキルを身につける構成になっています。

この図は、どこから学び、どこに進めばよいかを示した“ロードマップ”です。

---

📍 現在の位置

---

現在はこの図の「Shell編の第3回」になります

↑ 目次に戻る

---

📍 はじめに：この記事のスタンス

第1回で「出口（stdout/stderr）」を、第2回で「転送（Pipe/Redirect）」を学びました。これにより、コマンドが生成したデータの流路を把握できるようになりました。

しかし、実務では依然として以下の現象が発生します。

• 「ファイル内に確実に文字列が存在するが、grepで抽出できない」

• 「手動実行では成功する処理が、Ansible経由では意図した結果を返さない」

• 「タスクが応答待ちの状態で停止し、最終的にタイムアウトする」

これらの要因は、コマンドの実行時にOSがどのようにデータを読み込むかという、「入力ソース（引数・標準入力）」 の判定ロジックにあります。

---

⚠️ 注意事項

この記事の目的は、標準入力の定義を解説することではありません。
「OSがどの経路からデータを読み込もうとしているのか」を特定し、トラブルを解決することに主眼を置いています。

---

「データは存在するが、プロセスに読み込まれていない」

この課題を解決するために、Linuxにおける入力ソースの選択ルールと、Ansible実行時に発生するプロセスの停滞メカニズムを整理します。

---

1. 前回の振り返り（第2回）

前回は、コマンドが出力したデータがパイプやリダイレクトによって「どのデバイスやファイルへ転送されるか」を整理しました。

今回は、視点を出力から入力へと切り替え、コマンドが処理を開始する際に必要なデータを「どのソースから読み込んでいるのか」、その判定ロジックについて解説します。

---

↑ 目次に戻る

---

2. 逆引き辞典との連動

具体的なエラー名から原因を特定したい場合は、以下の逆引き辞典を活用してください。

【保存版】Ansibleよくあるエラー一覧と原因まとめ（Shell編）

• まず「逆引き辞典」で該当ステップを特定する
• 次に「本編（各連載記事）」で仕組みを理解する

このサイクルが、OS編から続くトラブル解決の最短ルートです。

---

↑ 目次に戻る

---

3. Shellの入力構造：データ読み込み元の決定

Shellでは、コマンドはデータを処理する前に「どこから入力を受け取るか」を決定します。

この入力元は内部的に分離されており、指定方法によって読み込まれる対象が変わります。

入力の種類	実務での記述	特徴
引数 (Argument)	grep "word" file.txt	コマンドの直後に「ファイル名」を直接指定する
標準入力 (stdin)	cat file.txt | grep "word"	前のプロセスから流れてくるデータを受け取る
リダイレクト入力	grep "word" < file.txt	ファイルの内容を入り口に直接流し込む

多くのコマンドは「引数」が指定されると「標準入力」を無視します。

---

↑ 目次に戻る

---

4. なぜ見つからないのか：入力源判定の「2つのステップ」

コマンド（特にgrepやawkなど）は、以下の優先順位で「どこからデータを読むか」を判定します。

この優先順位を誤解していると、「データはあるはずなのに検索に引っかからない」という事態が発生します。

---

入力源判定ロジック

ステップ	判定内容	到達しない（失敗する）理由
Step 1: 引数確認	ファイル名が指定されているか？	指定があると、パイプからのデータは読み込まれない
Step 2: stdin確認	パイプ等からデータが流れているか？	流れがない場合、キーボード入力を待ち続けて停止する

---

【入力判定フロー】

---

結論：

grep等のコマンドで意図した結果が得られない場合、その原因は必ずしも「検索文字列のミス」にあるとは限りません。むしろ、OSがどの読み込み先（Step）を優先して選択したか、引数とパイプを両方書いていないかを確認すべきです。

---

↑ 目次に戻る

---

5. 観測方法：コマンドが「何を待っているか」を特定する

検索の失敗や処理の停止が発生した際は、その状態から「コマンドが現在、どの入力ソース（引数または標準入力）を選択しているか」を特定します。

特にAnsibleでは、以下の観点で確認します。

• タスクが終了しているか（ハングしていないか）
• stdout / stderr に何が出ているか
• 実行コマンドに引数（ファイル名）が含まれているか

---

状態からStepを逆引きする

現象	判定されるStep	状態の解釈
エラー：No such file	Step 1 (Argument)	引数で渡したパスが間違っている
ヒット件数 0	Step 1 (Argument)	指定したファイルの中身が空、または意図しないファイルを読んでいる
タスクがタイムアウト	Step 2 (stdin)	入力が届かず、OSが「次のデータ」を待ち続けている

「ファイル名を指定したのに、パイプでも渡している」場合、パイプ側は捨てられます。

Ansibleによる実行では、コマンドが要求する入力を動的に供給する手段がないため、「入力待ち」が発生したタスクはハング状態となり、最終的にタイムアウトします。

---

↑ 目次に戻る

---

6. 【実機検証】入力源の決定プロセス：引数と標準入力の優先順位

セクション4で解説した「入力源判定ロジック」が、実際のAnsible実行においてどのようにデータの読み込み先を決定し、あるいは処理を停止させるのか。その挙動を確認します。

6-1. 【検証1】引数による標準入力（パイプ）の無視（Step 1の優先）

パイプでデータを渡しているにもかかわらず、コマンドに引数（ファイル名）を与えた場合、どちらのデータが処理対象になるのかを観測します。

① 検証手順（リモートノード側）

検証用のファイルを作成し、パイプから渡す文字列とファイル内の文字列をあえて別に用意します。

# 検証用ファイルの作成
[ansibleuser@localhost ~]$ echo "DATA_FROM_FILE" > /tmp/test_input.txt

② Ansibleによる実行テスト

実行するPlaybook (case1_stdin_priority.yml)

---
- name: 検証1 引数と標準入力の優先順位
  hosts: test_servers
  gather_facts: false
  tasks:
    - name: パイプでデータを渡しつつ引数でファイルを指定
      ansible.builtin.shell: "echo 'DATA_FROM_PIPE' | grep 'DATA' /tmp/test_input.txt"
      register: res_priority

    - name: 変数の中身を確認
      ansible.builtin.debug:
        msg: "取得されたデータ: {{ res_priority.stdout }}"

実行コマンド

ansible-playbook -i inventory.ini case1_stdin_priority.yml

③ 検証結果

(ansible) [root@localhost workspace]# ansible-playbook -i inventory.ini case1_stdin_priority.yml

PLAY [検証1 引数と標準入力の優先順位] *******************************************************************************************************************************************************

TASK [パイプでデータを渡しつつ引数でファイルを指定] *****************************************************************************************************************************************
changed: [192.168.1.21]

TASK [変数の中身を確認] *********************************************************************************************************************************************************************
ok: [192.168.1.21] => {
    "msg": "取得されたデータ: DATA_FROM_FILE"
}

PLAY RECAP **********************************************************************************************************************************************************************************
192.168.1.21               : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

ログの読み解きと考察

• 現象： echo で渡した DATA_FROM_PIPE は無視され、ファイルの中身である DATA_FROM_FILE だけがヒットしています。

• 理由： OSがコマンドを実行する際、Step 1（引数の確認） においてファイル名 /tmp/test_input.txt を検知したためです。この判定が下されると、パイプから届いている標準入力のストリームは読み込まれずに破棄されます。

テスト結果のまとめ：

引数と標準入力が同時に指定された場合、OSは Step 1（引数） を優先して実行します。この判定ロジックにより、標準入力（パイプ）からのデータストリームはプロセスに読み込まれず、引数で指定されたファイルオブジェクトのみが処理対象となります。

---

6-2. 【検証2】入力待ちによるタスクの停止（Step 2の空振り）

引数（ファイル名）もパイプ（標準入力）も存在しない状態で、OSが入力を待ち続ける「待機状態」を再現します。

① 検証手順（リモートノード側）

通常、引数なしで grep を実行すると、OSは標準入力（キーボード等）からのデータ提供を待ち続けます。この状態をAnsible経由で実行し、タスクの挙動を観測します。

② Ansibleによる実行テスト

実行するPlaybook (case2_hang_test.yml)

---
- name: 検証2 入力待ちによるハングの再現
  hosts: test_servers
  gather_facts: false
  tasks:
    - name: 引数もパイプもなしでgrepを実行
      # 検索語のみ指定し、入力元を指定しない
      ansible.builtin.shell: "grep 'search_word'"
      # 10秒でタイムアウトさせる設定
      vars:
        ansible_command_timeout: 10
      register: res_hang

    - name: 変数の中身を確認
      ansible.builtin.debug:
        var: res_hang

Playbook (case2_hang_test.yml)の補足
「ansible_command_timeout」コマンドはAnsible 2.10以降で有効な変数ですが、Ansibleのバージョンによっては動作しない場合があります。
もし動作しない場合は代替え案として以下のコマンドを試してみてください。

ansible.builtin.shell: "timeout 10 grep 'search_word'"

実行コマンド

ansible-playbook -i inventory.ini case2_hang_test.yml

③ 検証結果

(ansible) [root@localhost workspace]# ansible-playbook -i inventory.ini case2_hang_test.yml

PLAY [検証2 入力待ちによるハングの再現] *****************************************************************************************************************************************************

TASK [引数もパイプもなしでgrepを実行] *******************************************************************************************************************************************************

※上記の通り「ハング状態」

ログの読み解きと考察

• 現象： タスクが 引数もパイプもなしでgrepを実行 の表示から進まず、応答を停止しました。

• 理由： Step 2（stdin確認） において、引数によるファイル指定がなく、かつパイプ等からのデータ流入も検知できないため、OSが標準入力（キーボード等）からのデータ供給を待機する状態に移行したためです。自動実行環境であるAnsibleでは、対話的な入力を行うことができないため、この待機プロセスを完了させることができず処理が停滞します。

テスト結果のまとめ：

コマンドに対して「処理対象（引数）」と「ストリーム（標準入力）」のいずれも与えなかった場合、OSは Step 2 で入力待ちの状態を維持します。Ansible実行において、特定のタスクで処理が長時間停止し、最終的にタイムアウトが発生する原因は、この入力待ちに起因するプロセスの停滞によるものです。

---

↑ 目次に戻る

---

7. まとめ：入力ソースの判定に基づくトラブルシューティング

Ansible実行時において出力が得られない、あるいは処理が停滞するといった事象が発生した際は、以下の判定ステップに従って切り分けを行います。

【入力エラーの確認手順】

1. 引数（Step 1）の有無を確認する
   ・コマンドの引数にファイル名が指定されている場合、処理対象はそのファイルのみに限定されます。
   ・このとき、パイプから渡された標準入力の内容は処理されません。

2. 標準入力（Step 2）への流入を確認する
   ・引数がない場合、前段のコマンドから期待通りのデータストリームが流れているかを確認します。
   ・前段のコマンドが失敗、あるいは出力を生成していない場合、後続のコマンドは空のデータを処理することになります。

3. 入力待ち状態の有無を確認する
   ・引数も標準入力も存在しない場合、コマンドが対話的な入力を要求していないかを確認します。

---

【入力ソースの判定ルール】

入力に関する問題は、検索ワードを疑う前に、まずどこから読んでいるかを確認する。実行結果から、OSがどのステップで入力を決定したかを特定することが解決の最短ルートです。

• 引数がある場合：Step 1（ファイル読み込み）が実行される

• 引数がなく、ストリームがある場合：Step 2（標準入力の読み込み）が実行される

• いずれもない場合：待機状態（Ansibleではハング）となる

これまで解説した「入口（第3回）」・「出口（第1回）」・「転送（第2回）」この3点を押さえれば、Shellのデータの流れはほぼ全部説明できます。

---

↑ 目次に戻る

---

8. 次回予告

ここまでで「入力・出力・転送」というShellの基本3要素を整理しました。これにより、システム内におけるデータの物理的な移動経路を制御し、観測することが可能になりました。

• スペースの有無によってコマンドがエラーになる

• 変数が期待通りに展開されず、リテラル（文字列そのまま）として評価される

これらの事象は、OSによる「クォートの評価」や「正規表現の展開ルール」の理解によって解消されます。

次回：

【Shell編】第4回：なぜ正規表現で壊れるのか

記述した文字列がOS側でどのように解釈・変換されるのか、その評価プロセスを明確にします。

---

↑ 目次に戻る

---

📑 連載の移動
前の記事：【Shell編】第2回 ｜ 次の記事：【Shell編】第4回

---

🗺️ 初めての方・シリーズの全体像を知りたい方はこちら

本記事は、OSの仕組みからAnsible設計までを繋ぐ連載シリーズの一部です。
「どこから読み始めればいいか」あるいは、「OS/Shell/Ansible編の関係性」 について把握されたい場合は、以下の統合ガイドで整理しています。

→ Ansibleが理解できない理由はLinuxにあった｜統合ガイド

---

9. 連載一覧：Ansibleが理解できない理由はLinuxにあった【Shell編】

回数とタイトル	内容（概要）
【Shell編】第0回：なぜShellを理解しないとAnsibleは使えないのか	AnsibleはShellを通してコマンドを実行している。Ansible → SSH → Shell → Linux の構造を理解し、なぜShell理解が必須なのかを整理する。
【Shell編】第1回：なぜAnsibleで出力が取得できないのか	Ansibleでregisterが空になる・エラーが見えない原因はstdout / stderrの違いにある。Shellの出力構造を理解することで原因を特定できる。
【Shell編】第2回：なぜ結果が消えるのか	Ansibleで実行結果が見えなくなる原因はパイプ・リダイレクトによる出力先の変化にある。どこに出力が流れたのかを追うことで原因を特定できる。
【Shell編】第3回：なぜgrepで見つからないのか	Ansibleでgrepがヒットしない原因は検索対象ではなく入力（stdin）の問題にある。Shellの入力（ストリーム）構造を理解することで原因を特定できる。
【Shell編】第4回：なぜ正規表現で壊れるのか	Ansibleで検索や置換が壊れる原因は正規表現の評価ルールにある。文字列ではなくルールとして解釈される仕組みを理解し、リテラルの境界を学ぶ。
【Shell編】第5回：なぜ環境が違うのか	手動では動くのにAnsibleで失敗する原因は実行環境（PATH・環境変数）の差分にある。Shellの実行コンテキストの違いを理解し、環境を制御する。
【Shell編】第6回：なぜ条件分岐が失敗するのか	Ansibleのwhen条件が意図通りに動かない原因はexit codeにある。Shellの終了ステータスの判定ロジックを理解することで、正しく条件を組める。
【Shell編】第7回：なぜループがうまく動かないのか	Ansibleで繰り返し処理が期待通り動かない原因はShellのループと入力・サブシェルの干渉にある。データの扱い方を理解し、ループを安定させる。
【Shell編】第8回：なぜ途中で処理が止まるのか	Ansible実行中に意図せず処理が止まる原因はShellのエラーハンドリング（set -e 等）にある。エラー伝播の仕組みを理解し、停止条件を制御する。
【Shell編】第9回：なぜ変数が意図通りに展開されないのか	Ansibleで変数が空になる・壊れる原因はShellのクォートと展開順序にある。値の保護と展開のルールを理解し、安定したコマンドを記述する。
【Shell編】第10回：なぜ値が分割されてしまうのか	スペースや改行で意図せず値が壊れる原因はShellの単語分割（word splitting）にある。IFSなどの内部処理の本質を理解し、データの整合性を守る。
【Shell編】第11回：なぜAnsibleの挙動が読めるようになるのか	これまでの知識を統合し、AnsibleのエラーをShellの実行プロセスから逆算して分解できるようになる。実務で使える“読み方”を完成させる。

---

↑ 目次に戻る