cron(1M) DG/UX R4.11MU05 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: To create crontab files you must have appropriate privilege,
or your name (UID) must appear in /etc/cron.d/cron.allow. If
that file does not exist, your name must not appear in
/etc/cron.d/cron.deny. See crontab(1) for further
information.
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.
Security Features
On a system with DG/UX information security, cron is a full-fledged
session initiator. When the time comes for a job to execute, cron
contacts credentiald to find out if the job is actually authorized to
run. If so, the credentials assigned to the job are a combination of
those returned by credentiald and those saved by at or crontab. The
combination process is restrictive (credentials which grant
privilege, such as capabilities, are intersected, while those which
restrict privilege, like audit mask, are unioned). cron attempts to
create the session at the MAC label at which the job was submitted.
If this fails, the job does not run-- alternative MAC labels are not
considered. If the job is not authorized, the user is informed via
mail.
Because cron is a session initiator, any users who are to be allowed
to submit jobs must have the proper authorizations created for them
in the A&A database. In order to run jobs via at or batch, the user
will need an authorization for the "at" service. In order to run
jobs via crontab, the user will need an authorization for the
"crontab" service.
On DG/UX systems with B2-level security, a session control daemon
must be present in order to successfully invoke other session
initiators such as su or assume from within an at or crontab job. If
the subsession limit attribute of the user's at or crontab
authorization is greater than 0, then cron will start a sesctld for
the user. If the subsession limit is 0, no session control daemon
will be started, and attempts to run other session initiators from
the job will fail.
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), credentiald(1m), crontab(1), init(1M), sesctld(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)