Difference between revisions of "Cron"
Kynikos.bot (talk | contribs) (rm temporary i18n template) |
m (Various style fixes) |
||
(46 intermediate revisions by 25 users not shown) | |||
Line 2: | Line 2: | ||
[[de:Cron]] | [[de:Cron]] | ||
[[fr:Cron]] | [[fr:Cron]] | ||
+ | [[ko:Cron]] | ||
[[sk:Cron]] | [[sk:Cron]] | ||
[[zh-CN:Cron]] | [[zh-CN:Cron]] | ||
Line 8: | Line 9: | ||
{{Article summary heading|Resources}} | {{Article summary heading|Resources}} | ||
{{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 heading|Related}} | ||
+ | {{Article summary wiki|systemd/cron functionality}} | ||
{{Article summary end}} | {{Article summary end}} | ||
+ | {{Lowercase_title}} | ||
− | Cron | + | From [[Wikipedia:Cron|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 == | |
− | + | {{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. | |
− | + | == Configuration == | |
− | + | === Users and 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 {{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. | |
− | == | + | === 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 {{ic|sendmail}} command. Cronie disables mail output if {{ic|/usr/bin/sendmail}} is not found. To log these messages use the {{ic|-m}} option and write a script or install a rudimentary SMTP subsystem. | |
− | |||
− | + | # [[Systemd#Editing_provided_unit_files|Edit]] the {{ic|cronie.service}} unit. | |
+ | # Install {{Pkg|esmtp}}, {{Pkg|msmtp}}, {{Pkg|opensmtpd}} or write a custom script. | ||
− | + | ==== Example with msmtp ==== | |
− | + | Here are two ways to obtain emails from cronie with msmtp: | |
− | = | + | # Install the {{Pkg|msmtp-mta}} package which effectively creates a symbolic link from {{ic|/usr/bin/sendmail}} to {{ic|/usr/bin/msmtp}}. You must then provide a way for msmtp to convert your username into an email address. |
− | + | #* Either add a {{ic|MAILTO}} line to your crontab, like so:{{bc|<nowiki>MAILTO=your@email.com</nowiki>}} '''or''': | |
− | + | #* Add this line to {{ic|/etc/msmtprc}}: {{bc|aliases /etc/aliases}}and create {{ic|/etc/aliases}}: {{bc|your_username: your@email.com<br># Optional:<br>default: your@email.com}} | |
+ | # [[Systemd#Editing_provided_unit_files|Edit]] the {{ic|cronie.service}} unit. For example, create {{ic|/etc/sytemd/system/cronie.service.d/msmtp.conf}}:{{bc|<nowiki>[Service] | ||
+ | ExecStart= | ||
+ | ExecStart=/usr/bin/crond -n -m '/usr/bin/msmtp -t'</nowiki>}} | ||
+ | {{Note|The empty {{ic|<nowiki>ExecStart=</nowiki>}} cancels any previous {{ic|ExecStart}} commands.}} | ||
− | + | ==== Example with esmtp ==== | |
− | + | Install {{Pkg|esmtp}} and {{Pkg|procmail}}. | |
− | + | 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" | ||
+ | }} | ||
− | + | 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 {{ic|message.txt}} with {{ic|"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 {{ic|/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''" | ||
+ | }} | ||
− | Run the following command to make sure it has the correct | + | {{Note|If the above test didn't work, you may try creating a local configuration in {{ic|~/.esmtprc}} with the same content. |
+ | |||
+ | Run the following command to make sure it has the correct permission: | ||
$ chmod 710 ~/.esmtprc | $ chmod 710 ~/.esmtprc | ||
− | + | 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: | ||
− | ==Crontab format== | + | listen on localhost |
+ | accept for local deliver to mbox | ||
+ | |||
+ | You can proceed to test it: | ||
+ | # systemctl start smtpd | ||
+ | $ echo test | sendmail user | ||
+ | |||
+ | ''user'' can check his/her mail in with any [[:Category:Email_Client|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: | ||
+ | # systemctl enable smtpd | ||
+ | |||
+ | This approach has the advantage of not sending local cron notifications to a remote server. Not even network connection is needed. 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 ==== | ||
+ | |||
+ | 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 : | ||
+ | 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 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. | ||
+ | |||
+ | 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: | ||
− | + | ''minute'' ''hour'' ''day_of_month'' ''month'' ''day_of_week'' ''command'' | |
* ''minute'' values can be from 0 to 59. | * ''minute'' values can be from 0 to 59. | ||
Line 92: | Line 150: | ||
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 | + | *0,*5 9-16 * 1-5,9-12 1-5 ~/bin/i_love_cron.sh |
− | Will execute the script {{ | + | 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 | + | 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 124: | Line 182: | ||
# crontab -u ''username'' -e | # crontab -u ''username'' -e | ||
− | This same format (appending | + | This same format (appending {{ic|-u ''username''}} to a command) works for listing and deleting crontabs as well. |
− | |||
− | |||
− | + | == Examples == | |
− | |||
− | |||
− | |||
− | ==Examples== | ||
The entry: | The entry: | ||
Line 138: | Line 190: | ||
01 * * * * /bin/echo Hello, world! | 01 * * * * /bin/echo Hello, world! | ||
− | runs the command {{ | + | 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, | ||
Line 144: | Line 196: | ||
*/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: | As noted in the ''Crontab Format'' section, the line: | ||
Line 152: | Line 204: | ||
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). | ||
− | == | + | == Default editor == |
+ | |||
+ | To use an alternate default editor, define the {{ic|EDITOR}} environment variablee it in a shell initialization script ({{AUR|vim-default-editor}} is available for vim users). For example: | ||
+ | |||
+ | {{hc|/etc/profile.d/nano-default-editor|2=<nowiki> | ||
+ | #!/bin/sh | ||
+ | |||
+ | export EDITOR=/usr/bin/nano | ||
+ | </nowiki>}} | ||
+ | |||
+ | As a regular user, {{ic|su}} will need to be used instead of {{ic|sudo}} for the environment variable to be pulled correctly: | ||
+ | |||
+ | $ su -c "crontab -e" | ||
− | The cron daemon parses a configuration file known as | + | To have an alias to this {{ic|printf}} is required to carry the arbitrary string because {{ic|su}} launches in a new shell: |
+ | |||
+ | alias scron="su -c $(printf "%q " "crontab -e")" | ||
+ | |||
+ | == More information == | ||
+ | |||
+ | 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 160: | Line 230: | ||
{{hc|/var/spool/cron/root | {{hc|/var/spool/cron/root | ||
|2=<nowiki> | |2=<nowiki> | ||
− | # | + | # Run command at a scheduled time |
− | # | + | # Edit this 'crontab -e' for error checking, man 1 crontab for acceptable format |
− | # | + | # <@freq> <tags and command> |
− | |||
− | |||
− | |||
− | |||
@hourly ID=sys-hourly /usr/sbin/run-cron /etc/cron.hourly | @hourly ID=sys-hourly /usr/sbin/run-cron /etc/cron.hourly | ||
@daily ID=sys-daily /usr/sbin/run-cron /etc/cron.daily | @daily ID=sys-daily /usr/sbin/run-cron /etc/cron.daily | ||
@weekly ID=sys-weekly /usr/sbin/run-cron /etc/cron.weekly | @weekly ID=sys-weekly /usr/sbin/run-cron /etc/cron.weekly | ||
@monthly ID=sys-monthly /usr/sbin/run-cron /etc/cron.monthly | @monthly ID=sys-monthly /usr/sbin/run-cron /etc/cron.monthly | ||
+ | |||
+ | # mm hh DD MM W /path/command (or tags) # W = week: 0-6, Sun=0 | ||
+ | 21 01 * * * /usr/bin/systemctl suspend | ||
</nowiki>}} | </nowiki>}} | ||
Line 193: | Line 262: | ||
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 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}}). | |
− | + | == 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 {{AUR|xuserrun}} to do it: | |
− | + | 17 02 * ... /usr/bin/xuserrun /usr/bin/xclock | |
− | |||
− | + | Or then can be defined manually ({{ic|echo $DISPLAY}} will give the current DISPLAY value): | |
− | |||
− | + | 17 02 * ... env DISPLAY=:0 /usr/bin/xclock | |
− | + | If done through say SSH, permission will need be given: | |
− | + | # xhost +si:localuser:$(whoami) | |
− | ==Asynchronous job processing== | + | == 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 {{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 === |
− | + | ||
+ | {{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 === | ||
+ | |||
+ | {{AUR|anacron}} is a full replacement for ''dcron'' which processes jobs asynchronously. | ||
+ | |||
+ | === Fcron === | ||
+ | |||
+ | 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. Like cronwhip, it can run jobs that should have been run during the computer's downtime. | ||
+ | See also the [https://bbs.archlinux.org/viewtopic.php?id=140497 forum thread] | ||
+ | |||
+ | == 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 == | ||
− | + | * [http://gotux.net/arch-linux/crontab-usage/ CronTab Usage Tutorial] | |
− | [http:// |
Revision as of 07:39, 30 August 2013
zh-CN:Cron Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary link Template:Article summary heading Template:Article summary wiki 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.
Contents
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 and 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
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. To log these messages use the -m
option and write a script or install a rudimentary SMTP subsystem.
Example with msmtp
Here are two ways to obtain emails from cronie with msmtp:
- Install the msmtp-mta package which effectively creates a symbolic link from
/usr/bin/sendmail
to/usr/bin/msmtp
. You must then provide a way for msmtp to convert your username into an email address.- Either add a
MAILTO
line to your crontab, like so:MAILTO=your@email.com
or: - Add this line to
/etc/msmtprc
:aliases /etc/aliases
and create/etc/aliases
:your_username: your@email.com
# Optional:
default: your@email.com
- Either add a
- Edit the
cronie.service
unit. For example, create/etc/sytemd/system/cronie.service.d/msmtp.conf
:[Service] ExecStart= ExecStart=/usr/bin/crond -n -m '/usr/bin/msmtp -t'
ExecStart=
cancels any previous ExecStart
commands.Example with esmtp
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"
~/.esmtprc
with the same content.
Run the following command to make sure it has the correct permission:
$ chmod 710 ~/.esmtprcThen repeat the test with
message.txt
exactly as before.Example with opensmtpd
Install opensmtpd.
Edit /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:
# systemctl start smtpd $ echo test | sendmail user
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:
# systemctl enable smtpd
This approach has the advantage of not sending local cron notifications to a remote server. Not even network connection is needed. On the downside, you need a new daemon running.
- 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 :
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 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.
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.
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).
Default editor
To use an alternate default editor, define the EDITOR
environment variablee it in a shell initialization script (vim-default-editorAUR is available for vim users). For example:
/etc/profile.d/nano-default-editor
#!/bin/sh export EDITOR=/usr/bin/nano
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")"
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
# Run command at a scheduled time # Edit this 'crontab -e' for error checking, man 1 crontab for acceptable format # <@freq> <tags and command> @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 # mm hh DD MM W /path/command (or tags) # W = week: 0-6, Sun=0 21 01 * * * /usr/bin/systemctl suspend
These lines exemplify one of the formats that crontab entries can have, namely whitespace-separated fields specifying:
- @period
- ID=jobname (this tag is specific to dcron)
- command
The other standard format for crontab entries is:
- minute
- hour
- day
- month
- day of week
- 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 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 xuserrunAUR to do it:
17 02 * ... /usr/bin/xuserrun /usr/bin/xclock
Or then can be defined manually (echo $DISPLAY
will give the current DISPLAY value):
17 02 * ... env DISPLAY=:0 /usr/bin/xclock
If done through say SSH, permission will need be given:
# 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 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
anacronAUR is a full replacement for dcron which processes jobs asynchronously.
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. Like cronwhip, it can run jobs that should have been run during the computer's downtime. See also the forum thread
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