crontab man page on SmartOS

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

CRONTAB(1)							    CRONTAB(1)

NAME
       crontab - user crontab file

SYNOPSIS
       /usr/bin/crontab [filename]

       /usr/bin/crontab -e [username]

       /usr/bin/crontab -l [-g] [username]

       /usr/bin/crontab -r [username]

       /usr/xpg4/bin/crontab [filename]

       /usr/xpg4/bin/crontab -e [username]

       /usr/xpg4/bin/crontab -l [-g] [username]

       /usr/xpg4/bin/crontab -r [username]

       /usr/xpg6/bin/crontab [filename]

       /usr/xpg6/bin/crontab -e [username]

       /usr/xpg6/bin/crontab -l [-g] [username]

       /usr/xpg6/bin/crontab -r [username]

DESCRIPTION
       The crontab utility manages a user's access with cron (see cron(1M)) by
       copying, creating, listing, and	removing  crontab  files.  If  invoked
       without	options,  crontab  copies  the specified file, or the standard
       input if no file is specified, into a directory that holds  all	users'
       crontabs.

       If  crontab  is	invoked	 with  filename,  this	overwrites an existing
       crontab entry for the user that invokes it.

       Cron supports a merged crontab with  entries  coming  from  either  the
       user's	 /var/spool/cron/crontabs    file    or	   from	  the	user's
       /etc/cron.d/crontabs    file.	 The	entries	   in	 the	user's
       /var/spool/cron/crontabs	  file	 are   editable	  whereas   those   in
       /etc/cron.d/crontabs are system-defined entries which may not  be  cus‐
       tomized by the user.  The dual set of crontab entries is only of inter‐
       est to system-defined users  such  as  root.   Except  where  otherwise
       explicitly  indicated,  all variants of the crontab command act only on
       the editable crontab files found in /var/spool/cron/crontabs.

   crontab Access Control
       Users: Access to crontab is allowed:

	   o	  if the user's name appears in /etc/cron.d/cron.allow.

	   o	  if /etc/cron.d/cron.allow does not exist and the user's name
		  is not in /etc/cron.d/cron.deny.

       Users: Access to crontab is denied:

	   o	  if  /etc/cron.d/cron.allow exists and the user's name is not
		  in it.

	   o	  if /etc/cron.d/cron.allow does not exist and user's name  is
		  in /etc/cron.d/cron.deny.

	   o	  if   neither	 file	exists,	  only	 a   user   with   the
		  solaris.jobs.user authorization is allowed to submit a job.

	   o	  if Solaris Auditing is enabled,  the	user's	shell  is  not
		  audited  and	the  user  is  not the crontab owner. This can
		  occur if the user logs in by way of a program, such as  some
		  versions of SSH, which does not set audit parameters.

       The rules for allow and deny apply to root only if the allow/deny files
       exist.

       The allow/deny files consist of one user name per line.

   crontab Entry Format
       A crontab file consists of lines of six fields  each.  The  fields  are
       separated  by  spaces or tabs. The first five are integer patterns that
       specify the following:

	 minute (0−59),
	 hour (0−23),
	 day of the month (1−31),
	 month of the year (1−12),
	 day of the week (0−6 with 0=Sunday).

       Each of these patterns can be either an	asterisk  (meaning  all	 legal
       values) or a list of elements separated by commas. An element is either
       a number or two numbers separated by a minus sign (meaning an inclusive
       range).	Time  specified	 here  is  interpreted in the currently active
       timezone. At the top of the crontab file this is the timezone which  is
       set system-wide in /etc/default/init. A user can add a line such as:

	 TZ=timezone

       ...and  all subsequent entries will be interpreted using that timezone,
       until a new TZ=timezone line is encountered. The specification of  days
       can  be made by two fields (day of the month and day of the week). Both
       are adhered to if specified as a list of elements. See EXAMPLES.

       The sixth field of a line in a crontab file is a string	that  is  exe‐
       cuted  by the shell at the specified times. A percent character in this
       field (unless escaped by \) is translated to a NEWLINE character.

       Only the first line (up to a `%' or end of line) of the	command	 field
       is executed by the shell. Other lines are made available to the command
       as standard input. Any blank line or line beginning with	 a  `#'	 is  a
       comment and is ignored.

       The  shell  is  invoked	from  your  $HOME directory. As with $TZ, both
       $SHELL and $HOME can be set by having a line such as:

	 SHELL=/usr/bin/someshell

       ...or:

	 HOME=somedirectory

       ...which will take precedence for all  the  remaining  entries  in  the
       crontab	or  until  there is another HOME or SHELL entry. It is invoked
       with an arg0 of the basename of the $SHELL that is currently in effect.
       A  user who wants to have his .profile or equivalent file executed must
       explicitly do so in the crontab file. cron supplies a default  environ‐
       ment  for every shell, defining HOME, LOGNAME, SHELL, TZ, and PATH. The
       default PATH for user cron jobs	is  /usr/bin;  while  root  cron  jobs
       default	 to  /usr/sbin:/usr/bin.  The  default	PATH  can  be  set  in
       /etc/default/cron (see cron(1M)). The TZ, HOME, and  SHELL  environment
       variables are set to match those that are in effect in the crontab file
       at the time.

       If you do not redirect the standard output and standard error  of  your
       commands, any generated output or errors are mailed to you.

   crontab Environment Variables
       The following variables are supported:

       HOME

	   Allows  the	user  to  choose and alternative directory for cron to
	   change directory to prior to running the command. For example:

	     HOME=/var/tmp

       SHELL

	   The name of the shell to use to run subsequent commands. For	 exam‐
	   ple:

	     SHELL=/usr/bin/ksh

       TZ

	   Allows  the	user  to choose the timezone in which the cron entries
	   are run.  This effects both the environment of the command that  is
	   run	and the timing of the entry. For example, to have your entries
	   run using the timezone for Iceland, use:

	     TZ=Iceland

       Each of these variables affects all of the lines that follow it in  the
       crontab	file,  until  it  is reset by a subsequent line resetting that
       variable. Hence, it is possible to have	multiple  timezones  supported
       within a single crontab file.

       The  lines  that	 are  not setting these environment variables are  the
       same as crontab entries that conform  to	 the  UNIX  standard  and  are
       described elsewhere in this man page.

   Setting cron Jobs Across Timezones
       The  default  timezone of the cron daemon sets the system-wide timezone
       for cron entries. This, in turn, is by set by default system-wide using
       /etc/default/init.

       If  some	 form  of daylight savings or summer/winter time is in effect,
       then jobs scheduled during the  switchover  period  could  be  executed
       once, twice, or not at all.

OPTIONS
       The following options are supported:

       -e
	     Edits  a  copy  of the current user's crontab file, or creates an
	     empty file to edit if crontab does not  exist.  When  editing  is
	     complete, the file is installed as the user's crontab file.

	     The  environment  variable	 EDITOR	 determines  which  editor  is
	     invoked with the -e option. All crontab jobs should be  submitted
	     using  crontab. Do not add jobs by just editing the crontab file,
	     because cron is not aware of changes made this way.

	     If all lines in the crontab file are  deleted,  the  old  crontab
	     file  is  restored.  The  correct	way  to delete all lines is to
	     remove the crontab file using the -r option.

	     If username is specified, the specified user's  crontab  file  is
	     edited,  rather  than  the	 current user's crontab file. This can
	     only be done by root or by a  user	 with  the  solaris.jobs.admin
	     authorization.

	     Only  the entries in the user's /var/spool/cron/crontabs file are
	     editable.

       -l
	     Lists the crontab file for the invoking user. Only root or a user
	     with  the solaris.jobs.admin authorization can specify a username
	     following the -l option to list the crontab file of the specified
	     user.

	     Entries from the user's /var/spool/cron/crontabs file are listed,
	     unless the -g option is given, in which case  only	 entries  from
	     the user's /etc/cron.d/crontabs file are listed.

       -g
	     In	 conjunction with the -l option, lists the global crontab file
	     for the invoking or specified user (if authorized) instead of the
	     editable  crontab	file.	This option is not valid unless the -l
	     option is also given.

       -r
	     Removes a user's crontab from the crontab directory. Only root or
	     a	user  with  the solaris.jobs.admin authorization can specify a
	     username following the -r option to remove the  crontab  file  of
	     the specified user.

EXAMPLES
       Example 1 Cleaning up Core Files

       This example cleans up core files every weekday morning at 3:15 am:

	 15 3 * * 1-5 find $HOME -namecore 2>/dev/null | xargs rm -f

       Example 2 Mailing a Birthday Greeting

       This example mails a birthday greeting:

	 0 12 14 2 * mailx john%Happy Birthday!%Time for lunch.

       Example 3 Specifying Days of the Month and Week

       This  example  runs a command on the first and fifteenth of each month,
       as well as on every Monday:

	 0 0 1,15 * 1

       To specify days by only one field, the other field should be set to  *.
       For example:

	 0 0 * * 1

       would run a command only on Mondays.

       Example 4 Using Environment Variables

       The  following  entries	take  advantage of crontab support for certain
       environment variables.

	 TZ=GMT
	 HOME=/local/home/user
	 SHELL=/usr/bin/ksh
	 0 0 * * * echo $(date) >	 midnight.GMT
	 TZ=PST
	 0 0 * * * echo $(date) >	 midnight.PST
	 TZ=EST
	 HOME=/local/home/myuser
	 SHELL=/bin/csh

       The preceding entries allow two jobs to run. The first one would run at
       midnight	 in  the  GMT timezone and the second would run at midnight in
       the PST timezone. Both would be run in the  directory  /local/home/user
       using  the  Korn	 shell.	 The  file  concludes with TZ, HOME, and SHELL
       entries that return those variable to their default values.

ENVIRONMENT VARIABLES
       See environ(5) for descriptions of the following environment  variables
       that  affect  the execution of crontab: LANG, LC_ALL, LC_CTYPE, LC_MES‐
       SAGES, and NLSPATH.

   /usr/bin/crontab
       EDITOR
		 Determine the editor to be invoked  when  the	-e  option  is
		 specified.  This  is  overridden  by the VISUAL environmental
		 variable. The default editor is vi(1).

       PATH
		 The PATH in crontab's environment specifies the  search  path
		 used to find the editor.

       VISUAL
		 Determine  the visual editor to be invoked when the -e option
		 is specified. If VISUAL is not specified, then	 the  environ‐
		 ment variable EDITOR is used. If that is not set, the default
		 is vi(1).

   /usr/xpg4/bin/crontab
       EDITOR
		 Determine the editor to be invoked  when  the	-e  option  is
		 specified. The default editor is /usr/xpg4/bin/vi.

   /usr/xpg6/bin/crontab
       EDITOR
		 Determine  the	 editor	 to  be	 invoked when the -e option is
		 specified. The default editor is /usr/xpg6/bin/vi.

EXIT STATUS
       The following exit values are returned:

       0
	     Successful completion.

       >0
	     An error occurred.

				   system spool area for crontab
FILES
       /etc/cron.d
       /var/cron/log		   main cron directory
				   accounting information

       /etc/cron.d/cron.allow
       /var/spool/cron/crontabs	   list of allowed users
				   spool area for crontab

       /etc/default/cron
ATTRIBUTES			   contains cron default settings
       See attributes(5) for descriptions of the following attributes:

   /usr/bin/crontabcron.deny
       ┌────────────────────┬──────list─of─denied users
       │  ATTRIBUTE TYPE    │ ATTRIBUTE VALUE │
       ├────────────────────┼─────────────────┤
       /InterfacedStability │ Standard	      │
       └────────────────────┴─────────────────┘

   /usr/xpg4/bin/crontab
       ┌────────────────────┬─────────────────┐
       │  ATTRIBUTE TYPE    │ ATTRIBUTE VALUE │
       ├────────────────────┼─────────────────┤
       │Interface Stability │ Standard	      │
       └────────────────────┴─────────────────┘

   /usr/xpg6/bin/crontab
       ┌────────────────────┬─────────────────┐
       │  ATTRIBUTE TYPE    │ ATTRIBUTE VALUE │
       ├────────────────────┼─────────────────┤
       │Interface Stability │ Standard	      │
       └────────────────────┴─────────────────┘

SEE ALSO
       atq(1), atrm(1),	 auths(1),  ed(1),  sh(1),  vi(1),  cron(1M),  su(1M),
       auth_attr(4), attributes(5), environ(5), standards(5)

NOTES
       If  you	inadvertently  enter the crontab command with no arguments, do
       not attempt to get out with Control-d. This removes all entries in your
       crontab file. Instead, exit with Control-c.

       When  updating  cron, check first for existing crontab entries that can
       be scheduled close to the time of the update. Such entries can be  lost
       if  the	update	process	 completes after the scheduled event. This can
       happen because, when cron is notified by crontab to update the internal
       view  of	 a  user's  crontab file, it first removes the user's existing
       internal crontab and any internal scheduled events. Then it  reads  the
       new  crontab  file  and	rebuilds the internal crontab and events. This
       last step takes time, especially with a large  crontab  file,  and  can
       complete	 after	an existing crontab entry is scheduled to run if it is
       scheduled too close to the update. To be safe, start a new job at least
       60 seconds after the current date and time.

       If  an  authorized user other than root modifies another user's crontab
       file, the resulting behavior can be unpredictable. Instead, the	autho‐
       rized  user  should  first  use su(1M) to become superuser to the other
       user's login before making any changes to the crontab file.

       Care should be taken when adding TZ, SHELL and HOME  variables  to  the
       crontab	 file  when the crontab file could be shared with applications
       that do not expect those variables to  be  changed  from	 the  default.
       Resetting  the  values to their defaults at the bottom of the file will
       minimize the risk of problems.

				 Sep 23, 2013			    CRONTAB(1)
[top]

List of man pages available for SmartOS

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