Партнёры:
Хостинг:
crontab - user crontab file
/usr/bin/crontab [filename]
/usr/bin/crontab -e [username]
/usr/bin/crontab -l [username]
/usr/bin/crontab -r [username]
/usr/xpg4/bin/crontab [filename]
/usr/xpg4/bin/crontab -e [username]
/usr/xpg4/bin/crontab -l [username]
/usr/xpg4/bin/crontab -r [username]
/usr/xpg6/bin/crontab [filename]
/usr/xpg6/bin/crontab -e [username]
/usr/xpg6/bin/crontab -l [username]
/usr/xpg6/bin/crontab -r [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 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.
Users: Access to crontab is allowed:
Users: Access to crontab is denied:
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.
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 EXAMPLES.
The sixth field of a line in a crontab file is a string that is executed 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 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)).
If you do not redirect the standard output and standard error of your commands, any generated output or errors are mailed to you.
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/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.
The following options are supported:
-e
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.
-l
-r
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.
See environ(5) for descriptions of the following environment variables that affect the execution of crontab: LANG, LC_ALL, LC_CTYPE, LC_COLLATE, LC_MESSAGES, and NLSPATH.
Affirmative responses are processed using the extended regular expression defined for the yesexpr keyword in the LC_MESSAGES category of the user's locale. The locale specified in the LC_COLLATE category defines the behavior of ranges, equivalence classes, and multi-character collating elements used in the expression defined for yesexpr. The locale specified in LC_CTYPE determines the locale for interpretation of sequences of bytes of text data a characters, the behavior of character classes used in the expression defined for the yesexpr. See locale(5).
EDITOR
PATH
VISUAL
EDITOR
EDITOR
The following exit values are returned:
0
>0
/etc/cron.d
/etc/cron.d/cron.allow
/etc/default/cron
/etc/cron.d/cron.deny
/var/cron/log
/var/spool/cron/crontabs
See attributes(5) for descriptions of the following attributes:
| |||||||||
| |||||||||
| |||||||||
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.
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 authorized user should first use su(1M) to become superuser to the other user's login before making any changes to the crontab file.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |