Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am unhappy with cron on linux.

  • Load peaks: @hourly jobs create load peaks. I want a random offset (per job).
  • high load: skip some jobs: If the load is too high, I want to skip some jobs.

I could solve this with shell scripts wrappers, but that is "dirty".

Up to now, I use the default vixie cron.

How do you solve this? Any alternative to vixie cron?

share|improve this question
up vote 3 down vote accepted

Take a look at fcron:

and, of course, in order to make it really useful, the time remaining until next execution is saved each time the system is stopped. You can also say:

run that command once between 2am and 5am which will be done if the system is running at any time in this interval.

Fcron also includes a useful system of options, which can be applied either to every lines following the declaration or to a single line. Some of the supported options permit to:

  • run jobs one by one (fcrontab option serial),
  • set the max system load average value under which the job should be run (fcrontab option lavg),
  • set a nice value for a job (fcrontab option nice),
  • run jobs at fcron's startup if they should have been run during system down time (fcrontab option bootrun),
share|improve this answer
Thank you very much. Of course I searched the web before asking here, but this did not show up. This cron implementation seems to solve all my needs, and a lot more... – guettli Feb 28 '12 at 15:29
Unfortunately this package was removed from debian and ubuntu. Any volunteers do adopt this package? – guettli Feb 28 '12 at 20:28
You should be able to download the latest deb source version from fossies and build the package by using dpkg-buildpackage. – the-wabbit Feb 29 '12 at 20:28

What you need is simple. Leave your jobs in @Hourly, but instead of calling a direct command, use a bash wrapper with the following function in it:

#! /bin/bash

# Random wait function
random_wait() {
  sleep $(( $RANDOM % ($RANDOMWAIT * 60) + 1 ))

run_job() {


This will delay the execution by a certain amount of time (from 1 to 60 minutes). Change the RANDOMWAIT to a higher value for a bigger range. ($RANDOM is a special shell variable on Linux, and is always a random integer)

That is common practice precisely for the reason you describe. I took this code sample from the cron script of the package yum-cron actually (located in /etc/cron.daily.

share|improve this answer
I use linux since 15 years and know that you can solve it this way. But it is somehow "dirty". Do you still use sendmail? I think it is time for a change. Unfortunately there seems to be no established alternative. – guettli Feb 28 '12 at 13:59
I don't see how this is considered dirty when several official services do it that way! What do you think other schedulers do if they want to delay job execution based on load? Just because it's scripted manually, doesn't mean it's "dirty". – Yanick Girouard Feb 28 '12 at 14:40
It's the $RANDOM that gets your spidey-sense tingling. The @hourly jobs can still all run at the same time if the random value happens to be the same for all of them. It's unlikely, but it's possible and when it happens it's going to be a bitch to debug. Deterministic schedules don't have this problem. – Ladadadada Feb 28 '12 at 15:09
True, but very unlikely. Then again, that was a quick solution, but it's not perfect. A better approach was already accepted by the op. (fcron), which I didn't know about. – Yanick Girouard Feb 28 '12 at 16:01
If your server is under heavy load, the shell wrapper eats cpu cycles before it can check if the load is high. And again, the shell script will start some other processes like cat/grep/cut to check the load.... – guettli Feb 28 '12 at 20:32

Depending on what you're doing, would a background job queuing system like Resque work?

share|improve this answer

There's nothing "dirty" about writing a shell wrapper to run your cron jobs under certain conditions, random intervals is not going to negate your load issues.


within you conditions such as what to do when under load.

Though if you can not run your cron tasks when under load I would be re-evaluating your cron tasks, such as could they be offset to run elsewhere, would they benefit from database sharding etc ...

share|improve this answer

Vixie Cron supports jitter, see here (1)
As far as skipping based on load goes, you will need to hack this, i am not aware of any cron-like tool which can do that.

share|improve this answer
Sad, not supported in my GNU environment. My versions of Ubuntu and SuSE don't have this. Sometimes BSD is better.... – guettli Feb 28 '12 at 14:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.