5 is an odd requirement potentially better implemented outside cron, such as with a single line of shell code involving the "at" command (and "expr" to scale a /dev/random value).
4, 6, 7 gets you into "enterprise" (not the StarTrek thing;) territory. Think about it: how to represent that a job has or hasn't finished successfully? Using a process return status, or maybe something more persistent, restartable, or federated and independent of a PID eg. a state stored in a database, which involves further design trade offs such as transactional isolation, locking, eventual consistency, etc.
> 5 is an odd requirement potentially better implemented outside cron, such as with a single line of shell code involving the "at" command (and "expr" to scale a /dev/random value).
I'm very surprised you think that. I would say that the job scheduler is the perfect place to randomize start times.
If it's a one-off then you rarely need randomization. For scheduled tasks, you often want randomization so that your fleet of servers is not all doing the task at the exact same time. Think "start between 2am and 4am every day".
You can work around it by picking an offset at install time like scheduling for 3:17am in particular on this server, or by putting a random sleep into the job, but both of those obfuscate the actual scheduling intent.
4, 6, 7 gets you into "enterprise" (not the StarTrek thing;) territory. Think about it: how to represent that a job has or hasn't finished successfully? Using a process return status, or maybe something more persistent, restartable, or federated and independent of a PID eg. a state stored in a database, which involves further design trade offs such as transactional isolation, locking, eventual consistency, etc.