'''''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 [...]''

+

:''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 ==

== Installation ==

−

{{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.

+

There are many cron implementations, but none of them are installed by default as the base system uses [[systemd/Timers]] instead. See the Gentoo's [http://www.gentoo.org/doc/en/cron-guide.xml cron guide], which offers comparisons.

+

+

Packages available:

+

+

* {{Pkg|cronie}}

+

* {{Pkg|fcron}}

+

* {{AUR|dcron}}

+

* {{AUR|vixie-cron}}

+

* {{AUR|scron-git}}

== Configuration ==

== Configuration ==

−

=== Users & autostart ===

+

=== Activation and autostart ===

+

+

After installation, the daemon will not be enabled by default. The installed package likely provides a service, which can be controlled by [[systemd#Using units|systemctl]]. For example, ''cronie'' uses {{ic|cronie.service}}.

+

+

Check {{ic|/etc/cron.daily/}} and similar directories to see which jobs are present. Activating cron service will trigger all of them.

−

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.

+

{{Note|''cronie'' provides the {{ic|0anacron}} ''hourly'' job, which allows for [[#Asynchronous job processing|delayed runs of other jobs]] e.g. if the computer was switched off at the moment of standard execution.}}

=== Handling errors of jobs ===

=== 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 {{ic|sendmail}} command.

+

cron registers the output from ''stdout'' and ''stderr'' and attempts to send it as email to the user's spools via the {{ic|sendmail}} command. Cronie disables mail output if {{ic|/usr/bin/sendmail}} is not found. In order for mail to be written to a user's spool, there must be an smtp daemon running on the system, e.g. {{Pkg|opensmtpd}}. Otherwise, you can install a package that provides the sendmail command, and configure it to send mail to a remote mail exchanger. You can also log the messages by using the {{ic|-m}} option and writing a custom script.

+

+

{{Tip|One can send the output to local system users using [[Postfix#Local mail]].}}

To log these messages use the {{ic|-M}} option and write a script or install a rudimentary SMTP subsystem:

+

ssmtp is a send-only sendmail emulator which delivers email from a local computer to an smtp server. While there are currently no active maintainers, it is still by far the simplest way to transfer mail to a configured mailhub. There are no daemons to run, and configuration can be as simple as editing 3 lines in a single configuration file (if your host is trusted to relay unauthenticated email through your mailhub). ssmtp does not receive mail, expand aliases, or manage a queue.

Install {{Pkg|ssmtp}}, which creates a symbolic link from {{ic|/usr/bin/sendmail}} to {{ic|/usr/bin/ssmtp}}. You must then edit {{ic|/etc/ssmtp/ssmtp.conf}}. See [[SSMTP|ssmtp]] for details. Creating a symbolic link to {{ic|/usr/bin/sendmail}} insures that programs like [[S-nail]] (or any package which provides {{ic|/usr/bin/mail}} will just work without modification.

−

# Install {{Pkg|esmtp}}, {{Pkg|msmtp}} or write a custom script.

−

Example with esmtp:

+

Restart {{ic|cronie}} to insure that it detects that you now have a {{ic|/usr/bin/sendmail}} installed.

−

# pacman -S esmtp procmail

+

==== Example with msmtp ====

+

+

Install {{Pkg|msmtp-mta}}, which creates a symbolic link from {{ic|/usr/bin/sendmail}} to {{ic|/usr/bin/msmtp}}. Restart {{ic|cronie}} to make sure it detects the new {{ic|sendmail}} command. You must then provide a way for {{ic|msmtp}} to convert your username into an email address.

+

+

Then either add {{ic|MAILTO}} line to your crontab, like so:

+

+

<nowiki>MAILTO=your@email.com</nowiki>

+

+

'''or''' create {{ic|/etc/msmtprc}} and append this line:

+

+

aliases /etc/aliases

+

+

and create {{ic|/etc/aliases}}:

+

+

your_username: your@email.com

+

# Optional:

+

default: your@email.com

+

+

Then [[Systemd#Editing provided units|modify the configuration]] of ''cronie'' daemon by replacing the {{ic|ExecStart}} command with:

+

+

ExecStart=/usr/bin/crond -n -m '/usr/bin/msmtp -t'

+

+

==== Example with esmtp ====

+

+

Install {{Pkg|esmtp}} and {{Pkg|procmail}}.

After installation configure the routing:

After installation configure the routing:

Line 77:

Line 120:

Then repeat the test with {{ic|message.txt}} exactly as before.}}

Then repeat the test with {{ic|message.txt}} exactly as before.}}

+

+

==== Example with opensmtpd ====

+

+

Install {{Pkg|opensmtpd}}.

+

+

Edit {{ic|/etc/smtpd/smtpd.conf}}. The following configuration allows for local delivery:

+

+

listen on localhost

+

accept for local deliver to mbox

+

+

You can proceed to test it. First [[start]] {{ic|smtpd.service}}. Then do:

+

$ echo test | sendmail user

+

+

''user'' can check his/her mail in with any [[:Category:Email clients|reader]] able to handle mbox format, or just have a look at the file {{ic|/var/spool/mail/''user''}}. If everything goes as expected, you can [[enable]] opensmtpd for future boots.

+

+

This approach has the advantage of not sending local cron notifications to a remote server. On the downside, you need a new daemon running.

+

+

{{Note|

+

* At the moment of writing the Arch opensmtpd package does not create all needed directories under {{ic|/var/spool/smtpd}}, but the daemon will warn about that specifying the required ownerships and permissions. Just create them as suggested.

+

* Even though the suggested configuration does not accept remote connections, it's a healthy precaution to add an additional layer of security blocking port 25 with [[iptables]] or similar.

+

}}

==== Long cron job ====

==== Long cron job ====

Line 94:

Line 158:

To solve this problem you can use the command chronic or sponge from {{Pkg|moreutils}}.

To solve this problem you can use the command chronic or sponge from {{Pkg|moreutils}}.

−

From they respective man page :

+

From their 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.

; 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.

; 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).

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:

+

Spaces are used to separate fields. To fine-tune your schedule you may also use one of the following symbols:

+

+

{| class="wikitable" style="text-align: center"

+

!Symbol!!Description

+

|-

+

| '''*''' || Wildcard, specifies every possible time interval

+

|-

+

| ''',''' || List multiple values separated by a comma.

+

|-

+

| '''-''' || Specify a range between two numbers, separated by a hyphen

+

|-

+

| '''/''' || Specify a periodicity/frequency using a slash

+

|-

+

|}

+

+

For example, the line:

+

+

*/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 on weekdays except during the summer months (June, July, and August). More examples and advanced configuration techniques can be found below.

+

+

Besides, crontab has some special keywords:

+

+

@reboot at startup

+

@yearly once a year

+

@annually ( == @yearly)

+

@monthly once a month

+

@weekly once a week

+

@daily once a day

+

@midnight ( == @daily)

+

@hourly once an hour

+

+

For example:

+

+

@reboot ~/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 startup.

−

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.

This same format (appending {{ic|-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 your shell's initialization file (eg. {{ic|/etc/profile}} or {{ic|/etc/bash.bashrc}}):

−

−

export EDITOR="/usr/bin/nano"

−

−

And restart open shells.

== Examples ==

== Examples ==

Line 160:

Line 254:

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

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

−

runs the command {{Ic|/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.)

+

runs the command {{ic|/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,

+

Similarly:

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

*/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.)

+

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:

+

The line (as noted in "man 5 crontab"):

*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 /home/user/bin/i_love_cron.sh

−

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 ==

+

Periodical settings can also be entered as in this crontab template:

−

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).

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

+

To use an alternate default editor, define the {{ic|EDITOR}} environment variable in a shell initialization script as described in [[Environment variables]].

−

# @period

+

As a regular user, {{ic|su}} will need to be used instead of {{ic|sudo}} for the environment variable to be pulled correctly:

−

# ID=jobname (this tag is specific to dcron)

−

# command

−

The other standard format for crontab entries is:

+

$ su -c "crontab -e"

−

# minute

+

To have an alias to this {{ic|printf}} is required to carry the arbitrary string because {{ic|su}} launches in a new shell:

−

# hour

−

# day

−

# month

−

# day of week

−

# command

−

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

+

alias scron="su -c $(printf "%q " "crontab -e")"

−

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

+

== Running X.org server-based applications ==

−

== run-parts issue ==

+

Cron does not run under the X.org server therefore it cannot know the environmental variable necessary to be able to start an X.org server application so they will have to be defined. One can use a program like {{AUR|xuserrun-git}} to do it:

−

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}}).

+

17 02 * ... /usr/bin/xuserrun /usr/bin/xclock

−

== Running Xorg server based applications ==

+

Or they can be defined manually ({{ic|echo $DISPLAY}} will give the current DISPLAY value):

−

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

+

17 02 * ... env DISPLAY=:0 /usr/bin/xclock

−

export DISPLAY=:0.0 ;

+

If running notify-send for desktop notifications in cron, notify-send is sending values to dbus. So it needs to tell dbus to connect to the right bus.

+

The address can be found by examining DBUS_SESSION_BUS_ADDRESS environment variable and setting it to the same value. Therefore:

−

This sets the {{ic|DISPLAY}} variable to the first display, which is usually right

It is based on the original cron and has security and configuration enhancements like the ability to use pam and SELinux.

+

+

=== Dcron ===

+

+

Vanilla {{AUR|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===

+

=== 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 former default cron implementation, dcron.

+

+

{{AUR|cronwhip}} is a script to automatically run missed cron jobs; it works with the former default cron implementation, ''dcron''.

+

See also the [https://bbs.archlinux.org/viewtopic.php?id=57973 forum thread].

+

+

=== Anacron ===

+

Anacron is a full replacement for ''dcron'' which processes jobs asynchronously.

−

===Anacron===

+

It is provided by {{Pkg|cronie}}. The configuration file is {{ic|/etc/anacrontab}}. Information on the format can be found in the {{ic|anacrontab(5)}} [[man page]]. Running {{ic|anacron -T}} will test {{ic|/etc/anacrontab}} for validity.

([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.

+

+

Like ''anacron'', {{Pkg|fcron}} assumes the computer is not always running and, unlike ''anacron'', it can schedule events at intervals shorter than a single day which may be useful for systems which suspend/hibernate regularly (such as a laptop). Like cronwhip, fcron can run jobs that should have been run during the computer's downtime.

+

+

When replacing {{Pkg|cronie}} with fcron be aware the spool directory is {{ic|/var/spool/fcron}} and the {{ic|fcrontab}} command is used instead of ''crontab'' to edit the user crontabs. These crontabs are stored in a binary format with the text version next to them as ''foo''.orig in the spool directory. Any scripts which manually edit user crontabs may need to be adjusted due to this difference in behavior.

+

+

A quick scriptlet which may aide in converting traditional user crontabs to fcron format:

+

+

{{bc|

+

cd /var/spool/cron && (

+

for ctab in *; do

+

fcrontab ${ctab} -u ${ctab}

+

done

+

)

+

}}

+

+

See also the [https://bbs.archlinux.org/viewtopic.php?id=140497 forum thread].

== Ensuring exclusivity ==

== 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.

+

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 {{ic|flock}} ({{Pkg|util-linux}}) can ensure that the cron job won't start a second time.

+

+

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

+

+

== Cronie ==

+

+

The relevant file hierarchy for cronie is the following:

+

+

/etc/

+

|----- cron.d/

+

| ----- 0hourly

+

|----- cron.minutely/

+

|----- cron.hourly/

+

| ----- 0anacron

+

|----- anacrontab

+

|----- cron.daily/

+

|----- cron.monthly/

+

|----- cron.weekly/

+

|----- crontab

+

|----- cron.deny

+

+

Cronie provides both ''cron'' and ''anacron'' functionalities: ''cron'' runs jobs at regular time intervals (down to a granularity of one minute) as long as the system is available at the specified time, while ''anacron'' executes commands at

+

intervals specified in days. Unlike cron, it does not assume that the system is running continuously. Whenever the system is up, ''anacron'' checks if there are any jobs that should have been run and handles them accordingly.

+

+

A ''cron'' job can be defined in a crontab-like file in the {{ic|/etc/cron.d}} directory or added within the {{ic|/etc/crontab}} file. Note the latter is not present by default but is used if it exists. As instructed by {{ic|/etc/cron.d/0hourly}}, any executable file in {{ic|/etc/cron.hourly}} will be run every hour (by default at minute 1 of the hour). Files in {{ic|/etc/cron.minutely}} are executed every minute if instructed accordingly in {{ic|/etc/cron.d/0hourly}}. The executables are typically shell scripts, symlinks to executable files can also be used.

+

The {{ic|/etc/cron.deny}} file includes the list of users not allowed to use crontab, without this file, only users listed in {{ic|/etc/cron.allow}} can use it.

+

+

''Anacron'' works similarly, by executing the files in the {{ic|/etc/cron.daily}}, {{ic|/etc/cron.weekly}} and {{ic|/etc/cron.monthly}} directories, placed there depending on the desired job frequency. The cron job {{ic|/etc/cron.hourly/0anacron}} makes sure that ''anacron'' is run once daily to perform its pending tasks.

+

+

{{Note|

+

* Cronie uses {{ic|run-parts}} to carry out scripts in the different directories. The filenames should not include any dot (.) since {{ic|run-parts}} in its default mode will silently ignore them (see {{man|8|run-parts}}). The names must consist only of upper and lower-case letters, digits, underscores and minus-hyphens.

+

* The output of {{ic|systemctl status cronie}} might show a message such as {{ic|CAN'T OPEN (/etc/crontab): No such file or directory}}. However, this can be ignored since cronie does not require one.

+

* Cronie is particular about the permissions for {{ic|/etc/cron.d/0hourly}}. None of the tasks in {{ic|/etc/cron.d/{hourly,weekly,daily} ... etc}} will be run (including the anacron launcher) if {{ic|/etc/cron.d/0hourly}} is damaged or has improper permissions. {{ic|pacman -Qkk cronie}} can show if you have any such issues.

+

}}

+

+

{{Tip|To prevent the sending of output and stop email alert, add {{ic|>/dev/null 2>&1}} at the end of the line for each cron job to redirect output to /dev/null.

+

+

0 1 5 10 * /path/to/script.sh >/dev/null 2>&1

+

+

You can also set {{ic|1=MAILTO=””}} variable in your crontab file to disable email alerts.}}

+

+

== Dcron ==

+

+

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).

Latest revision as of 08:01, 11 March 2018

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.

Configuration

Activation and autostart

After installation, the daemon will not be enabled by default. The installed package likely provides a service, which can be controlled by systemctl. For example, cronie uses cronie.service.

Check /etc/cron.daily/ and similar directories to see which jobs are present. Activating cron service will trigger all of them.

Note:cronie provides the 0anacronhourly job, which allows for delayed runs of other jobs e.g. if the computer was switched off at the moment of standard execution.

Handling errors of jobs

cron registers the output from stdout and stderr and attempts to send it as email to the user's spools via the sendmail command. Cronie disables mail output if /usr/bin/sendmail is not found. In order for mail to be written to a user's spool, there must be an smtp daemon running on the system, e.g. opensmtpd. Otherwise, you can install a package that provides the sendmail command, and configure it to send mail to a remote mail exchanger. You can also log the messages by using the -m option and writing a custom script.

Example with ssmtp

ssmtp is a send-only sendmail emulator which delivers email from a local computer to an smtp server. While there are currently no active maintainers, it is still by far the simplest way to transfer mail to a configured mailhub. There are no daemons to run, and configuration can be as simple as editing 3 lines in a single configuration file (if your host is trusted to relay unauthenticated email through your mailhub). ssmtp does not receive mail, expand aliases, or manage a queue.

Install ssmtp, which creates a symbolic link from /usr/bin/sendmail to /usr/bin/ssmtp. You must then edit /etc/ssmtp/ssmtp.conf. See ssmtp for details. Creating a symbolic link to /usr/bin/sendmail insures that programs like S-nail (or any package which provides /usr/bin/mail will just work without modification.

Restart cronie to insure that it detects that you now have a /usr/bin/sendmail installed.

Example with msmtp

Install msmtp-mta, which creates a symbolic link from /usr/bin/sendmail to /usr/bin/msmtp. Restart cronie to make sure it detects the new sendmail command. You must then provide a way for msmtp to convert your username into an email address.

user can check his/her mail in with any reader able to handle mbox format, or just have a look at the file /var/spool/mail/user. If everything goes as expected, you can enable opensmtpd for future boots.

This approach has the advantage of not sending local cron notifications to a remote server. On the downside, you need a new daemon running.

Note:

At the moment of writing the Arch opensmtpd package does not create all needed directories under /var/spool/smtpd, but the daemon will warn about that specifying the required ownerships and permissions. Just create them as suggested.

Even though the suggested configuration does not accept remote connections, it's a healthy precaution to add an additional layer of security blocking port 25 with iptables or similar.

Long cron job

Suppose this program is invoked by cron :

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

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 :

To solve this problem you can use the command chronic or sponge from moreutils.
From their 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.

Spaces are used to separate fields. To fine-tune your schedule you may also use one of the following symbols:

Symbol

Description

*

Wildcard, specifies every possible time interval

,

List multiple values separated by a comma.

-

Specify a range between two numbers, separated by a hyphen

/

Specify a periodicity/frequency using a slash

For example, the line:

*/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.

Besides, crontab has some special keywords:

@reboot at startup
@yearly once a year
@annually ( == @yearly)
@monthly once a month
@weekly once a week
@daily once a day
@midnight ( == @daily)
@hourly once an hour

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).

Default editor

To use an alternate default editor, define the EDITOR environment variable in a shell initialization script as described in Environment variables.

As a regular user, su will need to be used instead of sudo for the environment variable to be pulled correctly:

$ su -c "crontab -e"

To have an alias to this printf is required to carry the arbitrary string because su launches in a new shell:

alias scron="su -c $(printf "%q " "crontab -e")"

Running X.org server-based applications

Cron does not run under the X.org server therefore it cannot know the environmental variable necessary to be able to start an X.org server application so they will have to be defined. One can use a program like xuserrun-gitAUR to do it:

17 02 * ... /usr/bin/xuserrun /usr/bin/xclock

Or they can be defined manually (echo $DISPLAY will give the current DISPLAY value):

17 02 * ... env DISPLAY=:0 /usr/bin/xclock

If running notify-send for desktop notifications in cron, notify-send is sending values to dbus. So it needs to tell dbus to connect to the right bus.
The address can be found by examining DBUS_SESSION_BUS_ADDRESS environment variable and setting it to the same value. Therefore:

Asynchronous job processing

Cronie

Cronie contains the standard UNIX daemon crond that runs specified programs at scheduled times and related tools.
It is based on the original cron and has security and configuration enhancements like the ability to use pam and SELinux.

Dcron

Vanilla dcronAUR 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

cronwhipAUR is a script to automatically run missed cron jobs; it works with the former default cron implementation, dcron.
See also the forum thread.

Anacron

Anacron is a full replacement for dcron which processes jobs asynchronously.

It is provided by cronie. The configuration file is /etc/anacrontab. Information on the format can be found in the anacrontab(5)man page. Running anacron -T will test /etc/anacrontab for validity.

Fcron

Like anacron, fcron assumes the computer is not always running and, unlike anacron, it can schedule events at intervals shorter than a single day which may be useful for systems which suspend/hibernate regularly (such as a laptop). Like cronwhip, fcron can run jobs that should have been run during the computer's downtime.

When replacing cronie with fcron be aware the spool directory is /var/spool/fcron and the fcrontab command is used instead of crontab to edit the user crontabs. These crontabs are stored in a binary format with the text version next to them as foo.orig in the spool directory. Any scripts which manually edit user crontabs may need to be adjusted due to this difference in behavior.

A quick scriptlet which may aide in converting traditional user crontabs to fcron format:

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 flock (util-linux) can ensure that the cron job won't start a second time.

Cronie provides both cron and anacron functionalities: cron runs jobs at regular time intervals (down to a granularity of one minute) as long as the system is available at the specified time, while anacron executes commands at
intervals specified in days. Unlike cron, it does not assume that the system is running continuously. Whenever the system is up, anacron checks if there are any jobs that should have been run and handles them accordingly.

A cron job can be defined in a crontab-like file in the /etc/cron.d directory or added within the /etc/crontab file. Note the latter is not present by default but is used if it exists. As instructed by /etc/cron.d/0hourly, any executable file in /etc/cron.hourly will be run every hour (by default at minute 1 of the hour). Files in /etc/cron.minutely are executed every minute if instructed accordingly in /etc/cron.d/0hourly. The executables are typically shell scripts, symlinks to executable files can also be used.
The /etc/cron.deny file includes the list of users not allowed to use crontab, without this file, only users listed in /etc/cron.allow can use it.

Anacron works similarly, by executing the files in the /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly directories, placed there depending on the desired job frequency. The cron job /etc/cron.hourly/0anacron makes sure that anacron is run once daily to perform its pending tasks.

Note:

Cronie uses run-parts to carry out scripts in the different directories. The filenames should not include any dot (.) since run-parts in its default mode will silently ignore them (see run-parts(8)). The names must consist only of upper and lower-case letters, digits, underscores and minus-hyphens.

The output of systemctl status cronie might show a message such as CAN'T OPEN (/etc/crontab): No such file or directory. However, this can be ignored since cronie does not require one.

Cronie is particular about the permissions for /etc/cron.d/0hourly. None of the tasks in /etc/cron.d/{hourly,weekly,daily} ... etc will be run (including the anacron launcher) if /etc/cron.d/0hourly is damaged or has improper permissions. pacman -Qkk cronie can show if you have any such issues.

Tip: To prevent the sending of output and stop email alert, add >/dev/null 2>&1 at the end of the line for each cron job to redirect output to /dev/null.

0 1 5 10 * /path/to/script.sh >/dev/null 2>&1

You can also set MAILTO=”” variable in your crontab file to disable email alerts.

Dcron

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).