• Choose a category
• All
• Classic-Fiction

In this entry, we redirect the standard output, but allow the standard error to be sent as a mail message. This can be a nice feature because we'll get a mail message if anything goes wrong. If you want to make sure you don't receive mail under any circumstances, redirect both the standard output and the standard error to a file:

0 1 * * * find /tmp -atime 3 -exec ls -l { } \; >> /home/mdw/log 2>&1

When you save output in a logfile, you get the problem of a file that grows continuously. You may want another cron entry that runs once a week or so, just to remove the file.

Only Bourne shell commands can be used in crontab entries. That means you can't use any of the convenient extensions recognized by bash and other modern shells, such as aliases or the use of ~ to mean "my home directory." You can use $HOME, however; cron recognizes the $USER, $HOME, and $SHELL environment variables. Each command runs with your home directory as its current directory.

Some people like to specify absolute pathnames for commands, such as /usr/bin/find and /bin/rm, in crontab entries. This ensures that the right command is always found, instead of relying on the path being set correctly.

If a command gets too long and complicated to put on a single line, write a shell script and invoke it from cron. Make sure the script is executable (use chmod +x) or execute it by using a shell, such as:

0 1 * * * sh runcron

As a system administrator, you often have to create crontab files for dummy users, such as news or UUCP. Running all utilities as root would be overkill and possibly dangerous, so these special users exist instead.

The choice of a user also affects file ownership: a crontab file for news should run files owned by news, and so on. In general, make sure utilities are owned by the user in whose name you create the crontab file.

As root, you can edit other users' crontab files by using the -u option. For example:

tigger # crontab -u news -e

This is useful because you can't log in as user news, but you still might want to edit this user's crontab entry.

Executing Jobs Once

With cron, you can schedule recurring jobs, as we have seen in the previous section. But what if you want to run a certain command just once or a limited number of times, but still at times when it is inconvenient to type in the command interactively? Of course, you could always add the command to the crontab and then remove it later, or pick a date selection that only applies very rarely. But there is also a tool that is made for this job, the at command.

at reads commands to be executed from a file or from standard input. You can specify the time in a number of ways, including natural-language specifications such as noon, midnight, or, interestingly, teatime (which, much to the dismay of British users, maps to 4 p.m.).

For at to work, the at daemon, atd, needs to run. How it is started depends on your distribution: rcatd start and /etc/init.d/atd start are good tries. In a pinch, you should also be able to just run /usr/sbin/atd as root.

As an example, let's say that you want to download a large file from the Internet at midnight when your ISP is cheaper or when you expect the lines to be less congested so that the probability of success is higher. Let's further assume that you need to run a command connectinet for setting up your (dial-up) Internet connection, and disconnectinet for shutting it down. For the actual download in this example, we use the wget command:

tigger$ at midnight

warning: commands will be executed using /bin/sh

at> connectinet

at> wget ftp://overloadedserver.lotsastuff.com/pub/largefiles/reallylargefile.bz2

at> disconnectinet

at>

job 1 at 2005-02-26 00:00

After typing at midnight, the at command first tells us that it is going to execute our commands with another shell (we are using the Z shell for interactive work here, whereas at will be using the Bourne shell) and then lets us enter our commands one after the other. When we are done, we type Ctrl-D, which at shows as