This is very easy to set up – although, later, I shall use a slightly complicated example to illustrate its use.
If you have several users configured on your machine, each user gets their own independent schedule which they can configure.
Experienced users will recognise this as a description of Cron, pre-installed on virtually all Linux machines. The use of cron by root is somewhat different, and is used by some system functions – so we shall ignore the use of cron by root.
Each user specifies their schedule via a “crontab” which can be listed or edited via the crontab command. We can list our crontab with the crontab -l command:
You will always find these descriptive comments in your crontab – and you should retain them. To customise your crontab you need to add one (or more) lines containing time information and a command (or script) to be run.
Cron runs as a background daemon, and will run your command(s) at the appropriate times.
Note: your commands will be run under your user privileges; it isn't possible to gain elevated privileges by using sudo, etc.
There are 5 fields to specify the date – and the formats can be made quite complicated.
The separator between each of the five fields is always one or more spaces (or tab characters). Individual fields may contain complicated specifications such as 1-5,10-15 (but are usually either an asterisk or a single number). The hyphens and comma are not to be considered as field separators.
Each one is typically a number of units. So, for example, 2,4,6 means run at 2 units, 4 units, and 6 units. Another variation is 2-5 which is the same as 2,3,4,5. If we want to run on every valid occasion, we should specify a *. Writing something like */10 means run once every 10 units (so */10 in the minutes field means run at 00,10,20,30,40,50 minutes past the hour).
We may also use names in those fields where it makes sense.
As if this wasn’t enough, combinations are allowed e.g: 1-3,7,9 is equivalent to: 1,2,3,7,9
1st field Minute of the hour (0 - 59)
2nd field Hour of the day (0 - 23)
3rd field Day of the month (1 – 31)
4th field Month of the year (1 – 12 or feb, jun, etc)
5th field Day of the week (0 – 7; both 0 and 7 mean Sunday, or names: mon, tue, wed, etc).
Examples
First, a bad example – this would run only if 13th June is a Monday (next occurs in 2016)!
0 1 13 jun mon some-command
More sensibly,
0 1 13 * * some-command
This would run at 01:00 on the 13th of each month.
Suppose you want to log problems with a very bad connection, using a user-written script named .whatip.sh which is a (hidden) file in the home directory, you might run the following:
*/10 * * * * [ -x .whatip.sh ] && bash .whatip.sh 2>/dev/null
This runs every 10 minutes. The [ -x .whatip.sh ] command tests that the executable file exists, and only if this is true does the && permit running of the script (which writes to a log file); the 2>/dev/null causes any output to be ignored.
Despite the wealth of possibilities in specifying the time a job is to be run, there are certain specifications which can't be easily specified, such as “run on the last day of the month”. For such cases a run specification of something like:
0 1 28-31 * * some-script
would be suitable – with the script making an early exit if it isn't actually the very last day of the month.
Editing crontab: using the crontab -e command.
This will almost certainly not use your normal editor, such as gedit, but a more basic one – such as nano. This is perfectly good for editing configuration files and works in a non-GUI environment.
You still have keys such as insert, delete, backspace. Screen navigation (up, down, etc) is via cursor keys and page-up, page-down keys. However, you don't have scroll bars of any sort.
The function keys are listed across the bottom – but you need only two of those listed.
Scroll down to the last line and enter your changes to your crontab.
I understand that the very last line must end with a newline – this may not be necessary.
Check, then press CTRL+O to write out your changes.
Finally, press CTRL+X to exit.
If you want to disable a crontab specification, comment it out by inserting a # in the first position.
It's quite hard to come up with a crontab line which does useful work, without turning it into a script – but I do have a useful example (the credit for this belongs to an unknown author).
First the problem: If you move a fair number of files around, then Nautilus will create a small thumbnail file for it. If you move the file, you get another thumbnail, and if you look at your system directories you will generate many thousands of thumbnails. The problem is that Nautilus never deletes thumbnails.
To check if you have a problem, enter the following command:
du -sbh .thumbnails
I get a value of 20M i.e. 20MBytes (that's roughly 1,000 thumbnails). You might see a much larger value.
The solution: Every day I run a cron job to delete thumbnails which were last accessed more than 7 days ago. The command part in the crontab is:
find ~/.thumbnails -type f -atime +7 -exec rm '{}' \;
It is critical that the command is entered exactly as shown including the trailing \;
Because this command includes the rm (remove file) command, you may like to test it first by running another closely associated (and harmless) command in a terminal window:
find ~/.thumbnails -type f -atime +7 -exec ls '{}' \; | more
Note the replacement of the rm command by the ls command.
Once you are happy with the operation, you can enter a time specification and the command containing the rm operation into your crontab. Obviously you may want to change the value of +7 to suit your machine. My crontab entry reads:
45 19 * * * find ~/.thumbnails -type f -atime +7 -exec rm '{}' \;
Or, each evening, at 19:45 remove excess thumbnails.
If you have multiple users, you will need to repeat for each one.
Your crontab is actually stored in a sub-directory of the /var directory – so a system upgrade where you choose to replace all your system files (even if you retain your /home directory) will cause your crontabs to be lost. However, it is important that you edit your crontab only via the crontab command, as this incorporates some important error checking.
Excursionary note
If you have not performed an install which involved overwriting your /home directory in the last year or two, then the thumbnail removal entry may work slightly differently – but the difference is marginal and rather historical.
Originally, in addition to setting creation and modification timestamps on files, Linux always recorded file access timestamps (this is the -atime in our crontab entry). This can be inefficient, since reading a file always caused an additional write (to update the access timestamp). It is now possible to indicate that you don't want any atime updates to take place – and this is the current default.
Note that frequently accessed directories would always be looked at more often than every 7 days and so (under the old scheme), their thumbnails would never be deleted. Under the new scheme, atime is never updated, and so even these thumbnails would be deleted and very quickly recreated every 7 days. It's not a noticeable problem for thumbnails – although I understand one or two older applications find the atime change to be a problem.
To check your setting enter:
cat /etc/fstab | grep /home
into a terminal screen; I get 2 lines displayed.
# /home was on /dev/sda7 during installation
UUID=0648d2d1-9a41-4257-8b79-dfc7bc227e82 /home ext3 defaults,noatime 0 2
(My /home is mounted as ext3 – yours is probably ext4).
I have manually changed /etc/fstab to mount everything as noatime – which means no access timestamps are updated, just like the modern default. If you don't see noatime listed, or you see atime in its place, you should consider modifying your fstab file to use the noatime option unless there is a special reason not to.