anacron和cron服务有什么区别

最新推荐文章于 2024-08-13 12:47:02 发布

lionzl

最新推荐文章于 2024-08-13 12:47:02 发布

阅读量2.1k

点赞数

分类专栏： ubuntu Linux Fedora DLP

DLP 同时被 3 个专栏收录

228 篇文章 2 订阅

订阅专栏

ubuntu

161 篇文章 0 订阅

订阅专栏

Linux Fedora

117 篇文章 0 订阅

订阅专栏

cron是用来控制循环执行的例行性工作的，可循环的时间为分钟、小时、每周、每月或每年等。比如我要设定机器每天早上8点进行备份，就可以用到这个服务。除非我们的机器保持每天都24小时开始，否则就会有些系统例行工作都没有人做了，这个时候就可以用到anacron了。 anacron并不是用来取代cron的，anacron 存在的目的就在于我们上面提到的，在处理非 24 小时一直启动的 Linux 系统的 cron 服务的执行！所以 anacron 并不能指定何时执行某项任务，而是以天为单位或者是在开机后立刻进行 anacron 的动作，他会去侦测停机期间应该进行但是并没有进行的 cron服务，如果有就将该任务执行一遍，然后就自动停止。

cron

From Wikipedia, the free encyclopedia

Jump to: navigation, search

For other uses, see CRON (disambiguation).

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (November 2011)

Cron is the time-based job scheduler in Unix-like computer operating systems. Cron enables users to schedule jobs (commands or shell scripts) to run periodically at certain times or dates. It is commonly used to automate system maintenance or administration, though its general-purpose nature means that it can be used for other purposes, such as connecting to the Internet and downloading email.^[1]

Overview

Cron is driven by a crontab (cron table) file, a configuration file that specifies shell commands to run periodically on a given schedule. The crontab files are stored where the lists of jobs and other instructions to the cron daemon are kept. Users can have their own individual crontab files and often there is a system wide crontab file (usually in /etc or a subdirectory of /etc) which only system administrators can edit.

Each line of a crontab file represents a job and is composed of a CRON expression, followed by a shell command to execute. Some implementations of cron, such as that in the popular 4th BSD edition written by Paul Vixie and included in many Linux distributions, add a sixth field to the format: an account username that the specified job will be run by (subject to user existence and permissions). This is allowed only in the system crontabs, not in others which are each assigned to a single user to configure. The sixth field is also sometimes used for year instead of an account username; the nncron daemon for Windows does this. However vixie cron does not use the sixth column as a year and if used will treat the year as the command to run and fail.

For "day of the week" (field 5), both 0 and 7 are considered Sunday, though some versions of Unix such as AIX do not list "7" as acceptable in the man page. While normally the job is executed when the time/date specification fields all match the current time and date, there is one exception: if both "day of month" and "day of week" are restricted (not "*"), then either the "day of month" field (3) or the "day of week" field (5) must match the current day.

Examples

The following line specifies that the Apache error log is to be cleared at one minute past midnight (00:01) of every day of the month, of every day of the week, assuming that the default shell for the cron user is Bourne shell compliant:

1 0 * * *  printf > /var/log/apache/error_log

The following line causes the user program test.pl – ostensibly a Perl script – to be run every two hours, namely at midnight, 2am, 4am, 6am, 8am, and so on:

0 */2 * * *  /home/username/test.pl

Predefined scheduling definitions

There are several special predefined values which can be used to substitute the CRON expression.

Entry	Description	Equivalent To
`@yearly (or @annually)`	Run once a year at midnight in the morning of January 1	`0 0 1 1 *`
`@monthly`	Run once a month at midnight in the morning of the first of the month	`0 0 1 * *`
`@weekly`	Run once a week at midnight in the morning of Sunday	`0 0 * * 0`
`@daily`	Run once a day at midnight	`0 0 * * *`
`@hourly`	Run once an hour at the beginning of the hour	`0 * * * *`
`@reboot`	Run at startup	`@reboot`

*    *    *    *    *  command to be executed
┬    ┬    ┬    ┬    ┬
│    │    │    │    │
│    │    │    │    │
│    │    │    │    └───── day of week (0 - 7) (0 or 7 are Sunday, or use names)
│    │    │    └────────── month (1 - 12)
│    │    └─────────────── day of month (1 - 31)
│    └──────────────────── hour (0 - 23)
└───────────────────────── min (0 - 59)

@reboot configures a job to run once when the daemon is started. Since cron is typically never restarted, this typically corresponds to the machine being booted. This behavior is enforced in some variations of cron, such as that provided in Debian,^[2] so that simply restarting the daemon does not re-run @reboot jobs.

@reboot can be useful if there is a need to start up a server or daemon under a particular user, and the user does not have access to configure init to start the program.

There are sites where the cron expressions are described as containing also seconds setting. In example: http://docs.oracle.com/cd/E14592_01/doc.10142/e14611/cron_expressions.htm .

cron permissions

The following two files play an important role:

/etc/cron.allow - If this file exists, then you must be listed therein (your username must be listed) in order to be allowed to use cron jobs.
/etc/cron.deny - If the cron.allow file does not exist but the /etc/cron.deny file does exist, then you must not be listed in the /etc/cron.deny file in order to use cron jobs.

Please note that if neither of these files exists, then depending on site-dependent configuration parameters, only the super user will be allowed to use cron jobs, or all users will be able to use cron jobs.

Timezone handling

Most cron implementations simply interpret crontab entries in the system time zone setting under which the cron daemon itself is run. This can be a source of dispute if a large multiuser machine has users in several time zones, especially if the system default timezone includes the potentially confusing DST. Thus, a cron implementation may special-case any "CRON_TZ=<timezone>" environment variable setting lines in user crontabs, interpreting subsequent crontab entries relative to that timezone.^[3]

History

Early versions

The cron in Version 7 Unix, written by Brian Kernighan, was a system service (later called daemons) invoked from /etc/inittab when the operating system entered multi-user mode. Its algorithm was straightforward:

Read /usr/etc/crontab
Determine if any commands are to be run at the current date and time and if so, run them as the Superuser, root.
Sleep for one minute
Repeat from step 1.

This version of cron was basic and robust but it also consumed resources whether it found any work to do or not. In an experiment at Purdue University in the late 1970s to extend cron's service to all 100 users on a time-shared VAX, it was found to place too much load on the system.

Multi-user capability

The next version of cron, with the release of Unix System V, was created to extend the capabilities of cron to all users of a Unix system, not just the superuser. Though this may seem trivial today with most Unix and Unix-like systems having powerful processors and small numbers of users, at the time it required a new approach on a 1 MIPS system having roughly 100 user accounts.

In the August, 1977 issue of the Communications of the ACM, W. R. Franta and Kurt Maly published an article entitled "An efficient data structure for the simulation event set" describing an event queue data structure for discrete event-driven simulation systems that demonstrated "performance superior to that of commonly used simple linked list algorithms," good behavior given non-uniform time distributions, and worst case complexity $O\left(\sqrt{n}\right)$ , "n" being the number of events in the queue.

A graduate student, Robert Brown, reviewing this article, recognized the parallel between cron and discrete event simulators, and created an implementation of the Franta-Maly event list manager (ELM) for experimentation. Discrete event simulators run in "virtual time", peeling events off the event queue as quickly as possible and advancing their notion of "now" to the scheduled time of the next event. By running the event simulator in "real time" instead of virtual time, a version of cron was created that spent most of its time sleeping, waiting for the moment in time when the task at the head of the event list was to be executed.

The following school year brought new students into the graduate program, including Keith Williamson, who joined the systems staff in the Computer Science department. As a "warm up task" Brown asked him to flesh out the prototype cron into a production service, and this multi-user cron went into use at Purdue in late 1979. This version of cron wholly replaced the /etc/cron that was in use on the Computer Science department's VAX 11/780 running 32/V.

The algorithm used by this cron is as follows:

On start-up, look for a file named .crontab in the home directories of all account holders.
For each crontab file found, determine the next time in the future that each command is to be run.
Place those commands on the Franta-Maly event list with their corresponding time and their "five field" time specifier.
Enter main loop:
1. Examine the task entry at the head of the queue, compute how far in the future it is to be run.
2. Sleep for that period of time.
3. On awakening and after verifying the correct time, execute the task at the head of the queue (in background) with the privileges of the user who created it.
4. Determine the next time in the future to run this command and place it back on the event list at that time value.

Additionally, the daemon would respond to SIGHUP signals to rescan modified crontab files and would schedule special "wake up events" on the hour and half hour to look for modified crontab files. Much detail is omitted here concerning the inaccuracies of computer time-of-day tracking, Unix alarm scheduling, explicit time-of-day changes, and process management, all of which account for the majority of the lines of code in this cron. This cron also captured the output of stdout and stderr and e-mailed any output to the crontab owner.

The resources consumed by this cron scale only with the amount of work it is given and do not inherently increase over time with the exception of periodically checking for changes.

Williamson completed his studies and departed the University with a Masters of Science in Computer Science and joined AT&T Bell Labs in Murray Hill, New Jersey, and took this cron with him. At Bell Labs, he and others incorporated the Unix at command into cron, moved the crontab files out of users' home directories (which were not host-specific) and into a common host-specific spool directory, and of necessity added the crontab command to allow users to copy their crontabs to that spool directory.

This version of cron later appeared largely unchanged in Unix System V and in BSD and their derivatives, the Solaris Operating System from Sun Microsystems, IRIX from Silicon Graphics, HP-UX from Hewlett-Packard, and IBM AIX. Technically, the original license for these implementations should be with the Purdue Research Foundation who funded the work, but this took place at a time when little concern was given to such matters.

Modern versions

With the advent of the GNU Project and Linux, new crons appeared. The most prevalent of these is the Vixie cron, originally coded by Paul Vixie in 1987. Version 3 of Vixie cron was released in late 1993. Version 4.1 was renamed to ISC Cron and was released in January 2004. Version 3, with some minor bugfixes, is used in most distributions of Linux and BSDs.

In 2007, RedHat forked vixie-cron 4.1 to the cronie project and included anacron 2.3 in 2009.

Other popular implementations include anacron, dcron, and fcron. However, anacron is not an independent cron program; it relies on another cron program to call it in order to perform. dcron was the work of DragonFly BSD founder Matt Dillon, the code is currently maintained by Jim Pryor.

A webcron solution schedules recurring tasks to run on a regular basis wherever cron implementations may not be available in a web hosting environment.

CRON expression

A CRON expression is a string comprising 5 or 6 fields separated by white space^[4] that represents a set of times, normally as a schedule to execute some routine.

Format

Field name	Mandatory?	Allowed values	Allowed special characters
Minutes	Yes	0-59	`* / , -`
Hours	Yes	0-23	`* / , -`
Day of month	Yes	1-31	`* / , - ? L W`
Month	Yes	1-12 or JAN-DEC	`* / , -`
Day of week	Yes	0-6 or SUN-SAT	`* / , - ? L #`
Year	No	1970–2099	`* / , -`

In some uses of the CRON format there is also a seconds field at the beginning of the pattern.^[5]

Special characters

Support for each special character depends on specific distributions and versions of cron

Asterisk ( * )

The asterisk indicates that the cron expression will match for all values of the field; e.g., using an asterisk in the 4th field (month) would indicate every month.

Slash ( / )

Slashes are used to describe increments of ranges. For example 3-59/15 in the 1st field (minutes) would indicate the 3rd minute of the hour and every 15 minutes thereafter. The form "*/..." is equivalent to the form "first-last/...", that is, an increment over the largest possible range of the field.

Percent ( % )

Percent-signs (%) in the command, unless escaped with backslash (\), will be changed into newline characters, and all data after the first % will be sent to the command as standard input. ^[6]

Comma ( , )

Commas are used to separate items of a list. For example, using "MON,WED,FRI" in the 5th field (day of week) would mean Mondays, Wednesdays and Fridays.

Hyphen ( - )

Hyphens are used to define ranges. For example, 2000-2010 would indicate every year between 2000 and 2010 CE inclusive.

'L' stands for "last". When used in the day-of-week field, it allows you to specify constructs such as "the last Friday" ("5L") of a given month. In the day-of-month field, it specifies the last day of the month.

The 'W' character is allowed for the day-of-month field. This character is used to specify the weekday (Monday-Friday) nearest the given day. As an example, if you were to specify "15W" as the value for the day-of-month field, the meaning is: "the nearest weekday to the 15th of the month". So if the 15th is a Saturday, the trigger will fire on Friday the 14th. If the 15th is a Sunday, the trigger will fire on Monday the 16th. If the 15th is a Tuesday, then it will fire on Tuesday the 15th. However if you specify "1W" as the value for day-of-month, and the 1st is a Saturday, the trigger will fire on Monday the 3rd, as it will not 'jump' over the boundary of a month's days. The 'W' character can be specified only when the day-of-month is a single day, not a range or list of days.

Hash ( # )

'#' is allowed for the day-of-week field, and must be followed by a number between one and five. It allows you to specify constructs such as "the second Friday" of a given month. ^{[citation needed]}

Question mark ( ? )

Note: Question mark is a non-standard character and exists only in some cron implementations. It is used instead of '*' for leaving either day-of-month or day-of-week blank.

References

^ Newbie Introduction to cron
^ Bugs.debian.org
^ [1]
^ Ubuntu Cron Howto
^ "CronTrigger Tutorial". Quartz Scheduler Website. Retrieved 24 October 2011.
^ mcron crontab reference

External links

crontab: schedule periodic background work – Commands & Utilities Reference, The Single UNIX® Specification, Issue 7 from The Open Group
GNU cron (mcron)
ISC Cron 4.1
Fedorahosted.org - cronie project, a fork of vixie-cron 4.1 and anacron 2.3 from the RedHat project
ACM Digital library – Franta, Maly, "An efficient data structure for the simulation event set" (requires ACM pubs subscription)
Crontab syntax tutorial - Crontab syntax explained
UNIX / Linux cron tutorial - a quick tutorial for UNIX like operating systems with sample shell scripts.
All about Cron on one page - a page covering Cron, starting with theory and ending with many practical examples about its usage.
Dillon's cron (dcron)
Cron Reference - Information on the cron and its usage
Cron Expression translator - Small Site which tries to convert a cron tab expression to English
CronTab Config and Examples

anacron

From Wikipedia, the free encyclopedia

Jump to: navigation, search

anacron is a computer program that performs periodic command scheduling which is traditionally done by cron, but without assuming that the system is running continuously. Thus, it can be used to control the execution of daily, weekly, and monthly jobs (or anything with a period of n days) on systems that don't run 24 hours a day. anacron was originally conceived and implemented by Christian Schwarz in Perl, for the Unix operating system. The current implementation, in C, was written by Itai Tzur and is actively maintained by Sean 'Shaleh' Perry.

Advantages

Unix systems commonly run "housekeeping chores" such as log-rotation, unused files deletion, indexing local files for the search engine, sending disk usage reports, etc. A program called cron may be used to schedule these tasks.

With cron, tasks are commonly scheduled to be executed at night when the system is idle. If the system is off at the moment a task should be run, it will not be executed. anacron is different and moves tasks to different moments so they are run when the system is on. It is a cron-complement in that it requires cron.

Disadvantages

Only the system administrator can configure anacron tasks. In contrast, cron allows non-admin users to configure scheduled tasks. If necessary, a non-admin user can use the at Unix command to request a scheduled task (which is guaranteed to run). Upon starting, this command can then automatically request to run itself at a future date, thus giving the appearance of a regularly scheduled task, with guaranteed execution.

anacron can only run tasks once a day (or less often such as weekly or monthly). In contrast, cron allows tasks to run as often as every minute (but does not guarantee their execution if the system goes down). In practice, this is not usually an issue, since it is rare to have a task that must be guaranteed to run more often than (at least) once a day — especially on a system that is not necessarily running at all times.

If the system is rebooted or started after midnight, the daily tasks are run after a user-specified delay in synchronized fashion (sequential order), so only one anacron-task is running at a time. When that task is finished, the next one starts and so on.

This behaviour can be overridden to allow concurrent (parallel) tasks, but can consume system resources that are needed by the user to do work. In contrast cron will only run daily tasks at the time set (e.g. in the middle of the night, when presumably the machine is not being used).

fcron is another implementation of cron which attempts to fulfill the roles of both Vixiecron and anacron.