Skip to content

Conversation

@vtrenton
Copy link

Hey Github Runner team!

I felt the need to open this PR as to at least have a discussion around this. safe_sleep has created serious problems in the past with wasting CPU cycles using #3792 as reference. The codebase keeps getting bigger with hacks like using ping as a timer... Which is great except it relies heavily on the assumption that ping on all systems will never change it send frequency (unlikely - but there is a potential).

There is also an existing concern about the latest fix being vulnerable to injection attacks. Although not likely exploitable - it's new risk introduced into the codebase: #3792 (comment)

There is no need for this as almost zero UNIX-Like systems including containers and Android/Embedded systems don't have sleep. Sleep is a standard POSIX utility on all UNIX systems.

To top it off these scripts require BASH which is installed on less systems than sleep. Let alone hardcoding the shebang path to /bin/bash which systems such as Nix and BSD do not use. BASH is much larger compatibility risk than sleep.

if you're making bash (a much less deployed tool) a hard requirement than sleep should be.

All of this is to say - we should remove safe_sleep from the codebase and just use/assume a POSIX sleep implementation is available. This is technical debt and the implementation costs much more than its worth.

I would like to challenge anyone to give me an example of a UNIX-Like system that uses BASH that doesn't have sleep. Very open to being challenged on this. I seriously for the life of me can think of a single one. Would love to hear any feedback on this!

Thank you for your consideration!

Signed-off-by: Trenton VanderWert <trenton.vanderwert@gmail.com>
@vtrenton vtrenton requested a review from a team as a code owner December 12, 2025 22:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant