I see. I did not realize SECONDS was a built in bash variable.

It is still not a proper fix. It is still busy-looping 100% CPU.

Given that Github Actions is quite popular, probably wasting large amount of energy.

But probably good at generating billable Actions minutes.

One can only hope that not many people use sleeps to handle their CI race conditions, as that itself is also not a proper fix.

Clearly the job for a microservice. Accept number of seconds to wait as url, return content after that many seconds. Then just use curl in runner.

Brb founding a SaaS startup. I’ll call it cloudsleep dot io of course. After our Series B I’ll buy the .com.

Only task to do before lining up investors is how can I weave AI into our product?

Describe the task you're waiting for as text, and let an LLM pick the number of seconds for each request. More expensive the better model you clearly need for this. There, your AI pitch.

Excellent, welcome aboard, Chief Product Officer!

Retries won’t work in that case. Would be better to have two endpoints: get the time in x seconds and wait until time passed. That way retrying the wait endpoint will work fine and if time hasn’t elapsed it can just curl itself with the same arguments.

If you have curl (but not sleep) sure, but if not maybe you can use bash's wacky /dev/tcp. The microservice could listen on ports 1 through 64k to let you specify how many seconds to sleep.

Yeah, definitely not a proper fix.

Maybe a more serious fix is something like "read -t $N". If you think stdin might not be usable (like maybe it will close prematurely) this option won't work, but maybe you can open an anonymous FD and read from it instead.

    while wait && [[ $SECONDS -lt $1 ]]; do
      read -t $(($1 - SECONDS))
    done <><(:)

although if you're not too concerned about finishing early if a signal interrupts, probably

    { wait; read -t $1; } <><(:)

would be fine. You want the wait because otherwise bash won't reap the zombie from the process substitution until after the read times out.

Interestingly, it does reap on a blocked read without -t, so potentially the behaviour on -t would be considered a bug rather than as-designed.

There's also a loadable sleep builtin supplied with bash which calls into the internal fsleep() so should be reliable and without forking.

It's just all hacks. It should use `sleep`, period.

Sleeping is an OS scheduling task. Use the OS syscall that does that.

As is suggested on the Github issue that Microsoft has been ignoring for half a year.

Me neither. I am over 40 and did not know this. Feels good to learn something today, in an unexpected place!