2004/11/29
No Comments
Reading time: 5 – 8 minutes
Em vaig trobar un article sobre una eina molt bàsica per tots els que usem Linux, el crontab, una eina que tothom es pensa que domina i sovint ens trobem que no sabem programar algunes tasques que són ben fàcils d’automatitzar. Adjunto aquest article des de migraineheartache. M’agrada l’article perquè no és llarg i és molt pràctic. O sigui, que malgrat estar en anglès crec que és molt útil com a eina de consulta o d’instroducció/formació sobre aquest tema.
On a UNIX system there is always some things that should be done periodically, for example backups, locatedb updates and such things. This makes life easier, as you don’t have to keep all the things you should do in your head, or on silly little notes on your desk. Not to mention the fact that you don’t want to sit up all night doing backups.
The CRON daemon
The nice program that makes this possible is the cron daemon. It runs all the time the system is up and every minute it wakes up to see if there is something that should be done. If there is, it spawns a shell that executes some command. I’ll describe the most used cron package on Linux systems, Vixie Cron. Check out http://www.vix.com for some more interesting software.
Crontab’s
To instruct the crond when to do what, you use crontabs. Like many other programs, cron has a system and a per user crontab. They both have a similar format, with some small differences. What you do in the crontab is to give the minute, hour, day of month and/or day of week a specific command should be run.
The system crontab
The system wide crontab is most often called /etc/crontab. This file should have only important jobs, the file is only writable by root. Mine looks something like this:
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file.
# This file also has a username field, that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/etc/ppp
# m h dom mon dow user command
44 5 * * * root run-parts /etc/cron.daily
07 5 * * 7 root run-parts /etc/cron.weekly
00 5 1 * * root run-parts /etc/cron.monthly
As you can see, there is seven fields with information. They are, in correct order: minute, hour, day-of-month, month, day-of-week, user and command. Some of the fields contain stars (*) which means any value will fit. The first line of my file tells cron that every day (the fields day-of-month, month and day-of-week have stars, so cron doesn’t care about them) at 05:44 in the morning I want the command “run-parts /etc/cron.daily” to be run. The command run-parts checks a directory for files that are executable by the user specified in the user field. It runs all of them, in some kind of order 🙂 This is a good way of getting a lot of small things done without writing a big script. Makes it a lot easier maintaining the jobs. My /etc/cron.daily have the following files:
calendar* standard* sysklogd* find* man* netbase* smail* tetex-bin*
So every morning at 05:44 my computer starts doing things like rotating my logs, updating the manual index files, updating the updatedb database and other things that is quite good if you do once a day. At 05:44 I usually don’t use my computer anyway (I do actually sleep sometimes ! 😉 ) so these jobs don’t use any CPU – time I could need. The other lines work just as the first, executing things every week and every month. There is a user field, if you put another user than root there, it will run the command with other rights than root. That is often recommendable by security reasons.
The per – user crontab
Every user on the system may write his own crontab. The job will be executed even though the user is not logged on. The format is similar to the system crontab, though there is not user field, since a user’s cron commands will always be executed as that user. My personal crontab looks like this:
10 5 * * 0 futility tool "+delete" "keep+1300" ; futility pack
5 3 * * * /home/erik/bin/mirroring
15 0-23/1 * * * /usr/bin/fscan
As you can see, it has three jobs. The first one goes every Sunday (Day of week field has the value 0, which is Sunday. I could write ‘Sun’ there too) and does some packing of my fidonet message base. The second goes every day at 5 minutes past 3 in the morning and mirrors some ftp archives. The third executes 5 minutes past every hour 24 hours a day. The syntax 0-23/1 tells cron it should do it once an hour from hour 0 to hour 23. 0-14/2 would mean twice an hour from 00:00 to 14:00 in the afternoon.
The crontab command
When a user wants his own crontab, he has to install it. This is done with the command crontab. The syntax is quite simple, crontab name-of-crontab will install the file you specified as your new crontab. The command crontab has some other switches, to list, edit or remove crontabs, but the basic syntax is actually all you need to know – If you want to edit you crontab, do so and reinstall it with a new crontab command.
Environment variables and file rights.
There are a few things one should think of when trying to master cron. First cron doesn’t read your login files to set the path you’re used to, so a command that executes just fine when you test it may not run at all because cron can’t find some file. There are two solutions to this problem, the first is to use only absolute filenames (ie give the whole path to the files), the second to include something like this:
PATH = /usr/local/bin:/home/foo/bar
That way you set the environment variable PATH, so your scripts will find the files. Another environment variable of interest is MAILTO. If you set that variable (the same way as you set PATH) cron will mail the output of your commands to the address specified. Cron will by default mail the output to the user the crontab belongs to, but if you want the mail to go somewhere else you may specify it in the variable. You may also give an empty MAILTO variable (by writing “MAILTO=” in your crontab). Cron won’t mail any mails to an empty address. File rights can sometimes be a problem. If cron doesn’t want to execute your scripts or programs, try giving the group or world execution rights to the file. That may solve the problem. The irritating thing is cron won’t tell you it can’t execute, it just sits there doing nothing.
