Intermittent GLIBC errors on self-hosted Ubuntu 22.04 runners across multiple architectures and Python versions

[anamargfer]

Description:
We're experiencing intermittent GLIBC-related failures when using actions/setup-python on our self-hosted Ubuntu 22.04 runners. The issue is non-deterministic - the same Python version that works in one workflow run will fail in another run on the same day with the same configuration.

Action version:
It happens with all versions, but we are using v6.

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
All Python versions, it depends on the run.

Repro steps:

1. Cache some python versions on self-hosted runners
2. Run workflow with

- name: Set up Python
uses: actions/setup-python@v6
with:
python-version: '3.14.1' //This is only an example version

3. Execute Python

Expected behavior:

• setup-python should validate that cached Python binaries are compatible with the host system's GLIBC version. If a cached binary is incompatible, the action should download a compatible version.
• All runners with the same OS should consistently succeed or fail, not intermittently

Actual behavior:

• setup-python finds Python in tool-cache and reports success
• No GLIBC compatibility check is performed
• Workflow proceeds to use Python
• Python execution fails with GLIBC version mismatch

Error Message - Example:

python3: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by /etc/gha/_work/_tool/Python/3.13.10/x64/lib/libpython3.13.so.1.0)
python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /etc/gha/_work/_tool/Python/3.13.10/x64/lib/libpython3.13.so.1.0)

[anamargfer]

The attached screenshot shows a workflow run that failed 11 hours ago using the same cached Python version

Earlier that same day, identical workflows with the same cached Python version succeeded.

This demonstrates that:

• The same runner with the same cached Python exhibits both success and failure
• The issue is not simply about different runners having different cached versions
• Something changes in the runtime environment that causes the same cached Python binary to work at one point and fail minutes later
• The failures are truly non-deterministic and time-dependent, making them extremely difficult to debug or reproduce consistently

[mahabaleshwars]

Hi @anamargfer,
Thank you for creating this issue. We will investigate it and provide feedback as soon as we have some updates.

[anamargfer]

Hi @mahabaleshwars
We've noticed we were facing the same problem related in 1087. It would be great if you can implement some solution for that.
Thank you!