[K12OSN] cron & crontab (was Re: Presentation Freezing)

[Michael C Wescott]

cron(8) is a program designed to run other programs periodically. It is
controlled by some configuration files called "crontabs" that come in
two flavors. One type of crontab file lives as /etc/crontab or as a file
in the /etc/cron.d directory. The second type lives in the
/var/spool/cron directory and takes the name of it's owner.

crontabs of the first kind have the 6th field indicating the user whose
privileges with which the command will run. These crontabs should be
considered as system files. Don't change them unless you really know
what you are doing. The ones in /etc/cron.d are usually specific to some
package. I don't see any in a k12ltsp system I've got available but my
home system (Debian) shows several all associated with a particular
package:

	~ $ ls /etc/cron.d
	anacron  logcheck  sendmail  uucp
	~ $ 

Having a directory with a package-specific crontab makes it easy for a
package to install cron entries without trying to edit one or more
standard crontabs.

These system crontabs can be editted with any text editor.

A user (including root) should find his crontab in /var/spool/cron.
These crontabs don't use the username in the sixth field since all
commands in that file will be run with the user's privileges. These
crontabs should be installed, removed and editted using the crontab(1)
command. For details on the format see crontab(5), but briefly there are
two types of lines (other than empty or comment lines). One sets an
enviroment variable and looks like:

ENVVAR = some value

The other type has at least 6 whitespace separated fields. The first 5
determine when the command should be run. The 6th (and following) are
treated as a command line and executed by a shell, much as if it had
been run with  /bin/sh -c "command line".

The rules for exactly when to run the command can be fairly complicated
so read the man page crontab(5) more than once.

The current version of cron(8) is quite good about "doing the right
thing" but it wasn't always so. In olden times (i.e some Unix systems)
had some very interesting bugs that popped up when a command was
scheduled to be run when daylight savings time changed.

On Fri, 2005-02-18 at 13:11, Rob Owens wrote:
> No commas in the crontab file (at least not in mine).

A comma is a separtor within a time field but not between different
fields. Whitespace is used between fields.

15,45    9-11,13-16    *     *     1-5    echo "working hours"

Will execute the command 'echo "working hours"' every hour at 15 and 45
minutes after the hour between 9 and 5 pm (not including a lunch break
at noon) on every weekday.

> Here is a sample that I pulled from "man crontab".  In
> my crontab file, the 6th field is usually "root" --
> the user whose account will run the specified command.

Err ... no, the sixth field only shows up in the special crontabs that
you really don't want to mess with.

> The ">> $HOME/tmp/out 2>&1" part means to send all
> output, errors and otherwise, to a file: $HOME/tmp/out

Close. The ">> $HOME/tmp/out" part means to append stdout (the normal
output of the command) to $HOME/tmp/out. The 2>&1 part means to do to
stderr (usually error messages) whatever was done to stdout.


> Brandon Kovach <bkovach at lrhs.greene-r8.k12.mo.us> wrote:
> 
> This will be my first effort at cron, so please
> confirm that this is how 
> the cron file should be setup.

> 0, 23, *, *, 1-5, del /tmp/*.*

Lose the commas. Don't you mean "rm" rather than "del"? And *.* will
match any file with a dot in it, except those starting with a dot. I
think you probably want

0   23  *  *  1-5  /bin/rm -f /tmp/*

or more likely

0   23  *  *  1-5  /bin/rm -r -f /tmp/*

The bad part about this kind of blanket removal of files from /tmp is
that it is difficult to know when other programs, say other cron jobs,
might be using /tmp.

> Then I would name the file tmpremove.cron
> Then I would do a crontab -l to make sure I had no
> files of the same name.
> Then I would crontab tmpremove.cron to activate the
> file.
> Is this all correct?

Nope. First create a copy of your current crontab; then edit it; then
install it as the new version:

	[root at drbob root]# crontab -l > xxx.cron
	[root at drbob root]# vi xxx.cron
	[root at drbob root]# crontab xxx.cron

or combine it all into one step:

	[root at drbob root]# VISUAL=vi crontab -e


-- 
	Mike Wescott