I'm looking for a standalone command that runs another program immediately when started, waits for a configurable delay after it exits, and then repeats indefinitely. For example: `recur --every 25m -- my-command --with=args`.
This is intended for containers where systemd timers are unavailable or undesirable, usually alongside a process manager such as supervisord. The interval should be measured from the previous run rather than aligned to wall-clock boundaries, so a 25-minute interval remains consistent regardless of when the container starts. It would also be useful for the wrapper to forward signals, preserve stdout and stderr, return the child command's exit status, and avoid requiring a shell script for every use case.
Cron and similar schedulers are workable but use calendar-based timing, while `at` requires its own daemon and self-rescheduling is cumbersome. A simple shell loop using `sleep` works too, but handling signals and child-process cleanup adds boilerplate. Does an existing small, portable utility provide this behavior, or is writing a custom wrapper the practical solution?
4 Answers
`at` can schedule a command relative to the current time, so a script can run the job and submit itself again for, say, 25 minutes later. That gives you elapsed-time scheduling rather than cron’s calendar alignment. The downside is that `at` depends on an `atd` daemon, and self-rescheduling makes lifecycle management and user separation less clean when a process supervisor is already in charge.
The simplest solution is usually a small supervisor-managed loop: run the command, check its exit status, sleep for the configured interval, and repeat. In a container, supervisord can run it as the correct user, restart it when needed, and collect its output. A command such as `sh -c 'my-command && sleep 25m'` is often enough when the task should wait after a successful run. If signal handling during the command matters, a short wrapper that traps and forwards signals is safer than relying entirely on the shell.
Cron is a poor fit when the interval is user-configurable and should start at service startup. A 25-minute cron schedule eventually runs on wall-clock boundaries rather than 25 minutes after the previous invocation, and it doesn’t naturally behave like a supervised foreground process with signal forwarding and captured output. If no existing utility matches those requirements, a small purpose-built program in Python, Rust, or another language is probably the cleanest long-term answer.
There are small tools in this space, such as `snooze`, but they generally solve only part of the problem. Depending on the options, they either wait before launching a command or rely on a supervisor to restart them. Time-file support can be useful for persistent scheduling, but it also means managing one file per job and updating its timestamp. For a container-local task that should run immediately and then repeat after completion, it may not be simpler than a loop.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures