cron man page on OpenSuSE

Man page or keyword search:  
man Server   25941 pages
apropos Keyword Search (all sections)
Output format
OpenSuSE logo
[printable version]

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

NAME
       crond - daemon to execute scheduled commands

SYNOPSIS
       crond [-n | -p | -s | -c | -m<mailcommand>]

       crond -x [ext,sch,proc,pars,load,misc,test,bit]

DESCRIPTION
       Cron is started from /etc/rc.d/init.d or /etc/init.d It returns immedi‐
       ately, thus, there is no need to need to start it with the '&'  parame‐
       ter.

       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:  /etc/anacrontab	system
       crontab,	  usually  used	 to  run  daily,  weekly,  monthly  jobs.  See
       anacrontab(5) for more details.	/etc/cron.d/ directory	that  contains
       system  cronjobs stored for different users.  /var/spool/cron directory
       that contains user crontables created by the crontab command.

       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 Daylight Saving Time changes, are handled in a special  way.	  This
       only applies to jobs that run at a specific time and jobs that run with
       a granularity greater than one hour. Jobs that run more frequently  are
       scheduled normally.

       If  time	 was adjusted one hour forward, those jobs that would have run
       in the interval that has been skipped will be  run  immediately.	  Con‐
       versely,	 if  time was adjusted backward, running the same job twice is
       avoided.

       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.

OPTIONS
       -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.

       -p     Allows Cron to accept any user set crontables.

       -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.

SIGNALS
       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‐
       log(3).

CLUSTERING SUPPORT
       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
       the  hosts  should  run	the  crontab jobs in this directory at any one
       time. This is done by starting Cron with the -c option,	and  have  the
       /var/spool/cron/.cron.hostname file contain just one line, which repre‐
       sents the hostname of whichever host in	the  cluster  should  run  the
       jobs.   If  this	 file  does  not exist, or the hostname in it does not
       match that returned by gethostname(2), then all crontab files  in  this
       directory  are  ignored.	  This has no effect on cron jobs specified in
       the /etc/crontab file or on files in the /etc/cron.d  directory.	 These
       files are always run and considered host-specific.

       Rather than editing /var/spool/cron/.cron.hostname directly, use the -n
       option of crontab(1) to specify the host.

       You should ensure that all hosts in a cluster, and the file server from
       which  they  mount  the shared crontab directory, have closely synchro‐
       nised clocks, e.g. using ntpd(8) , otherwise the results will  be  very
       unpredictable.

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

CAVEATS
       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
       installed.

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

AUTHOR
       Paul Vixie <vixie@isc.org>
       Marcela Mašláňová <mmaslano@redhat.com>
       Colin Dean <colin@colin-dean.org>

Marcela Mašláňová		   July 2010			       CRON(8)
[top]

List of man pages available for OpenSuSE

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net