cron manpage

Search topic Section

CRON(8)			     Cronie Users' Manual		       CRON(8)

       cron - daemon to execute scheduled commands

       cron [-n | -p | -s | -m<mailcommand>]
       cron -x [ext,sch,proc,pars,load,misc,test,bit]

       Cron should be started from /etc/rc.d/init.d or /etc/init.d

       Cron  searches  /var/spool/cron for crontab files which are named after
       accounts in /etc/passwd; The founded crontabs are loaded	 into  memory.
       Cron also searches for /etc/anacrontab and the files in the /etc/cron.d
       directory, which are in a different format  (see	 crontab(5)  ).	  Cron
       examines all stored crontabs, checking each command to see if it should
       be run in the current minute. When executing commands,  any  output  is
       mailed  to the owner of the crontab (or to the user named in the MAILTO
       environment variable in the crontab, if such exists).  Job  output  can
       also be sent to syslog by using the -s option.

       There  are  two	ways,  how  the changes are checked in crontables. The
       first is checking the modtime of file and the other  is	using  inotify
       support.	  You  can  find out which of them are you using, if you check
       /var/log/cron where is (or isn't) inotify mentioned after start of dae-
       mon.  The inotify support is watching for changes in all crontables and
       touch the disk only in case that something was changed.

       In other case cron checks each minute to see if its crontables  modtime
       have  changes  and reload those which have changes. There is no need to
       restart cron after some of  the	crontable  is  modified.  The  modtime
       option is used also when inotify couldn't be initialized.

       Cron  is	 checking  those  files or directories: /etc/anacrontab system
       crontab	is  usually  for  running  daily,  weekly,  monthly  jobs.
       /etc/cron.d/  where  are	 system cronjobs stored for different users.
       /var/spool/cron that's mean spool directory for user crontables.

       Note that the crontab(1) command	 updates  the  modtime	of  the	 spool
       directory whenever it changes a crontab.

   Daylight Saving Time and other time changes
       Local  time  changes  of less than three hours, such as those caused by
       the start or end of Daylight Saving Time, are handled specially.	  This
       only  applies to jobs that run at a specific time and jobs that are run
       with a granularity greater than one hour.   Jobs	 that  run  more  fre-
       quently are scheduled normally.

       If time has moved forward, those jobs that would have run in the inter-
       val that has been skipped will be run immediately.  Conversely, if time
       has moved backward, care is taken to avoid running jobs twice.

       Time  changes  of more than 3 hours are considered to be corrections to
       the clock or timezone, and the new time is used immediately.

       It's possible to use different time zones for cron tables.  More	 could
       be found in crontab(5).

   PAM Access Control
       On  Red	Hat  systems, crond now supports access control with PAM - see
       pam(8).	 A  PAM	 configuration	file  for  crond   is	installed   in
       /etc/pam.d/crond.   crond  loads	 the  PAM environment from the pam_env
       module, but these can be	 overriden  by	settings  in  the  appropriate
       crontab file.

       As a special case, the string off will disable sending mail.

       -s     This  option  will  direct cron to send job output to the system
	      log using syslog(3).  This is useful if your system has no send-
	      mail(8), or if mail is disabled using -m off.

       -m     This  option allows you to specify a shell command string to use
	      for sending cron mail output instead of sendmail(8).  This  com-
	      mand  must  accept a fully formatted mail message (with headers)
	      on stdin and send it as a mail message to the recipients	speci-
	      fied in the mail headers.

       -n     This  option changes default behavior causing it to run crond in
	      the foreground.  This can be useful  when	 starting  it  out  of

       -p     Cron permit any crontab, which user set.

       -x     With this option is possible to set debug flags.

       -P     Don't set PATH.  PATH is instead inherited from the environment.

       On  receipt  of a SIGHUP, the cron daemon will close and reopen its log
       file.  This is useful in scripts which rotate and age log files.	 Natu-
       rally this is not relevant if cron was built to use syslog(3).

       The  crontab  files  have  to  be  regular files or symlinks to regular
       files, they must not be executable or writable by anyone else than  the
       owner.	This  requirement  can be overridden by using the -p option on
       the crond command line.	If inotify support is in use, changes  in  the
       symlinked  crontabs  are	 not automatically noticed by the cron daemon.
       The cron daemon must receive a SIGHUP to reload the crontabs.  This  is
       a limitation of inotify API.

       crontab(1), crontab(5), inotify(7), pam(8)

       Paul Vixie <vixie@isc.org>
       Marcela Malaova <mmaslano@redhat.com>

Marcela Malaova			 December 2009			       CRON(8)