cron(1M) DG/UX R4.11 cron(1M)
NAME
cron - clock agent
SYNOPSIS
/etc/cron
DESCRIPTION
Cron executes commands at specified dates and times. You can
schedule commands on a regular basis according to instructions found
in crontab files; crontab files are submitted via the crontab
command. You may also schedule commands which are to be executed
only once via the at command. Only a single cron process can be
running at any one time.
NOTE: You must have permission to create crontab files.
Commands that are to be executed only once may be submitted via the
at command. Because cron never exits, it should be executed only
once. This is best done by running cron from the initialization
process through the rc script mechanism (see rc.init(1M)).
On a system with DG/UX information security, cron is a service
initiator which must set the authentication ID (authid) for all cron
sessions it starts. In order to do this, cron must be running with
its authid equal to zero. The only way to accomplish this is to have
cron be started by init (see rc.init(1M)), or by some other mechanism
started from init.
On a system with DG/UX information security, users' cron entries are
kept separately based upon the clearance (MAC label) of the process
submitting the jobs. Thus, a user may have simultaneous cron entries
at different MAC labels.
To keep a log of all actions taken by cron, CRONLOG=YES (by default)
must be specified in the /etc/default/cron file. If CRONLOG=NO is
specified, no logging is done. Keeping the log is a user
configurable option since cron can potentially create huge log files.
You can change the way cron schedules jobs by changing entries in the
queuedefs file. The file has at least two lines, one for the at
queue (a.) and one for the batch queue (b.):
a.XjYnZw
b.XjYnZw
where:
X is the maximum number of jobs allowed to execute simultaneously.
This cannot be set higher than 25.
Y is the nice factor--the job priority number will be raised by
this amount. The higher the number, the less attention the job
gets from the CPU. The maximum nice factor is 20.
Z is how long to wait, in seconds, before trying to reschedule a
queue request when the job queue is full.
The user also can define their own queue definitions. They can be
defined as d through z (c is reserved specifically for cron). The
default limits are set to work as follows:
a.4j1n
b.2j2n90w
If you increase the job limits, be on guard for a potential impact on
system performance, especially on smaller machines or machines having
lots of active users.
On a system with DG/UX information security, cron jobs are run with
the authentication identifier (AUTHID) equal to the originator's
AUTHID and a MAC label of the submitting process. The audit mask is
CRON_DEFAULT, which must always be defined in
/etc/tcb/auditaliasdefs. A value for CRON_DEFAULT is supplied with
the system, but it may be changed as long as it is always a valid
mask.
FILES
/etc/cron.d main cron directory
/etc/cron.d/queuedefs scheduling information
/var/cron/log accounting information (log file)
/var/spool/cron spool area
/etc/default/cron defaults file
/var/spool/cron/atjobs directory containing jobs submitted through
at
/var/spool/cron/crontabs directory containing jobs submitted through
crontab
DIAGNOSTICS
A history of all actions taken by cron is recorded in /var/cron/log.
SEE ALSO
at(1), crontab(1), init(1M), sh(1).
NOTES
Cron(1M) examines crontab files (located in /var/spool/cron/crontabs)
and at command files (located in /var/spool/cron/atjobs) only during
process initialization, when a file has changed, and when the system
date/time/timezone has changed. This reduces the overhead of
checking for new or changed files.
On a system with DG/UX information security, these two directories
are both multilevel directories. This allows users to have
concurrent cron jobs at any level they are authorized to submit cron
jobs at.
Changing the system clock (date/time) or timezone will affect the
execution of jobs specified in the crontab files. If the clock is
moved forward, the jobs scheduled to run during the skipped time
interval will not be run. If the clock is moved backward, the jobs
that already ran during the time interval will be run a second time.
This happens when the system makes automatic time adjustments for
alternate time zones, such as daylight savings time.
Manual clock or timezone changes should be done through admdate or
sysadm so that cron will be automatically restarted.
If the system makes the time adjustment for an alternate time zone,
cron will not notice the change until the next job runs. At that
time, cron will re-initialize itself. To get cron to re-initialize
itself as soon as the system changes to the alternate time zone, you
may create a dummy job that runs when the time change occurs.
For example, in the U.S. Eastern Standard Time Zone, the changes
going into and out of daylight savings time occur at 2:00am, so the
following line could be added to the root crontab file to get cron to
restart when the alternate time zone starts and ends:
00 2 * * * #dummy job to help cron notice DST changes - don't delete
When it runs out of jobs to do, cron(1M) tries to redo jobs it has
already done. This behavior is potentially dangerous, so you should
always keep it busy, preferably with something like uucleanup or a
dummy job.
If you are a non-privileged user, an entry similar to the following
will suffice:
59 23 * * * echo > /dev/null 2>&1
This bug originated in AT&T System V.
Licensed material--property of copyright holder(s)