sleepPause for a set time (retries, polling, containers)
sleep pauses for a number of seconds, minutes, hours or days, then exits 0. In DevOps scripts it's the delay in retry loops and polling, the back-off between health checks, and 'sleep infinity' keeps debug containers alive.
sleep NUMBER[SUFFIX]... (suffix s, m, h or d; decimals allowed; 'infinity')Learn what sleep accepts and how it reports errors, before you rely on it in scripts.
untilShell loop: repeat the body until the test command succeeds (exit 0).
GNU sleep parses each argument as a floating-point number with an optional unit (s, m, h, d), adds them up, so 'sleep 1m 30s' is 90 seconds, and calls clock_nanosleep once. The process moves to state S (interruptible sleep) on a kernel timer and uses no CPU at all; the scheduler doesn't touch it until the timer fires. It's not busy-waiting. A signal interrupts the sleep: SIGTERM or Ctrl+C (SIGINT) ends it, with exit status 143 or 130 as reported by the shell. 'sleep infinity' calls pause() and waits for a signal forever, which is why it's the standard way to keep a container running for debugging. Precision is the timer granularity plus scheduling delay, usually well under a millisecond, but sleep only guarantees 'at least' that long. Many shells don't have it built in (bash doesn't by default), so each sleep forks and execs /usr/bin/sleep.
N or NsN seconds (decimals ok: 0.5)Nm / Nh / NdMinutes / hours / daysA B ...Several values are added: sleep 1m 30s = 90 secondsinfinitySleep until killed (keeps containers alive)timeout DUR cmdThe opposite tool: kill cmd if it runs longer than DUR (exit 124)while ! curl -s localhost:8080; do :; doneWithout a sleep the loop spins as fast as it can, eating a CPU core and hammering the service.
until curl -sf localhost:8080/health; do sleep 2; donesleep 30 in a deploy script to 'wait for the app'Too short on a slow day, wasted time on a fast one. A fixed sleep is a guess.
Poll the real condition (health endpoint, port open) with a bounded retry loopsleep 5min or sleep 2 minutesGNU sleep only knows the suffixes s, m, h and d.
sleep 5m # or sleep 300CMD ["sleep", "infinity"] as the main process and expecting a fast docker stopPID 1 ignores SIGTERM unless it installs a handler, so every stop waits for the 10 s timeout.
docker run --init ... sleep infinityTry these on a Linux machine of your own. Each task has a hint and a solution.
Time 'sleep 0.5' and note how much CPU it used.
Write a loop that checks for /tmp/ready every second, gives up after 10 tries, and prints 'ready' or 'timeout'. Test it by creating the file from another command.
Start 'sleep 300' in the background, look at its state with ps, then kill it and print the exit code.
Run 'sleep 10' but give up after 3 seconds, and print the exit code.
sleepPause for a set time (retries, polling, containers)
sleep pauses for a number of seconds, minutes, hours or days, then exits 0. In DevOps scripts it's the delay in retry loops and polling, the back-off between health checks, and 'sleep infinity' keeps debug containers alive.
sleep NUMBER[SUFFIX]... (suffix s, m, h or d; decimals allowed; 'infinity')Learn what sleep accepts and how it reports errors, before you rely on it in scripts.
untilShell loop: repeat the body until the test command succeeds (exit 0).
GNU sleep parses each argument as a floating-point number with an optional unit (s, m, h, d), adds them up, so 'sleep 1m 30s' is 90 seconds, and calls clock_nanosleep once. The process moves to state S (interruptible sleep) on a kernel timer and uses no CPU at all; the scheduler doesn't touch it until the timer fires. It's not busy-waiting. A signal interrupts the sleep: SIGTERM or Ctrl+C (SIGINT) ends it, with exit status 143 or 130 as reported by the shell. 'sleep infinity' calls pause() and waits for a signal forever, which is why it's the standard way to keep a container running for debugging. Precision is the timer granularity plus scheduling delay, usually well under a millisecond, but sleep only guarantees 'at least' that long. Many shells don't have it built in (bash doesn't by default), so each sleep forks and execs /usr/bin/sleep.
N or NsN seconds (decimals ok: 0.5)Nm / Nh / NdMinutes / hours / daysA B ...Several values are added: sleep 1m 30s = 90 secondsinfinitySleep until killed (keeps containers alive)timeout DUR cmdThe opposite tool: kill cmd if it runs longer than DUR (exit 124)while ! curl -s localhost:8080; do :; doneWithout a sleep the loop spins as fast as it can, eating a CPU core and hammering the service.
until curl -sf localhost:8080/health; do sleep 2; donesleep 30 in a deploy script to 'wait for the app'Too short on a slow day, wasted time on a fast one. A fixed sleep is a guess.
Poll the real condition (health endpoint, port open) with a bounded retry loopsleep 5min or sleep 2 minutesGNU sleep only knows the suffixes s, m, h and d.
sleep 5m # or sleep 300CMD ["sleep", "infinity"] as the main process and expecting a fast docker stopPID 1 ignores SIGTERM unless it installs a handler, so every stop waits for the 10 s timeout.
docker run --init ... sleep infinityTry these on a Linux machine of your own. Each task has a hint and a solution.
Time 'sleep 0.5' and note how much CPU it used.
Write a loop that checks for /tmp/ready every second, gives up after 10 tries, and prints 'ready' or 'timeout'. Test it by creating the file from another command.
Start 'sleep 300' in the background, look at its state with ps, then kill it and print the exit code.
Run 'sleep 10' but give up after 3 seconds, and print the exit code.