Home : Computers : Linux : Man Pages : cron



       crond [-c | -h | -i | -n | -p | -P | -s | -m<mailcommand>]
       crond -x [ext,sch,proc,pars,load,misc,test,bit]


       Cron  is  started  from  /etc/rc.d/init.d or /etc/init.d when classical
       sysvinit scripts are used. In case systemd is enabled, then  unit  file
       is  installed  into  /lib/systemd/system/crond.service  and  daemon  is
       started by systemctl start crond.service command.  It  returns  immedi-
       ately,  thus, there is no need to need to start it with the '&' parame-

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

       There are two ways how changes in crontables are  checked.   The  first
       method  is  checking the modtime of a file.  The second method is using
       the inotify support.  Using of inotify is logged in  the  /var/log/cron
       log  after  the  daemon  is  started.   The  inotify support checks for
       changes in all crontables and accesses the hard disk only when a change
       is detected.

       When  using  the  modtime  option, Cron checks its crontables' modtimes
       every minute to check for any changes and reloads the crontables  which
       have  changed.   There  is  no  need  to restart Cron after some of the
       crontables were modified.  The modtime option is also used when inotify
       can not be initialized.

       Cron checks these files and directories:

              system  crontab.  Nowadays the file is empty by default.  Origi-
              nally it was usually used to run daily,  weekly,  monthly  jobs.
              By  default  these  jobs are now run through anacron which reads
              /etc/anacrontab configuration file.  See anacrontab(5) for  more

              directory  that  contains  system  cronjobs stored for different

              directory that contains user crontables created by  the  crontab

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

       It is possible  to  use  different  time  zones  for  crontables.   See
       crontab(5) for more information.

   PAM Access Control
       Cron  supports access control with PAM if the system has PAM installed.
       For more information, see pam(8).  A PAM configuration file  for  crond
       is installed in /etc/pam.d/crond.  The daemon loads the PAM environment
       from the pam_env module.  This can be overridden by  defining  specific
       settings in the appropriate crontab file.


       -h     Prints a help message and exits.

       -i     Disables inotify support.

       -m     This  option  allows  you  to specify a shell command to use for
              sending Cron mail output instead of using sendmail(8) This  com-
              mand  must  accept a fully formatted mail message (with headers)
              on standard input and send it as a mail message to  the  recipi-
              ents  specified  in the mail headers.  Specifying the string off
              (i.e., crond -m off) will disable the sending of mail.

       -n     Tells the daemon to run in the foreground.  This can  be  useful
              when  starting  it  out  of  init. With this option is needed to
              change  pam   setting.    /etc/pam.d/crond   must   not   enable
              pam_loginuid.so module.

       -p     Allows Cron to accept any user set crontables.

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

       -c     This option enables clustering support, as described below.

       -s     This  option will direct Cron to send the job output to the sys-
              tem log using syslog(3).  This is useful if your system does not
              have sendmail(8), installed or if mail is disabled.

       -x     This option allows you to set debug flags.


       When  the SIGHUP is received, the Cron daemon will close and reopen its
       log file.  This proves to be useful in scripts which rotate and age log
       files.   Naturally,  this is not relevant if Cron was built to use sys-


       In this version of Cron it is possible to use a network-mounted  shared
       /var/spool/cron  across a cluster of hosts and specify that only one of
       which they mount the shared crontab directory,  have  closely  synchro-
       nised  clocks,  e.g., using ntpd(8), otherwise the results will be very

       Using cluster sharing automatically disables inotify  support,  because
       inotify cannot be relied on with network-mounted shared file systems.


       All  crontab  files  have  to  be  regular files or symlinks to regular
       files, they must not be executable or writable for anyone else but  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 signal to  reload  the  crontabs.
       This is a limitation of the inotify API.

       The  syslog  output  will be used instead of mail, when sendmail is not


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


       Paul Vixie <vixie@isc.org>
       Marcela Malaova <mmaslano@redhat.com>
       Colin Dean <colin@colin-dean.org>

cronie 2013-09-26 CRON(8)

Subscribe to us on YouTube