Learn everything about Linux/Unix schedulers i.e. cron and at. Know how to schedule cronjobs and at jobs, their configuration files, log files.
Unix or Linux comes with native in-build job scheduler i.e.
at. Out of which cron used to schedule tasks to repeat over some period while at used to execute the job at a specific time one time.
Cron enables administrators/users to execute a particular script or command at a given time of choice repetitively. It’s a daemon that runs in the background whenever system clock configured time it executes respective script or command. It can be checked if running with ps/service command.
# ps -ef |grep -i cron root 2390 1 0 Mar17 ? 00:01:24 crond root 8129 8072 0 09:50 pts/0 00:00:00 grep -i cron # service crond status crond (pid 2390) is running...
Cron saves commands/scripts and related schedules in a file called
crontab. Normally crontab can be found in path
/var/spool/cron and file with a username (root user crontab file can be seen in the below example). These are plain text files that can be viewed using
more commands and can be edited using a text editor.
# pwd /var/spool/cron # ll total 4 -rw------- 1 root root 99 Jul 31 2015 root # cat root 00 8 * * 1 /scripts/log_collection.sh
But, it’s not advisable to edit crontab file with a text editor, you need to use
crontab -e <username> command to edit it so that syntax can be verified before saving. This command opens a crontab file in a native text editor only.
Cron access can be given a user basis. The administrator can enable or disable cron access to a particular user. There are two files
cron.deny; either one of which will exist on the server. These are files with usernames only. No special file format/syntax follows within. If both files are missing then the only superuser is allowed to use cron.
cron.allow exists on the server then only users specified in this file are allowed to use cron, rest all are denied. And if it exists and empty then all are denied.
cron.deny exists then only users specified in it are not allowed to use cron, rest all are allowed. And if it exists and empty then all are allowed.
Let’s see the syntax for the crontab file and commands.
A crontab file has 6 fields separated by space to be filled in. Those are as below :
- Minute: Timestamp in 24 hrs format
- Hours: Timestamp in 24 hrs format
- Day of month: Date in dd format
- Month: Month number in mm format or Jan, Feb format.
- Day of week: Numeric/text day of the week. 0 or 7 being Sunday or Sun, Mon, etc.
These fields also support a series of values or multiple values example 1,2,3 or 1-4. When multiple time values defined then the event will happen whenever the clock hits one of the values.
Default cron definitions i.e. path or shell used to execute commands/scripts in crontabs etc are defined in
/etc/crontab file. See example below :
# cat /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # For details see man 4 crontabs # Example of job definition: # .---------------- minute (0 - 59) # | .------------- hour (0 - 23) # | | .---------- day of month (1 - 31) # | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | | # * * * * * user-name command to be executed
We have a crontab command with several options to play around configurations.
-lto view specified user’s crontab
-eto edit specified user’s crontab
-rto remove specified user’s crontab
-iInteractive removal. Should be used with -r
If a new crontab is being set then the system will show using empty crontab for the user!
# crontab -u testuser -e no crontab for testuser - using an empty one crontab: installing new crontab # crontab -u testuser-l 00 8 * * 1 echo test # crontab -u testuser -i -r crontab: really delete testuser's crontab? y # crontab -u testuser -l no crontab for testuser
All activities by cron daemon are logged in logfile
/var/log/cron. It includes crontab alterations and cron daemon executions. Let’s look at the file
# tail /var/log/cron Nov 21 10:25:36 oratest02 crontab: (root) BEGIN EDIT (testuser) Nov 21 10:25:48 oratest02 crontab: (root) REPLACE (testuser) Nov 21 10:25:48 oratest02 crontab: (root) END EDIT (testuser) Nov 21 10:26:52 oratest02 crontab: (root) LIST (testuser) Nov 21 10:27:46 oratest02 crontab: (root) DELETE (testuser) Nov 21 10:27:53 oratest02 crontab: (root) LIST (testuser) Nov 21 10:30:01 oratest02 CROND: (root) CMD (/usr/lib64/sa/sa1 1 1) Nov 22 10:40:01 oratest02 CROND: (root) CMD (/usr/lib64/sa/sa1 1 1)
In the above example, you can see, crontab alteration is being logged with what actions took place. Those logs are against the crontab field where first braces show the user who did alterations and last braces show which user’s crontab was altered. In the last two, you can see cron commands being executed by cron daemon according to schedule hence logged against
CROND. This file is very helpful in troubleshooting issues related to cron executions.
At enables administrators/users to execute a particular script or command at a given time of choice only once. It can also be termed as one-time task scheduling. Same as
crond, a daemon for at is
atd which runs in background. This can be checked using ps or service commands.
# ps -ef |grep -i atd root 2403 1 0 Mar17 ? 00:00:00 /usr/sbin/atd root 13568 8072 0 10:51 pts/0 00:00:00 grep -i atd # service atd status atd (pid 2403) is running...
at stores submitted jobs in files located at
/var/spool/at where file names are system generated and unlike crontabs these files can not be read.
# pwd /var/spool/at # ll total 12 -rwx------ 1 root root 2994 Nov 22 10:57 a000010178544d -rwx------ 1 root root 2989 Nov 22 11:00 a000020178548c drwx------. 2 daemon daemon 4096 Jan 30 2012 spool
at access also can be given a user basis. It also has
at.deny files and those works same as
cron.deny files we saw earlier in this post.
at command should be supplied with the time you prefer to execute the command. Once given in proper format, it will present you with a prompt. This prompt takes command inputs that need to be executed at a given time. Once finished entering commands/ scripts one can simply press
ctrl+d to exit out of at prompt and save the job. Observe a new file that is being generated at the above-mentioned path once you submit the job. at commands takes numerous types of time formats like noon, midnight, now + 2 hours, now + 20 minutes, tomorrow, next Monday, etc. If you enter the wrong format it will return the “garbled time” error message.
# at +2 hours syntax error. Last token seen: + Garbled time # at now + 2 hour at> echo hello at> <EOT> job 2 at 2016-11-22 13:00
To view currently queued jobs in at scheduler run
at -l command. It shows the output with numbering in the first column. The second field is about a time when the execution will happen and the last field is the username.
# atq 2 2016-11-22 13:00 a root 1 2016-11-22 11:57 a root # at -l 2 2016-11-22 13:00 a root 1 2016-11-22 11:57 a root
To remove a particular job from queue
atrm command is used. It should be supplied with serial number of the job. In the below example, we removed job number 2. You can see its vanished from the queue. The same can be achieved using
at -r command instead of
# atrm 1 # at -l 2 2016-11-22 13:00 a root
at daemon is very much regressive in terms of logging. Normally it does not log anything anywhere about its job queue alterations or job executions. Only fatal errors related to daemon are logged in Syslog only. Even if we turn debugging on, it logs information which is merely informative to look at.