[dundee] Cron - scared yet?

Colin Brough Colin.Brough at blueyonder.co.uk
Wed May 23 22:46:18 BST 2007


> Oops, I believe I just sent a blank email. I should really sleep sometime soon.
> Apologies everyone
> Anyway, I was wondering, what is everyone's opinion on Cron? I have
> always considered automating certain parts of my system, sit down,
> read a guide and then get distracted. 
> Is it really as scary as it looks? Or is it as straight forward as you would hope?

Its pretty straightforward really. There are minor complications -
different versions of cron on different systems, whether the (Debian
originally, I think) 'runparts' functionality is used, the difference
between the system crontab and an individual users crontab - but once
set up, those are fairly straightforward.

With some guff to make sure PATHs and other variables are set right, a
crontab file is simply a series of lines, each line saying when a
particular job should be run:

	01 * * * * JOB-hourly

This executes 'JOB-hourly' (which is just the name of an executable,
eg a script) at one minute past the hour, every hour.

	13 14 * * * JOB-daily

This executes 'JOB-daily' at 1413 hours every day. ('0 4 * * *' would
do for 4am...)

	00 12 2 * * JOB-monthly

This executes 'JOB-monthly' on the 2nd of every month at 1200 hours.

	30 10 * * 0 JOB-weekly

This executes 'JOB-weekly' at 1030 hours every Sunday.

(In other words '*' is a wildcard, matching any time or day. Specify
enough fields to specify when you want something to happen.)

You can get fancy, doing things like this (from my own crontab):

	2,17,32,47 * * * * gnews

This runs 'gnews' (which is a script on my system to download usenet
news) every fifteen minutes, at 2, 17, 32 and 47 minutes past the
hour...

cron looks at several files for crontabs: /etc/crontab is the system
wide file; its syntax is slightly different - between the timespec
entries described above and the executable there is also a username
(root, cmb, joe...) - the jobs are run with that user's privileges.
And each user can have their own crontab file - jobs in that are run
with the user's privileges. To avoid the possibility of a half-edited
crontab file crashing a running crond, you use the 'crontab' program
to 'install' a suitably formatted file, rather than editing
/etc/crontab or whatever directly. For my own personal crontab file I
edit /home/cmb/tmp/crontab, then run 'crontab ~/tmp/crontab' after any
edits... (Using your own personal crontab this way means you don't
have to invoke root privileges when messing around with personal jobs,
like your own backups.)

For security, by default cron runs with a minimal PATH and nowhere for
errors to be sent to, so you will often see crontab files starting
with things like:

	
	SHELL=/bin/bash
	PATH=/sbin:/bin:/usr/sbin:/usr/bin:/home/cmb/bin/bin:/home/cmb/bin/script
	MAILTO=cmb at localhost
	HOME=/home/cmb

These just make sure the scripts can be found and any error or
progress output is sent to the right place.

> Secondly, I was wondering something, I have a NAS enclosure now, but
> I'm not going to assume that anyone else on the network is going to
> scan it. I therefore set up ClamAV but it's going to be a pain in
> the neck to do it manually all the time. All I was wondering was
> whether anyone knew, assuming I set up crond to do something daily,
> say at 4AM... if my laptop was off at that point, would it do it
> next time it was booted?

anacron is the standard answer to this question. I use it for things
like automating backups, running locatedb updates, etc, as I have a
desktop I switch off overnight. You basically tell it how often you
want something done (eg daily, weekly) and it'll do it the next time
the machine is on. There is a similar timespec, but additionally
anacron tracks when a job was run and if the machine was off when a
job should have been done, it will execute it shortly after anacron
starts up.

> I'm going to have to brush up on my scripting to get this to work
> methinks. I see a lot of... fiddling approaching.

Well, maybe - cron and anacron just run external processes to do the
actual work - and those are often scripts - so as long as the scripts
themselves work, launching them from cron or anacron isn't so hard.

Cheers

Colin

----------------------------------------------------------------------
Colin Brough                             Colin.Brough at blueyonder.co.uk




More information about the dundee mailing list