BCS Technology Limited
Web Site: https://www.bcstechnology.net
In the UNIX or Linux environment, it is possible to asynchronously execute tasks at any desired time of the day, a feature made possible by the cron clock daemon. In the following text we will present some general information on how to use cron and its companion at, as well as some tips on avoiding problems. Although this discussion is geared toward the SCO OpenServer implementation of cron, the basics are applicable to all modern UNIX implementations.
Succinctly stated, cron's role is to spawn jobs in accordance with the passage of time. cron itself is normally started at boot time when the system switches to multiuser operation and once started, never stops unless it is manually killed or the system is halted. cron is slaved to the system clock and awakens at one minute intervals to start scheduled jobs (which are referred to as cron jobs).
When the time arrives to start a job, cron spawns a shell in which to run the job, thus allowing the job to execute independently of cron itself. A cron job executes with the identity and privileges assigned to the system user who scheduled the job. As a general rule, cron jobs are arranged to automatically die when they have finished their work. However, this is not an absolute requirement.
In order to know what is scheduled to run, cron reads text files called cron tables, which authorized users may generate and maintain. cron table maintenance is accomplished with the crontab command. Of the various crontab invocations, crontab -e and crontab -l are most often used, the former to create or edit a cron table and the latter to display it. On most systems, crontab -e will automatically start the vi text editor and if a cron table already exists, load it into vi. Upon saving and exiting from vi, the new or revised file will be submitted to cron, overwriting the existing cron table.
Like other UNIX files, each cron table is owned by the user who created it, and excepting root, can only be edited or viewed by its owner. root can edit any user's cron table with the invocation crontab -u <user> -e or display any table with crontab -u <user> -l, where <user> is a UNIX username. A user may remove his or her cron table with the command crontab -r. root is allowed to remove anyone's cron table.
Scheduling is quite flexible. Permissible values for the date and time fields are as follows:
Any text following an octothorpe (#) is treated as a comment and ignored by cron. Reasonably terse comments are recommended. All parameters must be separated by at least one space or tab (tabbed columns are suggested for clarity).
Here's a cron table entry example:
Theoretically, it is possible to execute any UNIX script or program with an entry in a cron table. However, the execution environment into which a cron job is spawned is very limited in scope, being determined by the parameters in the /etc/default/cron file, as well as the rights of the user owning the cron job. In most cases, the default shell will be the Bourne shell (or bash on Linux systems) and the default path will be limited to /bin, /usr/bin and on OpenServer, /usr/lbin. Therefore, the first thing your cron job script should do is set up a suitable environment, such as augmenting the path definition, defining a subdirectory for temporary file storage, and so forth.
As stated before, a cron job inherits the identity and access privileges of the owner of the cron table from which the job was spawned. It is essential you understand this characteristic of cron, as you may run into trouble with your program if it is denied access to a directory or file due to ownership and access rights. Similarly, be sure your cron job correctly sets the umask value so that any files that are created inherit the correct permissions. As always, information about how your system implements cron can be gleaned from local man pages.
Another possibility is to E-mail your cron job's output to a remote user by piping the output to the mail command. For example:
Alternatively, you could say:
<time> can be in several forms, such as 12 or 24 hour clock time, a date and time, an offset to the current time (e.g., now + 5 minutes) or similar. Again, see your local man pages for details.
As with cron, at's execution environment is limited in scope, and the rights assigned to the at job will be the same as those belonging to the invoking user. If your at job cannot get access to something because of insufficient privileges it will complain via local mail.
Got something to add? Send me email.
More Articles by Steggy © 2014-06-19 Steggy
There is no reason anyone would want a computer in their home. (Ken Olson, president, chairman and founder of DEC)