Linux Crontab

Introduction to Linux Crontab

Crontab – If you have a server-heavy website at present, you may be looking to run certain processes like enriching data or generating thumbnails in the background, without interfering with the user interface. Well, Linux crontab has a good program that does exactly that: Cron.

So what is this program? Cron is categorized as a daemon that can execute scheduled commands. It is automatically started when entering multi-user run levels, from /etc/init.d. It searches the spool area at /var/spool/cron/crontabs for crontab files named after the accounts in /etc/passwd. To access the crontabs in this directory, you need to use the crontab command instead of directly accessing them. Cron can also read the slight different format of /etc/crontab, as well as files in /etc/cron.d.

Once configured, Cron wakes up every minute, examines stored linux crontabs and checks command to see if there is anything to be executed. If a command is executed and output is generated, the output is then mailed to the crontab’s owner or the user in the MAILTO variable in the crontab. The children copies of the cron that runs these processes are named in uppercase, which you will see in the ps and syslog output.

Cron also checks every minute for changes in the modtime of the spool directory. If there are changes, it then examines the modtime of all linux crontabs and reloads the ones that have changed. As a result, cron does not have to restart when a crontab file is changed.

When the clock is changed by three hours or less, special considerations exist like at the start and end of daylight savings time. If the time moves forward, the jobs to have run in the skipped time will be altered to run soon after the change. On the other end, if the time moves backwards, the jobs that fall in the repeated time will not be rerun.

Only jobs that run at a specific time rather than hourly jobs or those marked with the ‘*’ in the minute/hour specifier are affected. Jobs specified with wild cars are immediately run based on the new time. In case of clock changes of more than three hours, the new time is immediately used.

In Red hat and Debian, cron treats the cron.d files as extensions to the linux crontab file since they follow the special format of the file, which means that they include the user field. This feature aims to allow packages that require finer scheduling control than daily, monthly or weekly directories. Such files should ideally be named after their supplier packages. Files must conform to the naming convention used for run-parts, in that they need to solely consist of upper-case and lower-case letters, digits, hyphens and underscores. The files in the cron.d directory are monitored for changes, just like the linux crontab directory. For commands like /bin/ls, make sure to use absolute path names to call the right command.

Linux Crontab

Now that you know the ins and outs of it , let’s look closely at this, which is a program for install, uninstalling or listing the tables to drive the daemon itself. Each user can have a linux crontab of their own and the files are available in the crontabs directory, but not meant for direct editing.

Any command given in a linux crontab of a user will be executed as the user owning it. Tabs, leading spaces and blank lines are typically ignored. Lines that have a hash-sign as the first non-space character are ignored as they are treated as comments. It is worth noting that comments are not allowed within the same lines of cron commands as they will be read as part of the command. On a similar note, comments are also not allowed on lines with environment variable settings.

In a linux crontab, an active line with be a cron command or environment variable setting, which is in the form “name=value”, where spaces can be added if needed around the equal-to sign. Any subsequent non-leading spaces are part of the name value. The value string could be placed in single or double matching quotes for preserving trailing or leading blank spaces. It is not parsed for environmental substitutions, so you may find that lines like “PATH = $HOME/bin:$PATH” will not work as expected.

Many environmental settings are automatically set up by cron, like HOME and LOGNAME being set from the passwd line of the user and SHELL being set to /bin/sh and PATH being set to /usr/bin:/bin. You can override PATH, SHELL and HOME by crontab settings. LOGNAME cannot be changed, though, since it is the user from which the job is running. On BSD systems, this variable may be called USER, in which case USER will also be set.

If sending mails is part of the commands being run in the linux crontab, it will also look at MAILTO. If the variable is defined and non-empty, a mail is sent to the named user. But if it is empty, no mail is sent and a mail is instead sent to the linux crontab owner. If the cron.allow file is available, then you need to be listed in it for using this command. If this file does not exist but a cron.deny file exists, then you should be removed from that file to use the command. If neither file exists, only the superuser will be able to use the command depending on site-dependent parameters. Alternatively, all users will be able to use the command, which is the case for standard Debian systems.

If the –u option is available, it gives the user name whose linux crontab requires tweaking. If not given, then it examines the crontab of the user executing the command. It is important to use this option always for the sake of safety when running inside of su, since it can be confused by su. The -l option is available for the current crontab to be displayed on the standard output, while the -r option removes the current crontab. The e-command is used for editing the current linux crontab using editors specified by the EDITOR or VISUAL environmental variables. You cannot use any editor that unlinks and recreates the file; you need an editor that edits the file in place. After exiting the editor, the tweaked linux crontab will be automatically installed.

The pam_env module is also supported by cron on the Debian GNU/Linux system, loading the environment as specified in the module file. However, it should be noted that the PAM setting does not override the above-mentioned settings or the crontab file settings. If you want a PATH different from the bin location, you need to set it up in the crontab file. Cron will, by default, send mails using the ‘text/plain’ content type with the character set parameter set to the codeset/character map of the locale where the cron has started up, which is the default system locale without any environment variable set, or the locale that the variables set up. You can add your own character encodings for the mail output by setting the variables ‘Content_Transfer_Encoding’ and ‘Content_Type’ in the crontabs to match the mail headers of the names.

Working on Crontab

The crontab command, found in Unix-like and Unix operating systems, can be accessed through a terminal. To see what crontab is currently running, open a terminal on your system and run the following command:

$ sudo crontab -l

To edit the crontab job lists, you can use the following command:

$ sudo crontab -e

This command opens the default editor in your system, which could be pico or vio, to change the crontab. To save the crontab job on your crontab file, save and exit the editor. Crontab jobs or cronjobs can be written like so:

* * * * * /bin/execute/this/script.sh

There are five asterisks in the above command, with each one representing different date parts to schedule the job. Here they are:

1. Minute, ranging from zero to 59
2. Hour, ranging from zero to 23
3. Day of the month, ranging from one to 31
4. Month, ranging from one to 12
5. Day of the week, ranging from zero to six, with zero meaning Sunday

The above list has been given in order, so you have to define the minute first, followed by hour, day of the month, month and day of the week. You can keep the asterisk if you do not want to define any of fields, but it’s important to note that the symbol means ‘every’. If you leave all five fields undefined with the asterisks intact, it means every minute of every hour, in every day of every week and every month.

Now, let’s assume you want to just execute a script every noon on a Sunday, here is what you do:

0 12 * * 0 /bin/execute/this/script.sh

Now, the script is executed when the system clock hits 1200 hours every Sunday, every week of every month. Now, if you want to execute the script every workday at 12 noon, here is what you write:

0 12 * * 1-5 /bin/execute/this/script.sh

The cron executes commands when the year, month, hour and minute fields match the current time, or when at least the day of month and year match the current time. A field may be marked with an asterisk to denote ‘first-last’. Number ranges are allowed, with the ranges being two numbers that are separated by a hyphen. The specific range is inclusive, so a range of 8-11 for ‘hours’ specifies execution at the eighth, ninth, tenth and eleventh hours. Lists are also supported, with each number separated by commas, like ‘1,2,8,9’. You can mix and match too, so it could be ‘1,2,8-11’.

You can use step values in conjunction with the ranges, with the ‘/’ after a range specifying a skip of the value of the number through the range. For instance, ‘0-11/2’ in the hours field specifies command execution every other hour, which would be written as a list like so: ‘0,2,4,6,8,10’. Steps can be permitted after an asterisk, like ‘*/2’ to indicate a command to be performed every two hours. For the day and month fields, you can use the first three letters of that particular day or month, and the case does not matter. However, lists and ranges of names are not supported. The day of execution can be specified in two fields: day of the week and day of the month. If both fields are restricted, the command will run when either field matches.

The rest of the line is the ‘sixth’ field, which specifies the command to be run. The command portion of the line takes up to a newline or up to % character. It is executed by the sh or by the specified shell in the crontab file’s SHELL variable. The % in the command will be changed to newline characters unless they are escaped with the backslash ‘\’. All the data after the first % sign is sent as standard input to the command. You cannot split one command line into multiple lines.

Scheduling Tricks on Crontab

The formatting can take some getting used to, but here are some tricks to help you out. If you want to run a cronjob every ten minutes, you can either write it this way:

0,10,20,30,40,50 * * * * /bin/execute/this/script.sh

Or you can write it this way, which is easier:

*/10 * * * * /bin/execute/this/script.sh

You also have special words that you can add for the first minute field instead of a number, like so:

• @reboot: this would run the script once at system startup
• @yearly: to run the command once a year (the alternative format would be “0 0 1 1 *”)
• @annually: an alternative to the yearly keyword
• @monthly: to run the command once a month (“0 0 1 * *”)
• @weekly: to run once a week (“0 0 * * 0”)
• @daily: to run once a week (“0 0 * * *”)
• @midnight: an alternative to the daily keyword
• @hourly: to run every hour (“0 * * * *”)

Output storage

By default, the cron saves the output of the job to the user mailbox or root. But you can make the output simpler and more presentable by saving it in a separate log file. This is how you do it:

*/10 * * * * /bin/execute/this/script.sh >> /var/log/script_output.log 2>&1

Linux is capable of reporting on various levels. You have standard errors STDERR and standard output STDOUT, marked as 2 and 1, respectively. The following statement tells to store the STDERR and STDOUT both, to create a single data stream of messages and errors:

2>&1

So we’ve defined the output stream, we now have to give it a destination. The ‘>’ overwrites the file and ‘>>’ appends to it. For appending, which is always safer, you can use the following command:

>> /var/log/script_output.log

Conclusion

As you can see, cron allows you to set tasks to automatically run at regular intervals in the background. This enables automated creation of backups, scheduling of updates, syncing of files and much more. You can do all that and more with crontab.