Github actions forces stdin through a fifo

[tymscar]

Description

When using GitHub actions, there is an ever-present fifo on stdin for the programs running there, and sometimes, that makes those programs misbehave because their heuristic tells them to use the empty fifo instead of the files in the current working directory.

Platforms affected

• [ ] Azure DevOps
• [X] GitHub Actions - Standard Runners
• [ ] GitHub Actions - Larger Runners

Runner images affected

• [X] Ubuntu 20.04
• [X] Ubuntu 22.04
• [X] Ubuntu 24.04
• [ ] macOS 12
• [ ] macOS 13
• [ ] macOS 13 Arm64
• [ ] macOS 14
• [ ] macOS 14 Arm64
• [ ] macOS 15
• [ ] macOS 15 Arm64
• [ ] Windows Server 2019
• [ ] Windows Server 2022

Image version and build link

I have recreated the simplest example of the bug happening, and you can see it in action here: https://github.com/tymscar/github-actions-test/actions/runs/11797546880/job/32861766821

The main line that is relevant to the discussion is on that page, part of the debug output of rg: rg: DEBUG|grep_cli|crates/cli/src/lib.rs:209: for heuristic stdin detection on Unix, found that is_file=false, is_fifo=true and is_socket=false, and thus concluded that is_stdin_readable=true

This has been reported to ripgrep too, and it was suggested that it's a GHA problem, after which I tried to replicate it as lean as possible.

Is it regression?

no

Expected behavior

When running a binary such as rg "hello" in GitHub Actions, I expect it to search for the string in the local files.

Actual behavior

In actuality, there is an ever-present empty fifo that tricks the heuristic of ripgrep (and other binaries) into thinking it should look at stdin instead of the default behavior.

Repro steps

Run any binary that has a heuristic about when to use stdin vs local files, such as ripgrep, and if it's not told explicitly to search for local files, it will default to the empty fifo. The best example is ripgrep, because when run with debug like rg --debug "hello" it will print that it found an open fifo on stdin from GitHub Actions. Locally on another machine, or in a vm, there is no present fifo, just in GHA.

[vidyasagarnimmagaddi]

Hi @tymscar

We have observed the issue.

The command rg --debug "Hello"failed as ripgrep don't have a file or input stream to search. Kindly trying using

      - name: Run ripgrep without specifying a file (will fail, so debug)
        run: rg --debug "Hello" hello.txt

Thanks.

[tymscar]

Yes, that fixes the ripgrep example, but not the overall issue. Why is there an open fifo? In some binaries, you can't force it not to take the fifo into account.

[vidyasagarnimmagaddi]

Hi @tymscar , Will into in it and provide our inputs, thanks

[tymscar]

Thank you!

[vidyasagarnimmagaddi]

Hi @tymscar

name:  ripgrep in gha

on: push
jobs:
  testing-ripgrep:
    runs-on: ubuntu-latest
    steps:
      - name: Redirect stdin to /dev/null globally to prevent FIFO issues
        run: |
          exec 0</dev/null  # Redirect stdin globally
      - name: Install latest ripgrep in gha
        run: |
          wget https://github.com/BurntSushi/ripgrep/releases/download/14.1.1/ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz
          tar -xvf ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz
          sudo mv ripgrep-14.1.1-x86_64-unknown-linux-musl/rg /usr/local/bin
          rg --version
      - name: Run ripgrep on stdinput
        run: echo "Hello, world!" | rg "Hello"

      - name: Create a file with a message
        run: echo "Hello, world!" > hello.txt

      - name: Run ripgrep on a file
        run: rg "Hello" hello.txt  

      - name: Run ripgrep with no file, explicitly searching current directory
        run: rg --debug "Hello" .  # Explicitly search the current directory to prevent stdin read

      - name: Run ripgrep without specifying a file (debug)
        run: rg --debug "Hello" .  # Adding a directory search prevents stdin read   

I used the above logic and it worked for me ripgrep has built-in heuristics taking input source depending on how it's called . By explicitly specifying the search path "." , by heuristics and ensuring the tool behaves as expected, directly searching files in the current directory.

[tymscar]

Indeed, @vidyasagarnimmagaddi, I am aware of this. You had previously mentioned this in your previous comment, but addressing only the symptom does not resolve the underlying issue.

The reason the heuristics fail is because there is a persistently open FIFO on GitHub Actions that should not exist, as far as my understanding goes. The reason for its presence remains unclear, and this is the critical aspect that requires further investigation.

[vidyasagarnimmagaddi]

Indeed, @vidyasagarnimmagaddi, I am aware of this. You had previously mentioned this in your previous comment, but addressing only the symptom does not resolve the underlying issue.

The reason the heuristics fail is because there is a persistently open FIFO on GitHub Actions that should not exist, as far as my understanding goes. The reason for its presence remains unclear, and this is the critical aspect that requires further investigation.

Hi @tymscar , Will redo my analysis and revert you back .Thanks

[tymscar]

Hey @vidyasagarnimmagaddi, any news on this? Thanks!

[vidyasagarnimmagaddi]

Hi @tymscar In our runner environment, stdin is set up as a FIFO (First In, First Out) pipe. As a result, if no arguments are passed to ripgrep (rg), hence it attempts to read from stdin, which fails because it's expecting data from the pipe. The runner script is intentionally configuring stdin as a FIFO for automated input handling.

To resolve this issue, we recommend the user explicitly pass a search term and a directory (e.g., rg "hello" ./). Specifying ./ ensures that ripgrep operates with a valid directory, bypassing the issue related to reading from stdin.

[tymscar]

Thank you. Do you have the sourcecode where this is defined? I would like to look more into it.

[vidyasagarnimmagaddi]

Hi @tymscar , In our images , we are not instrumenting the stdin. kindly check with the https://github.com/actions/runner team. Thanks closing the issue.