Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
crontab(1)							    crontab(1)

NAME
       crontab - user crontab file

SYNOPSIS
       crontab [filename]

       crontab [-elr username]

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

   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 au-
	    thorization	is allowed to submit a job.

	 o  if	BSM  audit 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  timezone  of  the
       cron(1M)	daemon,	which is set system-wide in /etc/default/init. Entries
       do not use the invoking user's timezone.	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 .

       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 with	an arg0	of sh.
       Users who desire	to have	their .profile executed	must explicitly	do  so
       in  the	crontab	 file.	cron  supplies a default environment for every
       shell, defining HOME, LOGNAME, SHELL(=/bin/sh), TZ, and PATH.  The  de-
       fault 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)).

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

   Setting cron	Jobs Across Timezones
       The 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/de-
       fault/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.

       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. If
		a  username  is	 given,	 the  specified	user's crontab file is
		edited,	rather than the	current	user's crontab file; this  can
		only  be done by a user	with the solaris.jobs.admin authoriza-
		tion. The environment variable EDITOR determines which	editor
		is  invoked  with  the -e option. The default editor is	ed(1).
		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.

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

       -r	Removes	a user's crontab from the crontab directory.

       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 -name core 2>/dev/null |	xargs rm -f

       Example 2: Mailing 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

       0 0 1,15	* 1

       would  run  a command on	the first and fifteenth	of each	month, as well
       as on every Monday.

       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.

       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.

       EDITOR	       Determine  the  editor to be invoked when the -e	option
		       is specified. This is overriden by the VISUAL  environ-
		       mental variable.	The default editor is ed(1).

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

       The following exit values are returned:

       0	Successful completion.

       >0	An error occurred.

       /etc/cron.d		       main cron directory

       /etc/cron.d/cron.allow	       list of allowed users

       /etc/default/cron	       contains	cron default settings

       /etc/cron.d/cron.deny	       list of denied users

       /var/cron/log		       accounting information

       /var/spool/cron/crontabs	       spool area for crontab

       See attributes(5) for descriptions of the following attributes:

       +-----------------------------+-----------------------------+
       |      ATTRIBUTE	TYPE	     |	    ATTRIBUTE VALUE	   |
       +-----------------------------+-----------------------------+
       |Availability		     |SUNWcsu			   |
       +-----------------------------+-----------------------------+
       |Interface Stability	     |Standard			   |
       +-----------------------------+-----------------------------+

       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)

       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.

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

       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 in-
       ternal 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 sec-
       onds after the current date and time.

				  10 Aug 2005			    crontab(1)

NAME | SYNOPSIS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=crontab&sektion=1&manpath=SunOS+5.10>

home | help