Difference between revisions of "Cron"

From ArchWiki
Jump to: navigation, search
m (Installation: dcron is still referenced throughout the page, so put the reference back in. (FIXME: either clean up the article or put dcron back into AUR.))
(36 intermediate revisions by 20 users not shown)
Line 4: Line 4:
 
[[sk:Cron]]
 
[[sk:Cron]]
 
[[zh-CN:Cron]]
 
[[zh-CN:Cron]]
{{Temporary i18n}}
 
 
{{Article summary start}}
 
{{Article summary start}}
 
{{Article summary text|An overview of the standard task scheduling daemon on GNU/Linux systems.}}
 
{{Article summary text|An overview of the standard task scheduling daemon on GNU/Linux systems.}}
Line 10: Line 9:
 
{{Article summary link|Gentoo Linux Cron Guide|http://www.gentoo.org/doc/en/cron-guide.xml}}
 
{{Article summary link|Gentoo Linux Cron Guide|http://www.gentoo.org/doc/en/cron-guide.xml}}
 
{{Article summary end}}
 
{{Article summary end}}
 +
{{Lowercase_title}}
  
Cron is a powerful job scheduler for GNU/Linux and many other operating systems. It automates recurring tasks by executing commands at a given time. It has a wide range of potential applications; most simple recurring tasks, from backups to e-mail retrieval, can be automated using cron, saving users time and headaches.
+
From [https://en.wikipedia.org/wiki/Cron Wikipedia]:
  
==Installation==
+
'''''cron''' is the time-based job scheduler in Unix-like computer operating systems. cron enables users to schedule jobs (commands or shell scripts) to run periodically at certain times or dates. It is commonly used to automate system maintenance or administration [...]''
  
There are multiple cron implementations available from which users may choose. {{Pkg|cronie}} is available in [core] and is installed as part of the '''base''' group, you can check it is correctly installed with:
+
== Installation ==
  
  # pacman -S --needed cronie
+
{{Pkg|cronie}} is installed by default as part of the '''base''' group. Other cron implementations exist if preferred, Gentoo's [http://www.gentoo.org/doc/en/cron-guide.xml Cron Guide] offers comparisons.  For example, {{Pkg|fcron}}, {{AUR|bcron}} or {{AUR|vixie-cron}} are other alternatives. {{AUR|dcron}} used to be the default cron implementation in Arch Linux until May 2011.
  
Until May 2011, the default cron implementation for Arch Linux was {{Pkg|dcron}} (Dillon's Cron), which anyway is still supported and can be [[pacman|installed]] from [[official repositories]].
+
== Configuration ==
  
Alternatively, users may wish to install {{Pkg|fcron}} from [community] or {{AUR|bcron}} or {{AUR|vixie-cron}} from the [[AUR]]; all offer a wider range of features and configuration options.
+
=== Users & autostart ===
  
The [http://www.gentoo.org/doc/en/cron-guide.xml Gentoo Linux Cron Guide] offers a comparison between these implementations.
+
cron should be working upon login on a new system to run root scripts. This can be check by looking at the log in {{ic|/var/log/}}. In order to use crontab application (editor for job entries), users must be members of a designated group {{ic|users}} or {{ic|root}}, of which all users should already be members. To ensure cron starts on boot, enable {{ic|cronie.service}} or {{ic|dcron.service}}  with {{ic|systemctl enable <service_name>}} depending on which cron implementation you use.
  
==Initial configuration==
+
=== Handling errors of jobs ===
{{Out of date|The following sections of this article are still based on {{Pkg|dcron}}: you are invited to check the validity of the contents below and fix what is out of date.}}
+
  
===Users & autostart===
+
Errors can occur during execution of jobs. When this happens, cron registers the '''stderr''' output and attempts to send it as email to the user's spools via the {{ic|sendmail}} command.
Cron should work "out-of-the-box" for most Arch Linux users. In order to use crontab, users must be members of a designated group, but in Arch Linux, that group is ''users'', of which all users should already be members. If for whatever reason some users are not members of this group, they can be added to it with the command:
+
  
# gpasswd -a ''username'' users
+
To log these messages use the {{ic|-M}} option in {{ic|/etc/conf.d/crond}} and write a script or install a rudimentary SMTP subsystem (e.g. {{Pkg|esmtp}}):
  
and they should then be able to edit their own crontabs.
+
# pacman -S esmtp procmail
  
To ensure cron starts on boot, add the ''crond'' daemon to the daemons array of [[rc.conf]]. See [[Daemon#Starting_on_Boot]] for details.
+
After installation configure the routing:
 +
{{hc|/etc/esmtprc|
 +
identity ''myself''@myisp.com
 +
      hostname mail.myisp.com:25
 +
      username ''"myself"''
 +
      password ''"secret"''
 +
      starttls enabled
 +
      default
 +
mda "/usr/bin/procmail -d %T"
 +
}}
  
===Handling errors of jobs===
+
Procmail needs root privileges to work in delivery mode but it is not an issue if you are running the cronjobs as root anyway.
Errors can occur during execution of jobs. When this happens cron register '''stderr''' output of job as e-mail and try to send it by default via '''sendmail''' command.
+
To log this message you can use '''-M''' option of crontd and write you own script or install rudimentary SMTP subsystem ('''esmtp''' in this example):
+
  
# pacman -S esmtp procmail
+
To test that everything works correctly, create a file {{ic|message.txt}} with {{ic|"test message"}} in it.
  
After installation create file {{ic|/etc/esmtprc}} with this content:
+
From the same directory run:
  
  identity myself@myisp.com
+
  $ sendmail ''user_name'' < message.txt
        hostname mail.myisp.com:25
+
        username "myself"
+
        password "secret"
+
        starttls enabled
+
        default
+
mda "/usr/bin/procmail -d %T"
+
Procmail needs root privileges to work in delivery mode but it is not an issue if you are running the cronjobs as root.
+
  
To test that everything works correctly, create a file {{ic|message.txt}} with ''"test message"'' in it.
+
then:
  
From the directory containing {{ic|message.txt}} run:
+
$ cat /var/spool/mail/''user_name''
  
$ sendmail user_name < message.txt
+
You should now see the test message and the time and date it was sent.
  
then:
+
The error output of all jobs will now be redirected to {{ic|/var/spool/mail/''user_name''}}.
  
$ cat /var/spool/mail/user_name
+
Due to the privileged issue, it is hard to create and send emails to root (e.g. {{ic|su -c ""}}). You can ask {{ic|esmtp}} to forward all root's email to an ordinary user with:
 +
{{hc|/etc/esmtprc|
 +
2=force_mda="''user-name''"
 +
}}
  
You should see in the terminal, the ''"test message"'', the time and date it was sent.
+
{{Note|If the above test didn't work, you may try creating a local configuration in {{ic|~/.esmtprc}} with the same content.
  
Thats all, all error output of jobs now will be redirected to {{ic|/var/spool/mail/$user_name}}.
+
Run the following command to make sure it has the correct permission:
  
Due to the privileged issue, it is hard to create and send the email to root. So you could ask esmtp to forward all root's email to some ordinary users. Add the following lines in esmtprc
+
$ chmod 710 ~/.esmtprc
force_mda="user-name"
+
  
'''If the above test did not work''', try creating a file {{ic|~/.esmtprc}} with the same content as {{ic|/etc/esmtprc}}, (you can just create a copy as normal user).
+
Then repeat the test with {{ic|message.txt}} exactly as before.}}
  
Run the following command to make sure it has the correct 710 permission:
+
==== Long cron job ====
  
$ chmod 710 ~/.esmtprc
+
Suppose this program is invoked by cron :
  
Now just repeat the test with {{ic|message.txt}} exactly as before.
+
#!/bin/sh
 +
echo "I had a recoverable error!"
 +
sleep 1h
  
==Crontab format==
+
What happens is this:
 +
# cron runs the script
 +
# as soon as cron sees some output, it runs your MTA, and provides it with the headers. It leaves the pipe open, because the job hasn't finished and there might be more output.
 +
# the MTA opens the connection to postfix and leaves that connection open while it waits for the rest of the body.
 +
# postfix closes the idle connection after less than an hour and you get an error like this :
 +
smtpmsg='421 … Error: timeout exceeded' errormsg='the server did not accept the mail'
 +
 
 +
To solve this problem you can use the command chronic or sponge from {{Pkg|moreutils}}.
 +
From they respective man page :
 +
; chronic: chronic runs a command, and arranges for its standard out and standard error to only be displayed if the command fails (exits nonzero or crashes). If the command succeeds, any extraneous output will be hidden.
 +
; sponge: sponge reads standard input and writes it out to the specified file. Unlike a shell redirect, sponge soaks up all its input before opening the output file… If no output file is specified, sponge outputs to stdout.
 +
 
 +
Even if it's not said chronic buffer the command output before opening its standard output (like sponge does).
 +
 
 +
== Crontab format ==
  
 
The basic format for a crontab is:
 
The basic format for a crontab is:
Line 93: Line 109:
 
Multiple times may be specified with a comma, a range can be given with a hyphen, and the asterisk symbol is a wildcard character. Spaces are used to separate fields. For example, the line:
 
Multiple times may be specified with a comma, a range can be given with a hyphen, and the asterisk symbol is a wildcard character. Spaces are used to separate fields. For example, the line:
  
  *0,*5 9-16 * 1-5,9-12 1-5 /home/user/bin/i_love_cron.sh
+
  *0,*5 9-16 * 1-5,9-12 1-5 ~/bin/i_love_cron.sh
  
Will execute the script {{Ic|i_love_cron.sh}} at five minute intervals from 9 AM to 4:55 PM every weekday of the month except during the summer months (June, July, and August). More examples and advanced configuration techniques can be found below.
+
Will execute the script {{Ic|i_love_cron.sh}} at five minute intervals from 9 AM to 4:55 PM on weekdays except during the summer months (June, July, and August). More examples and advanced configuration techniques can be found below.
  
==Basic commands==
+
== Basic commands ==
  
Crontabs should never be edited directly; instead, users should use the ''crontab'' program to work with their crontabs. To be granted access to this command, user must be a member of the users group (see gpasswd command).
+
Crontabs should never be edited directly; instead, users should use the {{ic|crontab}} program to work with their crontabs. To be granted access to this command, user must be a member of the users group (see the {{ic|gpasswd}} command).
  
 
To view their crontabs, users should issue the command:
 
To view their crontabs, users should issue the command:
Line 111: Line 127:
 
To remove their crontabs, they should use:
 
To remove their crontabs, they should use:
  
  $ crontab -d
+
  $ crontab -r
  
 
If a user has a saved crontab and would like to completely overwrite their old crontab, he or she should use:
 
If a user has a saved crontab and would like to completely overwrite their old crontab, he or she should use:
Line 125: Line 141:
 
  # crontab -u ''username'' -e
 
  # crontab -u ''username'' -e
  
This same format (appending "-u ''username''" to a command) works for listing and deleting crontabs as well.
+
This same format (appending {{ic|-u ''username''}} to a command) works for listing and deleting crontabs as well.
  
To use nano rather than vi as crontab editor, add the following lines to /etc/bash.bashrc:
+
To use [[nano]] rather than [[vi]] as crontab editor, add the following lines to your shell's initialization file (eg. {{ic|/etc/profile}} or {{ic|/etc/bash.bashrc}}):
  
 
  export EDITOR="/usr/bin/nano"
 
  export EDITOR="/usr/bin/nano"
  
And restart terminal/s
+
And restart open shells.
  
==Examples==
+
== Examples ==
  
 
The entry:
 
The entry:
Line 153: Line 169:
 
Will execute the script {{Ic|i_love_cron.sh}} at five minute intervals from 9 AM to 5 PM (excluding 5 PM itself) every weekday (Mon-Fri) of every month except during the summer (June, July, and August).
 
Will execute the script {{Ic|i_love_cron.sh}} at five minute intervals from 9 AM to 5 PM (excluding 5 PM itself) every weekday (Mon-Fri) of every month except during the summer (June, July, and August).
  
==More information==
+
== More information ==
  
The cron daemon parses a configuration file known as ''crontab''. Each user on the system can maintain a separate crontab file to schedule commands individually. The root user's crontab is used to schedule system-wide tasks (though users may opt to use {{ic|/etc/crontab}} or the {{ic|/etc/cron.d}} directory, depending on which cron implementation they choose).
+
The cron daemon parses a configuration file known as {{ic|crontab}}. Each user on the system can maintain a separate crontab file to schedule commands individually. The root user's crontab is used to schedule system-wide tasks (though users may opt to use {{ic|/etc/crontab}} or the {{ic|/etc/cron.d}} directory, depending on which cron implementation they choose).
  
 
There are slight differences between the crontab formats of the different cron daemons. The default root crontab for dcron looks like this:
 
There are slight differences between the crontab formats of the different cron daemons. The default root crontab for dcron looks like this:
Line 194: Line 210:
 
See the crontab [[man page]] for further information and configuration examples.
 
See the crontab [[man page]] for further information and configuration examples.
  
==run-parts issue==
+
== run-parts issue ==
cronie use run-parts to carry out script in cron.daily/cron.week.y/cron.montly. Be carefull that the script name in these folders should not have any '.', like backup.sh. Since run-parts without options will ignore them. Detail information see man run-parts.
+
  
==Running X apps==
+
cronie uses {{ic|run-parts}} to carry out script in {{ic|cron.daily}}/{{ic|cron.weekly}}/{{ic|cron.monthly}}. Be careful that the script name in these won't include a dot (.), e.g. {{ic|backup.sh}}, since {{ic|run-parts}} without options will ignore them (see: {{ic|man run-parts}}).
  
If you find that you cannot run X apps from cron jobs then put this before the
+
== Running Xorg server based applications ==
command:
+
 
 +
If you find that you can't run X apps from cron jobs then use this prefix:
  
 
  export DISPLAY=:0.0 ;
 
  export DISPLAY=:0.0 ;
  
That sets the DISPLAY variable to the first display; which is usually right
+
This sets the {{ic|DISPLAY}} variable to the first display, which is usually right
unless you like to run multiple xservers on your machine.
+
unless you run multiple X servers on your machine.
  
If it still does not work then you need to use xhost to give your user control
+
If it still doesn't work, then you need to use {{ic|xhost}} to give your user control
over X11:
+
over X:
  
 
  # xhost +si:localuser:$(whoami)
 
  # xhost +si:localuser:$(whoami)
  
I put it in my gnome `Startup Applications' like this:
+
== Asynchronous job processing ==
 
+
bash -c "xhost +si:localuser:$(whoami)"
+
 
+
==Asynchronous job processing==
+
  
 
If you regularly turn off your computer but do not want to miss jobs, there are some solutions available (easiest to hardest):
 
If you regularly turn off your computer but do not want to miss jobs, there are some solutions available (easiest to hardest):
  
; Dcron : Vanilla dcron supports asynchronous job processing. Just put it with @hourly, @daily, @weekly or @monthly with a jobname, like this:
+
===Dcron===
 +
Vanilla dcron supports asynchronous job processing. Just put it with @hourly, @daily, @weekly or @monthly with a jobname, like this:
  
 
  @hourly        ID=greatest_ever_job      echo This job is very useful.
 
  @hourly        ID=greatest_ever_job      echo This job is very useful.
  
; Cronwhip ([https://aur.archlinux.org/packages.php?ID=21079 AUR], [https://bbs.archlinux.org/viewtopic.php?id=57973 forum thread]): Script to automatically run missed cron jobs; works with the default cron implementation, dcron.
+
===Cronwhip===
; Anacron ([https://aur.archlinux.org/packages.php?ID=5196 AUR]): Full replacement for dcron, processes jobs asynchronously.
+
([https://aur.archlinux.org/packages.php?ID=21079 AUR], [https://bbs.archlinux.org/viewtopic.php?id=57973 forum thread]): Script to automatically run missed cron jobs; works with the former default cron implementation, dcron.
 +
 
 +
===Anacron===
 +
([https://aur.archlinux.org/packages.php?ID=5196 AUR]): Full replacement for dcron, processes jobs asynchronously.
 +
 
 +
===Fcron===
 +
([https://www.archlinux.org/packages/community/i686/fcron/ Community], [https://bbs.archlinux.org/viewtopic.php?id=140497 forum thread]): Like anacron, fcron assumes the computer is not always running and, unlike anacron, it can schedule events at intervals shorter than a single day.  Like cronwhip, it can run jobs that should have been run during the computer's downtime.
 +
 
 +
== Ensuring exclusivity ==
 +
 
 +
If you run potentially long-running jobs (e.g., a backup might all of a sudden run for a long time, because of many changes or a particular slow network connection), then {{AUR|lockrun}} can ensure that the cron job won't start a second time.
 +
 
 +
  5,35 * * * * /usr/bin/lockrun -n /tmp/lock.backup /root/make-backup.sh
  
==See also==
+
== See Also ==
[http://wiki.gotux.net/config:crontab CronTab Config and Examples]
+
* [http://gotux.net/arch-linux/crontab-usage/ CronTab Usage Tutorial]

Revision as of 20:08, 5 June 2013

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary link Template:Article summary end

From Wikipedia:

cron is the time-based job scheduler in Unix-like computer operating systems. cron enables users to schedule jobs (commands or shell scripts) to run periodically at certain times or dates. It is commonly used to automate system maintenance or administration [...]

Installation

cronie is installed by default as part of the base group. Other cron implementations exist if preferred, Gentoo's Cron Guide offers comparisons. For example, fcron, bcronAUR or vixie-cronAUR are other alternatives. dcronAUR used to be the default cron implementation in Arch Linux until May 2011.

Configuration

Users & autostart

cron should be working upon login on a new system to run root scripts. This can be check by looking at the log in /var/log/. In order to use crontab application (editor for job entries), users must be members of a designated group users or root, of which all users should already be members. To ensure cron starts on boot, enable cronie.service or dcron.service with systemctl enable <service_name> depending on which cron implementation you use.

Handling errors of jobs

Errors can occur during execution of jobs. When this happens, cron registers the stderr output and attempts to send it as email to the user's spools via the sendmail command.

To log these messages use the -M option in /etc/conf.d/crond and write a script or install a rudimentary SMTP subsystem (e.g. esmtp):

# pacman -S esmtp procmail

After installation configure the routing:

/etc/esmtprc
identity myself@myisp.com
       hostname mail.myisp.com:25
       username "myself"
       password "secret"
       starttls enabled
       default
mda "/usr/bin/procmail -d %T"

Procmail needs root privileges to work in delivery mode but it is not an issue if you are running the cronjobs as root anyway.

To test that everything works correctly, create a file message.txt with "test message" in it.

From the same directory run:

$ sendmail user_name < message.txt 

then:

$ cat /var/spool/mail/user_name

You should now see the test message and the time and date it was sent.

The error output of all jobs will now be redirected to /var/spool/mail/user_name.

Due to the privileged issue, it is hard to create and send emails to root (e.g. su -c ""). You can ask esmtp to forward all root's email to an ordinary user with:

/etc/esmtprc
force_mda="user-name"
Note: If the above test didn't work, you may try creating a local configuration in ~/.esmtprc with the same content.

Run the following command to make sure it has the correct permission:

$ chmod 710 ~/.esmtprc
Then repeat the test with message.txt exactly as before.

Long cron job

Suppose this program is invoked by cron :

#!/bin/sh
echo "I had a recoverable error!"
sleep 1h

What happens is this:

  1. cron runs the script
  2. as soon as cron sees some output, it runs your MTA, and provides it with the headers. It leaves the pipe open, because the job hasn't finished and there might be more output.
  3. the MTA opens the connection to postfix and leaves that connection open while it waits for the rest of the body.
  4. postfix closes the idle connection after less than an hour and you get an error like this :
smtpmsg='421 … Error: timeout exceeded' errormsg='the server did not accept the mail'

To solve this problem you can use the command chronic or sponge from moreutils. From they respective man page :

chronic
chronic runs a command, and arranges for its standard out and standard error to only be displayed if the command fails (exits nonzero or crashes). If the command succeeds, any extraneous output will be hidden.
sponge
sponge reads standard input and writes it out to the specified file. Unlike a shell redirect, sponge soaks up all its input before opening the output file… If no output file is specified, sponge outputs to stdout.

Even if it's not said chronic buffer the command output before opening its standard output (like sponge does).

Crontab format

The basic format for a crontab is:

<minute> <hour> <day_of_month> <month> <day_of_week> <command>
  • minute values can be from 0 to 59.
  • hour values can be from 0 to 23.
  • day_of_month values can be from 1 to 31.
  • month values can be from 1 to 12.
  • day_of_week values can be from 0 to 6, with 0 denoting Sunday.

Multiple times may be specified with a comma, a range can be given with a hyphen, and the asterisk symbol is a wildcard character. Spaces are used to separate fields. For example, the line:

*0,*5 9-16 * 1-5,9-12 1-5 ~/bin/i_love_cron.sh

Will execute the script i_love_cron.sh at five minute intervals from 9 AM to 4:55 PM on weekdays except during the summer months (June, July, and August). More examples and advanced configuration techniques can be found below.

Basic commands

Crontabs should never be edited directly; instead, users should use the crontab program to work with their crontabs. To be granted access to this command, user must be a member of the users group (see the gpasswd command).

To view their crontabs, users should issue the command:

$ crontab -l

To edit their crontabs, they may use:

$ crontab -e

To remove their crontabs, they should use:

$ crontab -r

If a user has a saved crontab and would like to completely overwrite their old crontab, he or she should use:

$ crontab saved_crontab_filename

To overwrite a crontab from the command line (Wikipedia:stdin), use

$ crontab - 

To edit somebody else's crontab, issue the following command as root:

# crontab -u username -e

This same format (appending -u username to a command) works for listing and deleting crontabs as well.

To use nano rather than vi as crontab editor, add the following lines to your shell's initialization file (eg. /etc/profile or /etc/bash.bashrc):

export EDITOR="/usr/bin/nano"

And restart open shells.

Examples

The entry:

01 * * * * /bin/echo Hello, world!

runs the command /bin/echo Hello, world! on the first minute of every hour of every day of every month (i.e. at 12:01, 1:01, 2:01, etc.)

Similarly,

*/5 * * jan mon-fri /bin/echo Hello, world!

runs the same job every five minutes on weekdays during the month of January (i.e. at 12:00, 12:05, 12:10, etc.)

As noted in the Crontab Format section, the line:

*0,*5 9-16 * 1-5,9-12 1-5 /home/user/bin/i_love_cron.sh

Will execute the script i_love_cron.sh at five minute intervals from 9 AM to 5 PM (excluding 5 PM itself) every weekday (Mon-Fri) of every month except during the summer (June, July, and August).

More information

The cron daemon parses a configuration file known as crontab. Each user on the system can maintain a separate crontab file to schedule commands individually. The root user's crontab is used to schedule system-wide tasks (though users may opt to use /etc/crontab or the /etc/cron.d directory, depending on which cron implementation they choose).

There are slight differences between the crontab formats of the different cron daemons. The default root crontab for dcron looks like this:

/var/spool/cron/root
# root crontab
# DO NOT EDIT THIS FILE MANUALLY! USE crontab -e INSTEAD

# man 1 crontab for acceptable formats:
#    <minute> <hour> <day> <month> <dow> <tags and command>
#    <@freq> <tags and command>

# SYSTEM DAILY/WEEKLY/... FOLDERS
@hourly         ID=sys-hourly   /usr/sbin/run-cron /etc/cron.hourly
@daily          ID=sys-daily    /usr/sbin/run-cron /etc/cron.daily
@weekly         ID=sys-weekly   /usr/sbin/run-cron /etc/cron.weekly
@monthly        ID=sys-monthly  /usr/sbin/run-cron /etc/cron.monthly

These lines exemplify one of the formats that crontab entries can have, namely whitespace-separated fields specifying:

  1. @period
  2. ID=jobname (this tag is specific to dcron)
  3. command

The other standard format for crontab entries is:

  1. minute
  2. hour
  3. day
  4. month
  5. day of week
  6. command

The crontab files themselves are usually stored as /var/spool/cron/username. For example, root's crontab is found at /var/spool/cron/root

See the crontab man page for further information and configuration examples.

run-parts issue

cronie uses run-parts to carry out script in cron.daily/cron.weekly/cron.monthly. Be careful that the script name in these won't include a dot (.), e.g. backup.sh, since run-parts without options will ignore them (see: man run-parts).

Running Xorg server based applications

If you find that you can't run X apps from cron jobs then use this prefix:

export DISPLAY=:0.0 ;

This sets the DISPLAY variable to the first display, which is usually right unless you run multiple X servers on your machine.

If it still doesn't work, then you need to use xhost to give your user control over X:

# xhost +si:localuser:$(whoami)

Asynchronous job processing

If you regularly turn off your computer but do not want to miss jobs, there are some solutions available (easiest to hardest):

Dcron

Vanilla dcron supports asynchronous job processing. Just put it with @hourly, @daily, @weekly or @monthly with a jobname, like this:

@hourly         ID=greatest_ever_job      echo This job is very useful.

Cronwhip

(AUR, forum thread): Script to automatically run missed cron jobs; works with the former default cron implementation, dcron.

Anacron

(AUR): Full replacement for dcron, processes jobs asynchronously.

Fcron

(Community, forum thread): Like anacron, fcron assumes the computer is not always running and, unlike anacron, it can schedule events at intervals shorter than a single day. Like cronwhip, it can run jobs that should have been run during the computer's downtime.

Ensuring exclusivity

If you run potentially long-running jobs (e.g., a backup might all of a sudden run for a long time, because of many changes or a particular slow network connection), then lockrunAUR can ensure that the cron job won't start a second time.

  5,35 * * * * /usr/bin/lockrun -n /tmp/lock.backup /root/make-backup.sh

See Also