Cron руководство по

Introduction

Cron is a system daemon used to execute desired tasks (in the background) at designated times.

A crontab file is a simple text file containing a list of commands meant to be run at specified times. It is edited using the crontab command. The commands in the crontab file (and their run times) are checked by the cron daemon, which executes them in the system background.

Each user (including root) has a crontab file. The cron daemon checks a user’s crontab file regardless of whether the user is actually logged into the system or not.

To display the on-line help for crontab enter:

 man crontab

or further information is available from the OpenGroup specifications.

On Gnome-based Ubuntu systems Gnome Scheduled tasks tool (from the gnome-schedule package) in Applications —> System Tools provides a graphical interface with prompting for using Cron. The project website is at http://gnome-schedule.sourceforge.net/; the software is installable from the Software Center or by typing

sudo apt-get install gnome-schedule

in a terminal.

Starting to Use Cron

To use cron for tasks meant to run only for your user profile, add entries to your own user’s crontab file. To edit the crontab file enter:

crontab -e

Edit the crontab using the format described in the next sections. Save your changes. (Exiting without saving will leave your crontab unchanged.) To display the on-line help describing the format of the crontab file enter:

man 5 crontab

Commands that normally run with administrative privileges (i.e. they are generally run using sudo) should be added to the root crontab. To edit the root crontab enter:

 sudo crontab -e

Crontab Lines

Each line has five time-and-date fields, followed by a command, followed by a newline character (‘\n’). The fields are separated by spaces. The five time-and-date fields cannot contain spaces. The five time-and-date fields are as follows: minute (0-59), hour (0-23, 0 = midnight), day (1-31), month (1-12), weekday (0-6, 0 = Sunday).

01 04 1 1 1 /usr/bin/somedirectory/somecommand

The above example will run /usr/bin/somedirectory/somecommand at 4:01am on January 1st plus every Monday in January.

An asterisk (*) can be used so that every instance (every hour, every weekday, every month, etc.) of a time period is used.

01 04 * * * /usr/bin/somedirectory/somecommand

The above example will run /usr/bin/somedirectory/somecommand at 4:01am on every day of every month.

Comma-separated values can be used to run more than one instance of a particular command within a time period. Dash-separated values can be used to run a command continuously.

01,31 04,05 1-15 1,6 * /usr/bin/somedirectory/somecommand

The above example will run /usr/bin/somedirectory/somecommand at 01 and 31 past the hours of 4:00am and 5:00am on the 1st through the 15th of every January and June.

The «/usr/bin/somedirectory/somecommand» text in the above examples indicates the task which will be run at the specified times. It is recommended that you use the full path to the desired commands as shown in the above examples. Enter which somecommand in the terminal to find the full path to somecommand. The crontab will begin running as soon as it is properly edited and saved.

You may want to run a script some number of times per time unit. For example if you want to run it every 10 minutes use the following crontab entry (runs on minutes divisible by 10: 0, 10, 20, 30, etc.)

*/10 * * * * /usr/bin/somedirectory/somecommand

which is also equivalent to the more cumbersome

0,10,20,30,40,50 * * * * /usr/bin/somedirectory/somecommand

Cron also offers some special strings, which can be used in place of the five time-and-date fields:

• string	meaning
  @reboot	Run once, at startup.
  @yearly	Run once a year, «0 0 1 1 *».
  @annually	(same as @yearly)
  @monthly	Run once a month, «0 0 1 * *».
  @weekly	Run once a week, «0 0 * * 0».
  @daily	Run once a day, «0 0 * * *».
  @midnight	(same as @daily)
  @hourly	Run once an hour, «0 * * * *».

@reboot /path/to/execuable1

The above example will execute /path/to/executable1 when the system starts.

For more information on special strings enter «man 5 crontab».

Crontab Options

• The -l option causes the current crontab to be displayed on standard output.
• The -r option causes the current crontab to be removed.
• The -e option is used to edit the current crontab using the editor specified by the EDITOR environment variable.

After you exit from the editor, the modified crontab is checked for errors and, if there are no errors, it is installed automatically. The file is stored in /var/spool/cron/crontabs but should only be edited using the crontab command.

Allowing/Denying User-Level Cron

If the /etc/cron.allow file exists, then users must be listed in it in order to be allowed to run the crontab command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does, then users must not be listed in the /etc/cron.deny file in order to run crontab.

In the case where neither file exists, the default on current Ubuntu (and Debian, but not some other Linux and UNIX systems) is to allow all users to run jobs with crontab.

No cron.allow or cron.deny files exist in a standard Ubuntu install, so all users should have cron available by default, until one of those files is created. If a blank cron.deny file has been created, that will change to the standard behavior users of other operating systems might expect: cron only available to root or users in cron.allow.

Note, userids on your system which do not appear in /etc/shadow will NOT have operational crontabs, if you desire to enter a user in /etc/passwd, but NOT /etc/shadow that user’s crontab will never run. Place an entry in /etc/shadow for the user with a * for the password crypt, eg:

joeuser:*:15169::::::

Further Considerations

Crontab commands are generally stored in the crontab file belonging to your user account (and executed with your user’s level of permissions). If you want to regularly run a command requiring administrative permissions, edit the root crontab file:

sudo crontab -e

Depending on the commands being run, you may need to expand the root users PATH variable by putting the following line at the top of the root crontab file:

PATH=/usr/sbin:/usr/bin:/sbin:/bin

crontab -e uses the EDITOR environment variable. To change the editor to your own choice, just set that variable. You may want to set EDITOR in your .bashrc because many commands use this variable. For example, in order to set the editor to be nano (a very easy editor to use) add this line to .bashrc:

export EDITOR=nano

It is sensible to test that your cron jobs work as intended. One method for doing this is to set up the job to run a couple of minutes in the future and then check the results before finalising the timing. You may also find it useful to put the commands into script files that log their success or failure, for example:

echo "Nightly Backup Successful: $(date)" >> /tmp/mybackup.log

If your machine is regularly switched off, you may also be interested in at and anacron, which provide other approaches to scheduled tasks. For example, anacron offers simple system-wide directories for running commands hourly, daily, weekly, and monthly. Scripts to be executed in said times can be placed in /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/. All scripts in each directory are run as root, and a specific order to running the scripts can be specified by prefixing the scripts’ filenames with numbers (see the man page for run‑parts for more details). Although the directories contain periods in their names, run‑parts will not accept a file name containing a period and will fail silently when encountering them (bug #38022). Either rename the file or use a symlink (without a period) to it instead (see, for example, python + cron without login? and Problems with Hourly Cron Job).

Common Problems

Edits to a user’s crontab and the cron jobs run are all logged by default to /var/log/syslog and that’s the first place to check if things are not running as you expect.

If a user was not allowed to execute jobs when their crontab was last edited, just adding them to the allow list won’t do anything. The user needs to re-edit their crontab after being added to cron.allow before their jobs will run.

Note that user-specific crontabs (including the root crontab) do not specify the user name after the date/time fields. If you accidentally include the user name in a user-specific crontab, the system will try to run the user name as a command.

Cron jobs may not run with the environment, in particular the PATH, that you expect. Try using full paths to files and programs if they’re not being located as you expect.

The «%» character is used as newline delimiter in cron commands. If you need to pass that character into a script, you need to escape it as «\%».

If you’re having trouble running a GUI application using cron, see the GUI Applications section below.

Two Other Types of Crontab

The crontab files discussed above are user crontabs. Each of the above crontabs is associated with a user, even the root crontab, which is associated with the root user. There are two other types of crontab, with syntax as follows:

minute(s) hour(s) day(s)_of_month month(s) day(s)_of_week user command

Note that the only difference from the syntax of the user crontabs is that the line specifies the user to run the job as.

The first type is as follows. As mentioned above anacron uses the run‑parts command and /etc/cron.hourly, /etc/cron.weekly, and /etc/cron.monthly directories. However anacron itself is invoked from the /etc/crontab file. This file could be used for other cron commands, but probably shouldn’t be. Here’s an example line from a fictitious /etc/crontab:

00 01 * * * rusty /home/rusty/rusty-list-files.sh

This would run Rusty’s command script as user rusty from his home directory. However, it is not usual to add commands to this file. While an experienced user should know about it, it is not recommended that you add anything to /etc/crontab. Apart from anything else, this could cause a problem if the /etc/crontab file is affected by updates! Rusty could lose his command.

The second type is to be found in the directory /etc/cron.d. This directory can contain crontab files. The directory is often used by packages, and the crontab files allow a user to be associated with the commands in them.

Example: Instead of adding a line to /etc/crontab, which Rusty knows is not a good idea, he might well add a file to the directory /etc/cron.d with the name rusty, containing his cron line above. This would not be affected by updates but is a well known location.

When would you use these alternate crontab locations? Well, on a single user machine or a shared machine such as a school or college server, a user crontab would be the way to go. But in a large IT department, where several people might look after a server, then the directory /etc/cron.d is probably the best place to install crontabs — it’s a central point and saves searching for them!

You may not need to look at /etc/crontab or /etc/cron.d, let alone edit them by hand. But an experienced user should perhaps know about them and that the packages that he/she installs may use these locations for their crontabs.

GUI Applications

It is possible to run gui applications via cronjobs. This can be done by telling cron which display to use.

00 06 * * * env DISPLAY=:0 gui_appname

The env DISPLAY=:0 portion will tell cron to use the current display (desktop) for the program «gui_appname».

And if you have multiple monitors, don’t forget to specify on which one the program is to be run. For example, to run it on the first screen (default screen) use :

00 06 * * * env DISPLAY=:0.0 gui_appname

The env DISPLAY=:0.0 portion will tell cron to use the first screen of the current display for the program «gui_appname».

Note: GUI users may prefer to use gnome-schedule (aka «Scheduled tasks») to configure GUI cron jobs. In gnome-schedule, when editing a GUI task, you have to select «X application» in a dropdown next to the command field.

Note: In Karmic(9.10), you have to enable X ACL for localhost to connect to for GUI applications to work.

 ~$ xhost +local:
non-network local connections being added to access control list
 ~$ xhost
access control enabled, only authorized clients can connect
LOCAL:
...

Crontab Example

Below is an example of how to setup a crontab to run updatedb, which updates the slocate database: Open a terminal, type «crontab -e» (without the double quotes) and press enter. Type the following line, substituting the full path of the application you wish to run for the one shown below, into the editor:

45 04 * * * /usr/bin/updatedb

Save your changes and exit the editor.

Crontab will let you know if you made any mistakes. The crontab will be installed and begin running if there are no errors. That’s it. You now have a cronjob setup to run updatedb, which updates the slocate database, every morning at 4:45.

Note: The double-ampersand (&&) can also be used in the «command» section to run multiple commands consecutively, but only if the previous command exits successfully. A string of commands joined by the double-ampersand will only get to the last command if all the previous commands are run successfully. If exit error-checking is not required, string commands together, separated with a semi-colon (;).

45 04 * * * /usr/sbin/chkrootkit && /usr/bin/updatedb

The above example will run chkrootkit followed by updatedb at 4:45am daily — providing you have all listed apps installed. If chkrootkit fails, updatedb will NOT be run.

How Anacron is Set Up

On Ubuntu 9.10 (and presumably, on later versions), anacron seems to be set up as follows:

There is a Upstart task, located in /etc/init/anacron.conf, which runs all the jobs in /etc/anacrontab. It is set to run on startup.

There is a cron.d file (/etc/cron.d/anacron) which causes the Upstart task to be started every day at 7:30 AM.

There is a file /etc/apm/event.d/anacron, which causes the Upstart task to be started when a laptop is plugged in to A/C power, or woken up.

In the system crontab (/etc/crontab), if anacron is not execuatable, run‑parts is used to run the files in cron.daily, cron.weekly, and cron.monthly at 6:25 AM, 6:47 AM and 6:52 AM, respectively.

In /etc/anacrontab, run‑parts is used to run cron.daily 5 minutes after anacron is started, and cron.weekly after 10 minutes (once a week), and cron.monthly after 15 (once a month).

Within the cron.daily, weekly, and monthly directories ( /etc/cron.daily, etc.) there is a 0anacron file that sets the timestamps for anacron, so it will know they have been run, even if it didn’t run them.

So it appears anacron is run on every startup, wake up, plug-in, and at 7:30 AM every day. Looking at the respective Changelogs and package databases, it looks like this setup is directly from Debian, and hasn’t been changed since at least 2009.

Alternatives to Cron

Some hosting companies don’t allow access to cron, but there are websites offering alternative ways of scheduling jobs (free or paid-for). Here are some examples:

• SetCron

• SetCronJob

• OnlineCronJobs

• EasyCron

Классик писал, что счастливые часов не наблюдают. В те дикие времена ещё не было ни программистов, ни Unix, но в наши дни программисты знают твёрдо: вместо них за временем проследит cron.

Утилиты командной строки для меня одновременно слабость и рутина. sed, awk, wc, cut и другие старые программы запускаются скриптами на наших серверах ежедневно. Многие из них оформлены в виде задач для cron, планировщика родом из 70-х.

Я долго пользовался cron поверхностно, не вникая в детали, но однажды, столкнувшись с ошибкой при запуске скрипта, решил разобраться основательно. Так появилась эта статья, при написании которой я ознакомился с POSIX crontab, основными вариантами cron в популярных дистрибутивах Linux и устройством некоторых из них.

Используете Linux и запускаете задачи в cron? Вам интересна архитектура системных приложений в Unix? Тогда нам по пути!

Содержание

• Происхождение видов
• POSIX crontab
• Хит продаж — Vixie cron 3.0pl1
• cron в Debian и Ubuntu
• cronie в Red Hat, Fedora и CentOS
• cronie в SLES и openSUSE
• Устройство Vixie cron
• Послесловие

Происхождение видов

Периодическое выполнение пользовательских или системных программ — очевидная необходимость во всех операционных системах. Поэтому потребность в сервисах, позволяющих централизованно планировать и выполнять задачи, программисты осознали очень давно.

Unix-подобные операционные системы ведут свою родословную от Version 7 Unix, разработанной в 70-х годах прошлого века в Bell Labs в том числе и знаменитым Кеном Томпсоном (англ. Ken Thompson). Вместе c Version 7 Unix поставлялся и cron, сервис для регулярного выполнения задач суперпользователя.

Типичный современный cron — несложная программа, но алгоритм работы оригинального варианта был ещё проще: сервис просыпался раз в минуту, читал табличку с задачами из единственного файл (/etc/lib/crontab) и выполнял для суперпользователя те задачи, которые следовало выполнить в текущую минуту.

Впоследствии усовершенствованные варианты простого и полезного сервиса поставлялись со всеми Unix-подобными операционными системами.

Обобщённые описания формата crontab и базовых принципов работы утилиты в 1992 году были включены в главный стандарт Unix-подобных операционных систем — POSIX — и таким образом cron из стандарта де-факто стал стандартом де-юре.

В 1987 году Пол Викси (англ. Paul Vixie), опросив пользователей Unix на предмет пожеланий к cron, выпустил ещё одну версию демона, исправляющую некоторые проблемы традиционных cron и расширяющую синтаксис файлов-таблиц.

К третьей версии Vixie cron стал отвечать требованиям POSIX, к тому же у программы была либеральная лицензия, вернее не было вообще никакой лицензии, если не считать пожеланий в README: гарантий автор не даёт, имя автора удалять нельзя, а продавать программу можно только вместе с исходным кодом. Эти требования оказались совместимы с принципами набиравшего в те годы популярность свободного ПО, поэтому некоторые ключевые из появившихся в начале 90-х дистрибутивов Linux взяли Vixie cron в качестве системного и развивают его до сих пор.

В частности, Red Hat и SUSE развивают форк Vixie cron — cronie, а Debian и Ubuntu используют оригинальное издание Vixie cron со множеством патчей.

Давайте для начала познакомимся с описанной в POSIX пользовательской утилитой crontab, после чего разберём расширения синтаксиса, представленные в Vixie cron, и использование вариаций Vixie cron в популярных дистрибутивах Linux. И, наконец, вишенка на торте — разбор устройства демона cron.

POSIX crontab

Если оригинальный cron всегда работал для суперпользователя, то современные планировщики чаще имеют дело с задачами обычных пользователей, что более безопасно и удобно.

Сron-ы поставляются комплектом из двух программ: постоянно работающего демона cron и доступной пользователям утилиты crontab. Последняя позволяет редактировать таблицы задач, специфичные для каждого пользователя в системе, демон же запускает задачи из пользовательских и системной таблиц.

В стандарте POSIX никак не описывается поведение демона и формализована только пользовательская программа crontab. Существование механизмов запуска пользовательских задач, конечно, подразумевается, но не описано подробно.

Вызовом утилиты crontab можно сделать четыре вещи: отредактировать пользовательскую таблицу задач в редакторе, загрузить таблицу из файла, показать текущую таблицу задач и очистить таблицу задач. Примеры работы утилиты crontab:

crontab -e # редактировать таблицу задач
crontab -l # показать таблицу задач
crontab -r # удалить таблицу задач
crontab path/to/file.crontab # загрузить таблицу задач из файла

При вызове crontab -e будет использоваться редактор, указанный в стандартной переменной окружения EDITOR.

Сами задачи описаны в следующем формате:

# строки-комментарии игнорируются
#
# задача, выполняемая ежеминутно
* * * * * /path/to/exec -a -b -c
# задача, выполняемая на 10-й минуте каждого часа
10 * * * * /path/to/exec -a -b -c
# задача, выполняемая на 10-й минуте второго часа каждого дня и использующая перенаправление стандартного потока вывода
10 2 * * * /path/to/exec -a -b -c > /tmp/cron-job-output.log

Первые пять полей записей: минуты [1..60], часы [0..23], дни месяца [1..31], месяцы [1..12], дни недели [0..6], где 0 — воскресенье. Последнее, шестое, поле — строка, которая будет выполнена стандартным интерпретатором команд.

В первых пяти полях значения можно перечислять через запятую:

# задача, выполняемая в первую и десятую минуты каждого часа
1,10 * * * * /path/to/exec -a -b -c

Или через дефис:

# задача, выполняемая в каждую из первых десяти минут каждого часа
0-9 * * * * /path/to/exec -a -b -c

Доступ пользователей к планированию задач регулируется в POSIX файлам cron.allow и cron.deny в которых перечисляются, соответственно, пользователи с доступом к crontab и пользователи без доступа к программе. Расположение этих файлов стандарт никак не регламентирует.

Запускаемым программам, согласно стандарту, должны передаваться по меньшей мере четыре переменные окружения:

1. HOME — домашняя директория пользователя.
2. LOGNAME — логин пользователя.
3. PATH — путь, по которому можно найти стандартные утилиты системы.
4. SHELL — путь к использованному командному интерпретатору.

Примечательно, что POSIX ничего не говорит о том, откуда берутся значения для этих переменных.

Хит продаж — Vixie cron 3.0pl1

Общий предок популярных вариантов cron — Vixie cron 3.0pl1, представленный в рассылке comp.sources.unix в 1992 году. Основные возможности этой версии мы и рассмотрим подробнее.

Vixie cron поставляется в двух программах (cron и crontab). Как обычно, демон отвечает за чтение и запуск задач из системной таблицы задач и таблиц задач отдельных пользователей, а утилита crontab — за редактирование пользовательских таблиц.

Таблица задач и файлы конфигурации

Таблица задач суперпользователя расположена в /etc/crontab. Синтаксис системной таблицы соответствует синтаксису Vixie cron с поправкой на то, что в ней шестой колонкой указывается имя пользователя, от лица которого запускается задача:

# Запускается ежеминутно от пользователя vlad
* * * * * vlad /path/to/exec

Таблицы задач обычных пользователей располагаются в /var/cron/tabs/username и используют общий синтаксис. При запуске утилиты crontab от имени пользователя редактируются именно эти файлы.

Управление списками пользователей, имеющих доступ к crontab, происходит в файлах /var/cron/allow и /var/cron/deny, куда достаточно внести имя пользователя отдельной строкой.

Расширенный синтаксис

По сравнению с POSIX crontab решение Пола Викси содержит несколько очень полезных модификаций в синтаксисе таблиц задач утилиты.

Стал доступен новый синтаксис таблиц: например, можно указывать дни недели или месяцы поимённо (Mon, Tue и так далее):

# Запускается ежеминутно по понедельникам и вторникам в январе
* * * Jan Mon,Tue /path/to/exec

Можно указывать шаг, через который запускаются задачи:

# Запускается с шагом в две минуты
*/2 * * * Mon,Tue /path/to/exec

Шаги и интервалы можно смешивать:

# Запускается с шагом в две минуты в первых десять минут каждого часа
0-10/2 * * * * /path/to/exec

Поддерживаются интуитивные альтернативы обычному синтаксису (reboot, yearly, annually, monthly, weekly, daily, midnight, hourly):

# Запускается после перезагрузки системы
@reboot /exec/on/reboot
# Запускается раз в день
@daily /exec/daily
# Запускается раз в час
@hourly /exec/daily

Среда выполнения задач

Vixie cron позволяет менять окружение запускаемых приложений.

Переменные окружения USER, LOGNAME и HOME не просто предоставляются демоном, а берутся из файла passwd. Переменная PATH получает значение «/usr/bin:/bin», а SHELL — «/bin/sh». Значения всех переменных, кроме LOGNAME, можно изменить в таблицах пользователей.

Некоторые переменные окружения (прежде всего SHELL и HOME) используются самим cron для запуска задачи. Вот как может выглядеть использование bash вместо стандартного sh для запуска пользовательских задач:

SHELL=/bin/bash
HOME=/tmp/
# exec будет запущен bash-ем в /tmp/
* * * * * /path/to/exec

В конечном итоге все определённые в таблице переменные окружения (используемые cron или необходимые процессу) будут переданы запущенной задаче.

Для редактирования файлов утилитой crontab используется редактор, указанный в переменной окружения VISUAL или EDITOR. Если в среде, где был запущен crontab, эти переменные не определены, то используется «/usr/ucb/vi» (ucb — это, вероятно, University of California, Berkeley).

cron в Debian и Ubuntu

Разработчики Debian и производных дистрибутивов выпустили сильно модифицированную версию версию Vixie cron 3.0pl1. Отличий в синтаксисе файлов-таблиц нет, для пользователей это тот же самый Vixie cron. Крупнейшие новые возможности: поддержка syslog, SELinux и PAM.

Из менее заметных, но осязаемых изменений — расположение конфигурационных файлов и таблиц задач.

Пользовательские таблицы в Debian располагаются в директории /var/spool/cron/crontabs, системная таблица всё там же — в /etc/crontab. Специфичные для пакетов Debian таблицы задач помещаются в /etc/cron.d, откуда демон cron их автоматически считывает. Управление доступом пользователей регулируется файлами /etc/cron.allow и /etc/cron.deny.

В качестве командной оболочки по умолчанию по-прежнему используется /bin/sh, в роли которого в Debian выступает небольшой POSIX-совместимый шелл dash, запущенный без чтения какой-либо конфигурации (в неинтерактивном режиме).

Сам cron в последних версиях Debian запускается через systemd, а конфигурацию запуска можно посмотреть в /lib/systemd/system/cron.service. Ничего особенного в конфигурации сервиса нет, любое более тонкое управление задачами возможно осуществить через переменные окружения, объявленные прямо в crontab каждого из пользователей.

cronie в RedHat, Fedora и CentOS

cronie — форк Vixie cron версии 4.1. Как и в Debian, синтаксис не менялся, но добавлена поддержка PAM и SELinux, работы в кластере, слежения за файлами при помощи inotify и других возможностей.

Конфигурация по умолчанию находится в обычных местах: системная таблица — в /etc/crontab, пакеты помещают свои таблицы в /etc/cron.d, пользовательские таблицы попадают в /var/spool/cron/crontabs.

Демон запускается под управлением systemd, конфигурация сервиса — /lib/systemd/system/crond.service.

В Red Hat-подобных дистрибутивах при запуске по умолчанию используется /bin/sh, в роли которого выступает стандартный bash. Надо заметить, что при запуске задач cron через /bin/sh командная оболочка bash запускается в POSIX-совместимом режиме и не читает никакой дополнительной конфигурации, работая в неинтерактивном режиме.

cronie в SLES и openSUSE

Немецкий дистрибутив SLES и его дериватив openSUSE используют всё тот же cronie. Демон здесь тоже запускается под systemd, конфигурация сервиса лежит в /usr/lib/systemd/system/cron.service. Конфигурация: /etc/crontab, /etc/cron.d, /var/spool/cron/tabs. В качестве /bin/sh выступает тот же самый bash, запущенный в POSIX-совместимом неинтерактивном режиме.

Устройство Vixie cron

Современные потомки cron по сравнению с Vixie cron не изменились радикально, но всё же обзавелись новыми возможностями, не требующимися для понимания принципов работы программы. Многие из этих расширений оформлены неаккуратно и путают код. Оригинальный же исходный код cron в исполнении Пола Викси читать одно удовольствие.

Поэтому разбор устройства cron я решил провести на примере общей для обеих ветвей развития cron программы — Vixie cron 3.0pl1. Примеры я упрощу, убрав усложняющие чтение ifdef-ы и опустив второстепенные детали.

Работу демона можно разделить на несколько этапов:

1. Инициализация программы.
2. Сбор и обновление списка задач для запуска.
3. Работа главного цикла cron.
4. Запуск задачи.

Разберём их по порядку.

Инициализация

При запуске после проверки аргументов процесса cron устанавливает обработчики сигналов SIGCHLD и SIGHUP. Первый вносит в лог запись о завершении работы дочернего процесса, второй — закрывает файловый дескриптор файла-лога:

signal(SIGCHLD, sigchld_handler);
signal(SIGHUP, sighup_handler);

Демон cron в системе всегда работает один, только в роли суперпользователя и из главной директории cron. Следующие вызовы создают файл-лок с PID-ом процесса-демона, убеждаются, что пользователь правильный и меняют текущую директорию на главную:

acquire_daemonlock(0);
set_cron_uid();
set_cron_cwd();

Выставляется путь по умолчанию, который будет использоваться при запуске процессов:

setenv("PATH", _PATH_DEFPATH, 1);

Дальше процесс «демонизируется»: создаёт дочернюю копию процесса вызовом fork и новую сессию в дочернем процессе (вызов setsid). В родительском процессе больше надобности нет — и он завершает работу:

switch (fork()) {
case -1:
    /* критическая ошибка и завершение работы */
    exit(0);
break;
case 0:
    /* дочерний процесс */
    (void) setsid();
break;
default:
    /* родительский процесс завершает работу */
    _exit(0);
}

Завершение родительского процесса высвобождает лок на файле-локе. Кроме того, требуется обновить PID в файле на дочерний. После этого заполняется база задач:

/* повторный захват лока */
acquire_daemonlock(0);

/* Заполнение БД  */
database.head = NULL;
database.tail = NULL;
database.mtime = (time_t) 0;
load_database(&database);

Дальше cron переходит к главному циклу работы. Но перед этим стоит взглянуть на загрузку списка задач.

Сбор и обновление списка задач

За загрузку списка задач отвечает функция load_database. Она проверяет главный системный crontab и директорию с пользовательскими файлами. Если файлы и директория не менялись, то список задач не перечитывается. В противном случае начинает формироваться новый список задач.

Загрузка системного файла со специальными именами файла и таблицы:

/* если файл системной таблицы изменился, перечитываем */
if (syscron_stat.st_mtime) {
    process_crontab("root", "*system*",
    SYSCRONTAB, &syscron_stat,
    &new_db, old_db);
}

Загрузка пользовательских таблиц в цикле:

while (NULL != (dp = readdir(dir))) {
    char    fname[MAXNAMLEN+1],
            tabname[MAXNAMLEN+1];
    /* читать файлы с точкой не надо*/
    if (dp->d_name[0] == '.')
            continue;
    (void) strcpy(fname, dp->d_name);
    sprintf(tabname, CRON_TAB(fname));
    process_crontab(fname, fname, tabname,
                    &statbuf, &new_db, old_db);
}

После чего старая база данных подменяется новой.

В примерах выше вызов функции process_crontab убеждается в существовании пользователя, соответствующего имени файла таблицы (если только это не суперпользователь), после чего вызывает load_user. Последняя уже читает сам файл построчно:

while ((status = load_env(envstr, file)) >= OK) {
    switch (status) {
    case ERR:
        free_user(u);
        u = NULL;
        goto done;
    case FALSE:
        e = load_entry(file, NULL, pw, envp);
        if (e) {
            e->next = u->crontab;
            u->crontab = e;
        }
        break;
    case TRUE:
        envp = env_set(envp, envstr);
        break;
    }
}

Здесь либо выставляется переменная окружения (строки вида VAR=value) функциями load_env / env_set, либо читается описание задачи (* * * * * /path/to/exec) функцией load_entry.

Сущность entry, которую возвращает load_entry, — это и есть наша задача, помещаемая в общий список задач. В самой функции проводится многословный разбор формата времени, нас же больше интересует формирование переменных окружения и параметров запуска задачи:

/* пользователь и группа для запуска задачи берутся из passwd*/
e->uid = pw->pw_uid;
e->gid = pw->pw_gid;

/* шелл по умолчанию (/bin/sh), если пользователь не указал другое */
e->envp = env_copy(envp);
if (!env_get("SHELL", e->envp)) {
    sprintf(envstr, "SHELL=%s", _PATH_BSHELL);
    e->envp = env_set(e->envp, envstr);
}
/* домашняя директория */
if (!env_get("HOME", e->envp)) {
    sprintf(envstr, "HOME=%s", pw->pw_dir);
    e->envp = env_set(e->envp, envstr);
}
/* путь для поиска программ */
if (!env_get("PATH", e->envp)) {
    sprintf(envstr, "PATH=%s", _PATH_DEFPATH);
    e->envp = env_set(e->envp, envstr);
}
/* имя пользовтеля всегда из passwd */
sprintf(envstr, "%s=%s", "LOGNAME", pw->pw_name);
e->envp = env_set(e->envp, envstr);

С актуальным списком задач и работает главный цикл.

Главный цикл

Оригинальный cron из Version 7 Unix работал совсем просто: в цикле перечитывал конфигурацию, запускал суперпользователем задачи текущей минуты и спал до начала следующей минуты. Этот простой подход на старых машинах требовал слишком много ресурсов.

В SysV была предложена альтернативная версия, в которой демон засыпал либо до ближайшей минуты, для которой определена задача, либо на 30 минут. Ресурсов на перечитывание конфигурации и проверку задач в таком режиме потреблялось меньше, но быстро обновлять список задач стало неудобно.

Vixie cron вернулся к проверке списков задач раз в минуту, благо к концу 80-х ресурсов на стандартных Unix-машинах стало значительно больше:

/* первичная загрузка задач */
load_database(&database);
/* запустить задачи, поставленные к выполнению после перезагрузки системы */
run_reboot_jobs(&database);
/* сделать TargetTime началом ближайшей минуты */
cron_sync();
while (TRUE) {
    /* выполнить задачи, после чего спать до TargetTime с поправкой на время, потраченное на задачи */
    cron_sleep();

    /* перечитать конфигурацию */
    load_database(&database);

    /* собрать задачи для данной минуты */
    cron_tick(&database);

    /* перевести TargetTime на начало следующей минуты */
    TargetTime += 60;
}

Непосредственно выполнением задач занимается функция cron_sleep, вызывающая функции job_runqueue (перебор и запуск задач) и do_command (запуск каждой отдельной задачи). Последнюю функцию стоит разобрать подробнее.

Запуск задачи

Функция do_command исполнена в хорошем Unix-стиле, то есть для асинхронного выполнения задачи она делает fork. Родительский процесс продолжает запуск задач, дочерний — занимается подготовкой процесса задачи:

switch (fork()) {
case -1:
    /*не смогли выполнить fork */
    break;
case 0:
    /* дочерний процесс: на всякий случай еще раз пробуем захватить главный лок */
    acquire_daemonlock(1);
    /* переходим к формированию процесса задачи */
    child_process(e, u);
    /* по завершению дочерний процесс заканчивает работу */
    _exit(OK_EXIT);
    break;
default:
    /* родительский процесс продолжает работу */
    break;
}

В child_process довольно много логики: она принимает стандартные потоки вывода и ошибок на себя, чтобы потом переслать на почту (если в таблице задач указана переменная окружения MAILTO), и, наконец, ждёт завершения работы основного процесса задачи.

Процесс задачи формируется еще одним fork:

switch (vfork()) {
case -1:
    /* при ошибки сразу завершается работа */
    exit(ERROR_EXIT);
case 0:
    /* процесс-внук формирует новую сессию, терминал и т.д.
     */
    (void) setsid();

    /*
     * дальше многословная настройка вывода процесса, опустим для краткости
     */

    /* смена директории, пользователя и группы пользователя,
     * то есть процесс больше не суперпользовательский
     */
    setgid(e->gid);
    setuid(e->uid);
    chdir(env_get("HOME", e->envp));

    /* запуск самой команды
     */
    {
        /* переменная окружения SHELL указывает на интерпретатор для запуска */
        char    *shell = env_get("SHELL", e->envp);

        /* процесс запускается без передачи окружения родительского процесса,
         * то есть именно так, как описано в таблице задач пользователя  */
        execle(shell, shell, "-c", e->cmd, (char *)0, e->envp);

        /* ошибка — и процесс на запустился? завершение работы */
        perror("execl");
        _exit(ERROR_EXIT);
    }
    break;
default:
    /* сам процесс продолжает работу: ждет завершения работы и вывода */
    break;
}

Вот, в общем-то, и весь cron. Какие-то интересные детали, например учёт удалённых пользователей, я опустил, но главное изложил.

Послесловие

Сron — на удивление простая и полезная программа, выполненная в лучших традициях мира Unix. Она не делает ничего лишнего, но свою работу выполняет замечательно на протяжении уже нескольких десятилетий. Ознакомление с кодом той версии, что поставляется с Ubuntu, заняло не больше часа, а удовольствия я получил массу! Надеюсь, я смог поделиться им с вами.

Не знаю, как вам, но мне немного грустно осознавать, что современное программирование с его склонностью к переусложнению и переабстрагированию уже давно не располагает к подобной простоте.

Существует множество современных альтернатив cron: systemd-timers позволяют организовать сложные системы с зависимостями, в fcron можно гибче регулировать потребление ресурсов задачами. Но лично мне всегда хватало простейших crontab.

Словом, любите Unix, используйте простые программы и не забывайте читать маны для вашей платформы!

Вам нужно регулярно запускать скрипт, но вы не хотите запускать его вручную? Или, может быть, вам нужно выполнить команду в определенное время или интервал, но вы не хотите, чтобы процесс монополизировал ваш процессор или память. В любом случае cron jobs идеально подходят для этой задачи. Давайте посмотрим, что это такое, как их настроить и что с ними можно сделать.

Бывают случаи, когда в будущем необходимо автоматически запускать группу задач в определенное время. Эти задачи обычно являются административными, но могут быть любыми – от создания резервных копий базы данных до загрузки электронных писем, когда все спят.

Cron — это планировщик заданий на основе времени в Unix-подобных операционных системах, который запускает определенные задачи в будущем. Название происходит от греческого слова χρόνος (хронос), что означает время.

Наиболее часто используемая версия Cron известна как Vixie Cron. Пол Викси первоначально разработал его в 1987 году.

Терминология Cron Job

• Job: единица работы, серия шагов, чтобы что-то сделать. Например, отправка электронной почты группе пользователей. В этой статье будет использоваться задача, задание, задание cron или событие взаимозаменяемо.
• Daemon: компьютерная программа, которая работает в фоновом режиме, служа различным целям. Daemon часто запускаются во время загрузки. Веб-сервер — это демон, обслуживающий HTTP-запросы. Cron — это Daemon для выполнения запланированных задач.
• Cron Job: задание cron — это запланированное задание. Daemon запускает задание, когда оно должно быть выполнено.
• Webcron:  планировщик заданий на основе времени, который работает в серверной среде. Это альтернатива стандартному Cron, часто на общих веб-хостах, которые не предоставляют доступ к оболочке.

Начало работы с Cron Jobs

Если мы заглянем внутрь /etc каталога, то увидим такие каталоги, как cron.hourly, cron.daily, cron.weeklyи cron.monthly, каждый из которых соответствует определенной частоте выполнения.

Одним из способов планирования наших задач является размещение наших сценариев в соответствующем каталоге. Например, для db_backup.php ежедневного запуска мы поместили его внутрь cron.daily. Если папка для данной частоты отсутствует, нам нужно будет сначала создать ее.

Этот подход использует run-parts скрипт, команду, которая запускает каждый исполняемый файл, который он находит в указанном каталоге.

Это самый простой способ запланировать задачу. Однако, если нам нужна большая гибкость, мы должны использовать Crontab.

Файлы Crontab

Cron использует специальные файлы конфигурации, называемые crontabфайлами, которые содержат список выполняемых заданий. Crontab означает таблицу Cron. Каждая строка в файле crontab называется заданием cron, которое напоминает набор столбцов, разделенных символом пробела. Каждая строка указывает, когда и как часто Cron должен выполнять определенную команду или сценарий.

В файле crontab пустые строки или строки, начинающиеся с #пробелов или табуляции, будут игнорироваться. Строки, начинающиеся с #, считаются комментариями.

Активные строки в crontab являются либо объявлением переменной среды, либо заданием cron. Crontab не разрешает комментарии к активным строкам.

Ниже приведен пример файла crontab с одной записью:

0 0 * * *  /var/www/sites/db_backup.sh

Первая часть 0 0 * * *— это выражение cron, которое определяет частоту выполнения. Вышеуказанное задание cron будет выполняться один раз в день.

Пользователи могут иметь свои собственные файлы crontab, названные в честь их имени пользователя, зарегистрированного в /etc/passwd файле. Все файлы crontab пользовательского уровня находятся в области spool Cron. Вы не должны редактировать эти файлы напрямую. Вместо этого мы должны редактировать их с помощью утилиты crontab командной строки.

Примечание: Каталог spool варьируется в разных дистрибутивах Linux. На Ubuntu это /var/spool/cron/crontabs в то время как в CentOS это /var/spool/cron.

Чтобы отредактировать наш собственный файл crontab:

crontab -e

Приведенная выше команда автоматически откроет файл crontab, принадлежащий нашему пользователю. Если вы еще не выбрали редактор по умолчанию для crontab, вы увидите набор установленных редакторов для выбора. Мы также можем явно выбрать или изменить нужный нам редактор для редактирования файла crontab:

export VISUAL=nano; crontab -e

После сохранения файла и выхода из редактора crontab будет проверен на точность. Если все настроено правильно, файл будет сохранен в каталоге spool.

Каждая команда в файле crontab выполняется с точки зрения пользователя, которому принадлежит crontab. Если ваша команда выполняется как root (sudo), вы не сможете определить этот crontab из своей учетной записи пользователя, если вы не войдете в систему как root.

Список установленных cron jobs, принадлежащих нашему пользователю:

crontab -l

Мы также можем записать наши задания cron в файл и отправить его содержимое в файл crontab следующим образом:

crontab /path/to/the/file/containing/cronjobs.txt

Предыдущая команда перезапишет существующий файл crontab /path/to/the/file/containing/cronjobs.txt.

Чтобы удалить crontab, мы используем -r опцию:

crontab -r

Анатомия записи Crontab

Анатомия записи crontab на уровне пользователя выглядит следующим образом:

 # ┌───────────── min (0 - 59) 
 # │ ┌────────────── hour (0 - 23)
 # │ │ ┌─────────────── day of month (1 - 31)
 # │ │ │ ┌──────────────── month (1 - 12)
 # │ │ │ │ ┌───────────────── day of week (0 - 6) (0 to 6 are Sunday to Saturday, or use names; 7 is Sunday, the same as 0)
 # │ │ │ │ │
 # │ │ │ │ │
 # * * * * *  command to execute

В первых двух полях указывается время (минута и час), в которое будет выполняться задача. Следующие два поля указывают день месяца и месяц. Пятое поле указывает день недели.

Cron выполнит команду, когда минута, час, месяц и день месяца или день недели совпадут с текущим временем.

Если день недели и день месяца имеют определенные значения, событие будет выполняться, когда любое поле соответствует текущему времени. Рассмотрим следующее выражение:

0 0 5-20/5 Feb 2 /path/to/command

Предыдущее задание cron будет выполняться один раз в день каждые пять дней, с 5 по 20 февраля плюс все вторники февраля.

Важно: Когда и день месяца, и день недели имеют определенные значения (не звездочку), он создаст OR условие, то есть оба дня будут совпадать.

Синтаксис в system crontabs (/etc/crontab) немного отличается от crontabs пользовательского уровня. Разница в том, что шестое поле — это не команда, а пользователь, от имени которого мы хотим запустить задание.

* * * * * testuser /path/to/command

Не рекомендуется помещать общесистемные задания cron /etc/crontab, так как этот файл может быть изменен в будущих обновлениях системы. Вместо этого мы помещаем эти задания cron в /etc/cron.d каталог.

Редактирование Crontab других пользователей

Возможно, нам придется редактировать файлы crontab других пользователей. Для этого мы используем -u опцию, как показано ниже:

crontab -u username -e

Примечание Мы можем редактировать файлы crontab других пользователей только как пользователь root или как пользователь с правами администратора.

Некоторые задачи требуют прав администратора. Вы должны добавить их в файл crontab корневого пользователя:

sudo crontab -e

Обратите внимание, что использование sudowith crontab -eбудет редактировать файл crontab корневого пользователя. Если нам нужно отредактировать crontab другого пользователя во время использования sudo, мы должны использовать -u опцию для указания владельца crontab.

Чтобы узнать больше о crontab команде:

man crontab

Стандартные и нестандартные значения Crontab

Поля Crontab принимают числа в качестве значений. Однако мы можем поместить в эти поля и другие структуры данных.

Диапазоны

Мы можем передавать диапазоны чисел:

0 6-18 1-15 * * /path/to/command

Вышеуказанное задание cron будет выполняться с 6 утра до 6 вечера с 1-го по 15-е число каждого месяца в году. Обратите внимание, что указанный диапазон включен, поэтому 1-5 означает 1,2,3,4,5.

Списки

Список — это группа значений, разделенных запятыми. Мы можем иметь списки в качестве значений полей:

0 1,4,5,7 * * * /path/to/command

Приведенный выше синтаксис будет запускать задание cron в 1 am, 4 am, 5 am и 7 am каждый день.

Шаги

Шаги можно использовать с диапазонами или символом звездочки(*). Когда они используются с диапазонами, они указывают количество значений, которые нужно пропустить через конец диапазона. Они определяются «/" символом после диапазона, за которым следует число. Рассмотрим следующий синтаксис:

0 6-18/2 * * * /path/to/command

Вышеуказанное задание cron будет выполняться каждые два часа с 6 утра до 6 вечера.

Когда шаги используются со звездочкой, они просто указывают частоту этого конкретного поля. Например, если мы устанавливаем минуту*/5, это просто означает каждые пять минут.

Мы можем комбинировать списки, диапазоны и шаги вместе, чтобы иметь более гибкое планирование событий:

0 0-10/5,14,15,18-23/3 1 1 * /path/to/command

Вышеуказанное событие будет проходить каждые пять часов с полуночи 1 января до 10 утра, 2 вечера, 3 вечера, а также каждые три часа с 6 вечера до 11 вечера.

Имена

Для полей месяц и день недели мы можем использовать первые три буквы определенного дня или месяца, например Sat, sun, Feb, Sep, и т.д.

* * * Feb,mar sat,sun /path/to/command

Предыдущее задание cron будет выполняться только по субботам и воскресеньям февраля и марта.

Обратите внимание, что имена не чувствительны к регистру. Диапазоны не допускаются при использовании имен.

Предопределенные определения

Некоторые реализации cron могут поддерживать некоторые специальные строки. Эти строки используются вместо первых пяти полей, каждое из которых определяет определенную частоту:

• @annual, @annual Запуск один раз в год в полночь 1 января (0 0 1 1 *)
• @ежемесячный запуск один раз в месяц, в полночь первого дня месяца (0 0 1 * *)
• @еженедельный запуск один раз в неделю в полночь воскресенья (0 0 * * 0)
• @ежедневный запуск один раз в день в полночь (0 0 * * *)
• @почасовой запуск в начале каждого часа (0 * * * *)
• @reboot Запуск один раз при запуске

Несколько команд в одном задании Cron

Мы можем выполнить несколько команд в одном задании cron, разделив их точкой с запятой (;).

* * * * * /path/to/command-1; /path/to/command-2

Если выполняемые команды зависят друг от друга, мы можем использовать двойной амперсанд (&&) между ними. В результате вторая команда не будет выполняться, если первая не выполняется.

* * * * * /path/to/command-1 && /path/to/command-2

Переменные среды

Переменные среды в файлах crontab имеют форму VARIABLE_NAME = VALUE (пробелы вокруг знака равенства необязательны). Cron не создает никаких файлов запуска из домашнего каталога пользователя (когда он работает на уровне пользователя cron). Это означает, что мы должны вручную установить любые пользовательские настройки, требуемые нашими задачами.

Daemon Cron автоматически устанавливает некоторые переменные среды при запуске. HOMEи LOGNAME устанавливаются из информации владельца crontab /etc/passwd в. Однако мы можем переопределить эти значения в нашем файле crontab, если в этом есть необходимость.

Есть также еще несколько переменных, например SHELL, указывающих оболочку, которая выполняет команды. Это /bin/sh по умолчанию. Мы также можем установить PATH, в котором искать программы.

PATH = /usr/bin;/usr/local/bin

Важно: мы должны заключать значение в кавычки, когда в значении есть пробел. Обратите внимание, что значения являются обычными строками. Они не будут интерпретироваться или анализироваться каким-либо образом.

Разные часовые пояса

Cron использует настройку часового пояса системы при оценке записей crontab. Это может вызвать проблемы для многопользовательских систем с пользователями, базирующимися в разных часовых поясах. Чтобы обойти эту проблему, мы можем добавить переменную среды с именем CRON_TZ в наш файл crontab. В результате все записи crontab будут проанализированы на основе указанного часового пояса.

Как Cron интерпретирует файлы Crontab

После запуска Cron он выполняет поиск в области катушки, чтобы найти и загрузить файлы crontab в память. Он дополнительно проверяет /etc/crontab/etc/cron.d каталоги и или для системных crontabs.

После загрузки crontabs в память Cron проверяет загруженные crontabs поминутно, выполняя события, которые должны быть выполнены.

Кроме того, Cron регулярно (каждую минуту) проверяет, изменилось ли modtimeвремя изменения каталога spool. Если это так, он проверяет modetimeвсе загруженные crontabs и перезагружает те, которые изменились. Вот почему нам не нужно перезапускать Daemon при установке нового задания cron.

Разрешения Cron

Мы можем указать, какой пользователь должен иметь возможность использовать Cron, а какой нет. Есть два файла, которые играют важную роль, когда дело доходит до разрешений cron: /etc/cron.allowи /etc/cron.deny.

Если /etc/cron.allow существует, то наше имя пользователя должно быть указано в этом файле для использования crontab. Если /etc/cron.deny существует, он не должен содержать наше имя пользователя. Если ни один из этих файлов не существует, то на основе параметров конфигурации, зависящих от сайта, либо суперпользователь, либо все пользователи смогут использовать crontab команду. Например, в Ubuntu, если ни один файл не существует, все пользователи могут использовать crontab по умолчанию.

Мы можем поместить ALL/etc/cron.deny файл, чтобы запретить всем пользователям использовать cron:

echo ALL > /etc/cron.deny

Примечание: Если мы создаем /etc/cron.allow файл, нет необходимости создавать /etc/cron.deny файл, поскольку он имеет тот же эффект, что и создание /etc/cron.deny файла с ALL в нем.

Перенаправление вывода

Мы можем перенаправить вывод нашего задания cron в файл, если команда (или скрипт) имеет какой-либо вывод:

* * * * * /path/to/php /path/to/the/command >> /var/log/cron.log

Мы можем перенаправить стандартный вывод на dev null, чтобы не получить электронное письмо, но все же отправить стандартное сообщение об ошибке:

* * * * * /path/to/php /path/to/the/command > /dev/null

Чтобы запретить Cron отправлять нам какие-либо электронные письма, мы меняем соответствующую запись crontab, как показано ниже:

* * * * * /path/to/php /path/to/the/command > /dev/null 2>&1

Это означает “отправить как стандартный вывод, так и вывод ошибки в забвение”.

Отправьте вывод по электронной почте

Выходные данные отправляются по почте владельцу crontab или электронной почте (адресам), указанным в переменной MAILTOсреды (если стандартный вывод или стандартная ошибка не перенаправляются, как указано выше).

Если MAILTO установлено значение empty, в результате выполнения задания cron электронное письмо отправлено не будет.

Мы можем установить несколько писем, разделив их запятыми:

MAILTO=admin@example.com,dev@example.com
* * * * * /path/to/command

Cron и PHP

Обычно мы запускаем наши скрипты командной строки PHP, используя исполняемый файл PHP.

php script.php

В качестве альтернативы мы можем использовать shebang в начале скрипта и указать на исполняемый файл PHP:

#! /usr/bin/php

<?php

// PHP code here

В результате мы можем выполнить файл, вызвав его по имени. Тем не менее, мы должны убедиться, что у нас есть разрешение на его выполнение.

Чтобы иметь более надежные скрипты командной строки PHP, мы можем использовать сторонние компоненты для создания консольных приложений, таких как Symfony Console Component или Laravel Artisan. Эта статья является хорошим началом для использования консольного компонента Symfony.

Узнайте больше о создании консольных команд с помощью Laravel Artisan.

Перекрытия задач

Бывают случаи, когда запланированные задачи занимают гораздо больше времени, чем ожидалось. Это приведет к перекрытиям, то есть некоторые задачи могут выполняться одновременно. В некоторых случаях это может не вызвать проблемы, но когда они изменяют одни и те же данные в базе данных, у нас возникнет проблема. Мы можем преодолеть это, увеличив частоту выполнения задач. Тем не менее, нет никакой гарантии, что эти перекрытия не повторятся.

У нас есть несколько вариантов предотвращения перекрытия заданий cron.

Использование Flock

Flock — хороший инструмент для управления файлами блокировки из сценариев оболочки или командной строки. Эти файлы блокировки полезны для того, чтобы узнать, запущен ли скрипт.

При использовании совместно с Cron соответствующие задания cron не запускаются, если файл блокировки существует. Вы можете установить Flock, используя apt-get или yum, в зависимости от дистрибутива Linux.

apt-get install flock

Или:

yum install flock

Рассмотрим следующую запись crontab:

* * * * * /usr/bin/flock --timeout=1 /path/to/cron.lock /usr/bin/php /path/to/scripts.php

В предыдущем примере flock ищет /path/to/cron.lock. Если блокировка будет получена за одну секунду, она запустит скрипт. В противном случае он потерпит неудачу с кодом выхода 1.

Использование механизма блокировки в скриптах

Если задание cron выполняет сценарий, мы можем реализовать механизм блокировки в сценарии. Рассмотрим следующий PHP-скрипт:

<?php
$lockfile = sys_get_temp_dir() . '/' md5(__FILE__) . '.lock';
$pid      = file_exists($lockfile) ? trim(file_get_contents($lockfile)) : null;

if (is_null($pid) || posix_getsid($pid) === false) {

    // Do something here
    
    // And then create/update the lock file
    file_put_contents($lockfile, getmypid());

} else {
    exit('Another instance of the script is already running.');
}

В предыдущем коде мы сохраняем pid текущий PHP-процесс в файле, который находится в системном tempкаталоге. Каждый PHP-скрипт имеет свой собственный файл блокировки, который является MD5-хэшем имени файла скрипта.

Сначала мы проверяем, существует ли файл блокировки, а затем получаем его содержимое, которое является идентификатором процесса последнего запущенного экземпляра скрипта. Затем мы передаем pid PHP-функцию posix_getsid , которая возвращает идентификатор сеанса процесса. Если posix_getsid возвращается false, это означает, что процесс больше не работает, и мы можем безопасно запустить новый экземпляр.

Anacron

Одна из проблем с Cron заключается в том, что он предполагает, что система работает непрерывно (24 часа в сутки). Это вызывает проблемы для машин, которые не работают весь день (например, персональные компьютеры). Если система отключается в течение запланированного времени выполнения задачи, Cron не будет выполнять эту задачу задним числом.

Anacron не является заменой Cron, но решает эту проблему. Он выполняет команды один раз в день, неделю или месяц, но не поминутно или ежечасно, как это делает Cron. Однако это гарантия того, что задача будет выполнена, даже если система отключится на непредвиденный период времени.

Только root или пользователь с правами администратора может управлять задачами Anacron. Anacron не работает в фоновом режиме, как Daemon, а только один раз, выполняя задачи, которые должны быть выполнены.

Anacron использует файл конфигурации (так же, как crontab) с именем anacrontabs. Этот файл находится в /etc каталоге.

Содержимое этого файла выглядит следующим образом:

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly

В anacrontab файле мы можем установить частоты только с периодом nдней, за которым следует время задержки в минутах. Это время задержки просто для того, чтобы убедиться, что задачи не выполняются одновременно.

Третий столбец — это уникальное имя, которое идентифицирует задачу в файлах журнала Anacron.

Четвертый столбец — это фактическая команда для запуска.

Рассмотрим следующую запись:

1       5       cron.daily              nice run-parts /etc/cron.daily

Эти задачи выполняются ежедневно, через пять минут после запуска Anacron. Он использует run-partsдля выполнения всех скриптов внутри/etc/cron.daily.

Вторая запись в списке выше выполняется каждые 7 дней (еженедельно) с задержкой 25 минут.

Столкновение между Cron и Anacron

Как вы, наверное, заметили, Cron также настроен на выполнение скриптов внутри /etc/cron.* каталогов. Различные варианты Linux обрабатывают такое возможное столкновение с Anacron по-разному. В Ubuntu Cron проверяет, присутствует ли Anacron в системе, и если это так, он не будет выполнять сценарии в /etc/cron.* каталогах.

В других версиях Linux Cron обновляет временные метки Anacron при выполнении задач. Anacron не будет выполнять их, если Cron уже запустил их.

Быстрое устранение неполадок

Абсолютный путь к командам

Это хорошая привычка использовать абсолютные пути ко всем исполняемым файлам, которые мы используем в файле crontab.

* * * * * /usr/local/bin/php /absolute/path/to/the/command

Убедитесь, что Daemon cron запущен

Если наши задачи вообще не выполняются, сначала нам нужно убедиться, что Daemon Cron запущен:

ps aux | grep crond

Вывод должен быть похож на этот:

root      7481  0.0  0.0 116860  1180 ?        Ss    2015   0:49 crond

Проверка /etc/cron.allowи /etc/cron.deny файлы

Когда задания cron не выполняются, нам нужно проверить /etc/cron.allow, существует ли. Если это так, нам нужно убедиться, что мы перечислили наше имя пользователя в этом файле. И если /etc/cron.deny существует, нам нужно убедиться, что наше имя пользователя не указано в этом файле.

Если мы редактируем файл crontab пользователя, в то время как пользователь не существует в /etc/cron.allow файле, включая пользователя в /etc/cron.allow не будет запускать cron, пока мы не отредактируем файл crontab.

Разрешение на выполнение

Мы должны убедиться, что владелец crontab имеет разрешения на выполнение для всех команд и сценариев в файле crontab. В противном случае cron не будет работать. Вы можете добавить разрешения на выполнение в любую папку или файл с помощью:

chmod +x /some/file.php

Новый символ строки

Каждая запись в crontab должна заканчиваться новой строкой. Это означает, что после последней записи crontab должна быть пустая строка, иначе последнее задание cron никогда не будет выполнено.

Завершение

Cron — это Daemon, выполняющий список событий, запланированных на будущее. Мы определяем эти задания в специальных файлах конфигурации, называемых файлами crontab. Пользователи могут иметь свой собственный файл crontab, если им разрешено использовать Cron на основе /etc/cron.allow или /etc/cron.deny files. В дополнение к заданиям cron на уровне пользователя Cron также загружает общесистемные задания cron, которые немного отличаются по синтаксису.

Наши задачи обычно PHP скрипты или утилиты командной строки. В системах, которые не работают все время, мы можем использовать Anacron для запуска событий, которые происходят в течение nнескольких дней.

При работе с Cron мы также должны знать о задачах, перекрывающих друг друга, чтобы предотвратить потерю данных. После завершения задания cron выходные данные будут отправлены владельцу crontab и/или электронной почты, указанной в переменной MAILTO среды.

Разбираемся с тем, что представляет собой Cron, как он работает и зачем нужен. Пытаемся обуздать его параметры, чтобы планировать задачи на своем сервере без лишних затрат сил и времени.

Что такое Cron и crontab?

Если в двух словах, то Cron – это планировщик задач. Если подробнее, то это утилита, позволяющая выполнять скрипты на сервере в назначенное время с заранее определенной периодичностью.

К примеру, у вас есть скрипт, который собирает какие-либо статистические данные каждый день в 6 часов вечера. Такие скрипты называют «заданиями», а их логика описывается в специальных файлах под названием сrontab.

crontab – это таблица с расписанием запуска скриптов и программ, оформленная в специальном формате, который умеет считывать компьютер. Для каждого пользователя системы создается отдельный crontab-файл со своим расписанием. Эта встроенная в Linux утилита доступна на низком уровне в каждом дистрибутиве.

В Linux-дистрибутивах с поддержкой systemd Cron считается устаревшим решением, его заменили утилитой systemd.timer. Ее предназначение и функциональность не отличается, но фактически частота использования Cron все еще выше.

Для чего обычно используют Cron?

Обычно Cron заставляют повторять вполне очевидные задачи в духе регулярного создания резервных копий данных. Но это не все.

1. Некоторые пользователи с помощью планировщика корректируют системное время. На многих компьютерах оно настраивается через Network Time Protocol. А так как этот протокол настраивает только время ОС, время, установленное для «железа», может отличаться. Cron позволяют регулярно корректировать время, установленное для аппаратного обеспечения, в соответствии со временем ОС.
2. Еще один популярный сценарий – создание оповещений, появляющихся каждое утро и рассказывающих о состоянии компьютера. В эти сообщения может входить любая полезная для пользователя информация.
3. Cron иногда работает даже без ведома пользователя. Эту утилиту используют такие сервисы, как Logwatch, logrotate и Rootkit Hunter. Повторяющиеся задачи они настраивают, как и пользователи, через Cron.

С помощью Cron пользователи автоматизируют самые разные задачи, сокращая вмешательство системного администратора в работу сервера.

Базовые принципы работы с Cron и crontab (через панель управления)

Многие хостинг-провайдеры предлагают отдельное меню в панели управления для настройки расписания запланированного выполнения скриптов.

Разберем подобное меню на примере панели управления Timeweb. Чтобы создать новую задачу, необходимо открыть раздел Crontab в боковой панели веб-интерфейса, кликнуть по кнопке «Добавить новую задачу» и указать параметры повторяющейся команды.​ Поговорим подробнее о параметрах. 

• Сначала надо придумать для команды название (подойдет любой текст без спецсимволов).
• Затем указываем исполнителя (нужно выбрать, будет ли планировщик работать с исполняемым файлом, PHP-скриптом или HTTP-запросом).
• В графе «Путь до файла» вводим абсолютный путь до скрипта, запуск которого хотим запланировать. К примеру: /home/u/myusername/mytestscript.php. При желании можно воспользоваться встроенным файловым менеджером и выбрать заранее предзагруженный на сервер скрипт.
• После этого указываем периодичность выполнения выбранного скрипта или исполняемого файла (в списке доступны предустановки в духе «Каждую минуту» или «Раз в день», но можно выбрать и пункт «Продвинутые настройки»).
• Кликаем по кнопке «Создать задачу».

На этом все. Скрипт запланирован и будет регулярно повторяться.

Базовые принципы работы с Cron и crontab (через SSH-протокол)

Планировать задачи через панель управления удобно, но не всегда возможно. Не все хостинг-провайдеры предлагают такие функциональные веб-интерфейсы. В этом случае придется воспользоваться командной строкой, подключившись к серверу по протоколу Secure Shell.

Для работы с планировщиком в системе есть ряд команд, помогающих решать основные задачи:

• crontab -e – открывает конфигурационный файл (поговорим о нем чуть подробнее в разделе с первичной настройкой).
• crontab -l – показывает список задач из конфигурационного файла (все, что было запланировано).
• crontab -r – удаляет конфигурационный файл вместе со всеми запланированными задачами.
• сrontab -v – показывает, когда в последний раз открывался конфигурационный файл.

Чтобы запланировать задачи, используя командную строку, необходимо выполнить базовую настройку Cron, проверить, не установлены ли ограничения, и заполнить расписание задач в соответствии с синтаксисом сrontab.

Первичная настройка Cron

Как мы уже выяснили ранее, планировщик черпает параметры для выполнения своих задач из crontab-файлов (таблиц с расписанием). У каждого пользователя, включая root, должен быть свой crontab-файл. По умолчанию он не существуют, поэтому придется создать его вручную.

Для этого существует команда crontab -e. Она автоматически генерирует таблицу в директории /var/spool/cron.

Вновь созданный файл будет пустым текстовым полем. Необходимо добавлять в него все параметры самостоятельно с нуля, опираясь на синтаксис сrontab (более подробно поговорим о нем ниже). После ввода параметров нужно сохранить параметры редактора, нажав на клавишу F2, а затем покинуть конфигурационный файл, нажав на клавишу F10. При введении корректных параметров в терминале отобразится строка crontab: installing new crontab.

Опытные разработчики и системные администраторы не рекомендуют использовать для редактирования расписания текстовые редакторы в духе Nano, Emacs или Vi. Команды crontab позволяют не только внести изменения в таблицу запланированных задач, но и перезапустить фоновый процесс crond, отвечающий за работу утилиты после сохранения настроек.

Ограничения Cron

У Cron есть функция установки ограничений на использование, задающихся через два специальных файла: cron.allow и cron.deny.

Первый файл находится в директории /usr/lib/cron/cron.allow и содержит в себе список учетных записей (имен пользователей), которые имеют право на планирование задач с помощью встроенных системных утилит.

Второй файл находится в директории /usr/lib/cron/cron.deny. В нем указываются имена пользователей, которые не могут запускать встроенный в систему планировщик задач.

Если первого файла не существует, то любой пользователь может планировать задачи с помощью встроенного в систему планировщика, но только при условии, что его имени нет во втором файле. Если удалить оба файла, то каждый пользователь сможет планировать задачи без ограничений.

Синтаксис crontab

# crontab -e
SHELL=/bin/bash
MAILTO=mymail@someprovider.com
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

# Детали смотрите в следующих разделах

# Примеры оформления задач в планировщике (формат данных):
# .---------------- минуты (0 - 59)
# |  .------------- часы (0 - 23)
# |  |  .---------- дни месяца (1 - 31)
# |  |  |  .------- сами месяцы (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- дни недели (0 - 6) (0 или 7 это воскресенье в зависимости от настроек системы) можно использовать сокращения типа mon,tue,wed,thu,fri,sat,sun
# |  |  |  |  |
# *  *  *  *  * имя пользоваться  команда, которую нужно запустить

# создание копии всей операционной системы с помощью кастомного скрипта 
01 01 * * * /usr/local/bin/bckp -vbd1 ; /usr/local/bin/bckp -vbd2

# установка соответствия между временем операционной системы и "железа"
03 05 * * * /sbin/hwclock --systohc

# проведение обновления операционной системы в заданный период времени
25 04 1 * * /usr/bin/apt-get update

Первые три линии кода в таблице отвечают за первичную настройку. Сначала указывается оболочка, в которой будет работать Cron. У утилиты нет каких-либо предпочтений, поэтому можно указать любую на собственное усмотрение (в нашем примере это bash). Затем указывается адрес электронный почты, на который будут отправляться отчеты о работе планировщика. И напоследок указывается путь к окружению.

Ниже находятся параметры, используемые для запуска процессов в определенный период времени. В комментариях описан базовый синтаксис, включающий в себя формат времени, имя пользователя и команду, которая должна быть запущена.

В нашем случае указаны команды:

02 04 5 * * /usr/local/bin/bckp -vbd1 ; /usr/local/bin/bckp -vbd2
04 06 * * * /sbin/hwclock –systohc
10 05 5 * * /usr/bin/apt-get update
05 * * * * rm /home/myusername/tmp/*

Примеры использования Cron в командной строке

Команда

02 04 5 * * /usr/local/bin/bckp -vbd1 ; /usr/local/bin/bckp -vbd2

создает в таблице расписания задачу на запуск скрипта под названием bckp (представим, что такой существует), который создает резервную копию всей системы на стороннем накопителе. Он выполняется 5 числа каждого месяца в 4 часа 2 минуты утра. Это видно по числовым значениям. Звездочки же указывают на отсутствие конкретного значения. Cron воспринимает их как «выполнять каждый раз», то есть каждый месяц, день или неделю.

Команда

04 06 * * * /sbin/hwclock –systohc

меняет время аппаратного обеспечения на то, что используется в системе. Делает это каждый день, каждую неделю и каждый месяц в 6 часов 4 минуты утра. Как видите, здесь пропущено третье значение. Поэтому команда и запускается ежедневно, так как нет более конкретных правил.

Команда

10 05 5 * * /usr/bin/apt-get update

запускает обновление пакетов с помощью пакетного менеджера apt каждый месяц 5 числа в 05:10.

Команда

05 * * * * rm /home/myusername/tmp/*

удаляет содержимое папки с временными файлами для конкретного пользователя (меня) на пятой минуте (первый пункт) каждого часа. Так как определенные значения отсутствуют для всех остальных пунктов, получается, что скрипт готов выполняться каждый день, каждый месяц и каждый час. Но первое значение указано, поэтому он будет дожидаться пятой минуты и запускаться в этот момент. То есть в 12:05, 13:05, 14:05 и т.п.

Как видите, разобраться с базовыми командами несложно.

Другие примеры настройки Cron

На примере команды для удаления временных файлов разберем пару-тройку нестандартных настроек расписания.

К примеру, некоторые показатели можно вводить не в виде цифр, а в виде сокращенных слов. Чтобы запускать удаление временных файлов каждую пятницу в 4 часа вечера, необходимо ввести в crontab:

00 16 * * Fri rm /home/myusername/tmp/*

Если не указывать в планировщике точных вводных, то выбранный скрипт будет выполняться каждую минуту:

* * * * * rm /home/myusername/tmp/*

Можно заставить планировщик выполнять задачу только в определенные месяцы. Чтобы запускать удаление временных файлов 1 февраля, 1 мая и 1 сентября в половину первого ночи, необходимо ввести в crontab:

30 00 1 2,5,9 * * rm /home/myusername/tmp/*

Некоторые скрипты необходимо выполнять только по будням, поэтому в Cron есть возможность исключить некоторые дни недели из расписания:

00 16 * * 1–5 rm /home/myusername/tmp/*

Часы тоже можно делить. Например, запускать ту или иную задачу каждые 3 часа. Для этого нужно поставить слэш в графе с установкой времени по часам:

*/5 */2 * * * rm /home/myusername/tmp/*

Вместо заключения

О работе с Cron стоит знать еще пару важных вещей.

Во-первых, всегда указывайте корректный почтовый адрес в параметрах. Это позволит собирать информацию о запускаемых по расписанию задачах. В этих письмах содержится и информация о возникающих ошибках. Во-вторых, при указании «исполнителя» в панели управления Timeweb важно делать корректный выбор, чтобы он соответствовал запускаемой задаче. В-третьих, информацию о работе Cron можно собирать в отдельный файл с помощью команд в духе:

30 18 * * * rm /home/myusername/tmp/* > /home/myusername/cronlogs/clean_tmp_dir.log

На этом все. Следуйте инструкциям, не путайте порядок параметров и внимательно изучайте журнал ошибок, если что-то пойдет не так. После недолгой практики вы поймете, что работать с Cron не так уж и сложно!

Системным администраторам, да и обычным пользователям часто приходится автоматизировать различные задачи по обслуживанию и работе с Linux с помощью скриптов. Это очень удобно, вы просто запускаете скрипт, и он делает все что необходимо без вашего вмешательства. Следующий шаг в этом пути — настроить автоматически запуск нужного скрипта в нужное время.

Именно для этих задач в Linux используется системный сервис cron. Это планировщик, который позволяет выполнять нужные вам скрипты раз в час, раз в день, неделю или месяц, а также в любое заданное вами время или через любой интервал. Программа часто используется даже другими службами операционной системы. В этой статье мы рассмотрим как выполняется настройка Cron и разберем основные часто используемые примеры.

Фактически, Cron — это сервис, как и большинство других сервисов Linux, он запускается при старте системы и работает в фоновом режиме. Его основная задача выполнять нужные процессы в нужное время. Существует несколько конфигурационных файлов, из которых он берет информацию о том что и когда нужно выполнять. Сервис открывает файл /etc/crontab, в котором указаны все нужные данные. Часто, в современных дистрибутивах там прописан запуск утилиты run-parts, которая запускает нужные скрипты из следующих папок:

• /etc/cron.minutely — каждую минуту;
• /etc/cron.hourly — каждый час;
• /etc/cron.daily — каждый день;
• /etc/cron.weekly — каждую неделю;
• /etc/cron.monthly — каждый месяц.

В этих папках должны находиться скрипты, которые нужно выполнять с указанным интервалом. Скрипты должны иметь права на выполнение и их имя не должно содержать точки. Это очень сильно облегчает работу с планировщиком для новых пользователей. Также в файле crontab прописан запуск команды anacron, которая работает так же как и cron, только предназначена для задач, которые нужно выполнять раз в длительный период, например, раз в день, неделю, месяц, год.

Она позволяет выполнять их даже если компьютер работает не всегда и время от времени выключается. Дата выполнения задания последний раз записывается в файл /var/spool/anacron, а затем, при следующем запуске anacron проверяет был ли запущен нужный процесс в нужное время, и если нет, то запускает его. Сам же сервис cron больше рассчитан на выполнение задач в течение дня или с точно расписанным временем и датой.

Настройка Cron

Для настройки времени, даты и интервала когда нужно выполнять задание используется специальный синтаксис файла cron и специальная команда. Конечно, вы всегда можете отредактировать файл /etc/crontab, но этого делать не рекомендуется. Вместо этого, есть команда crontab:

crontab -e

Ее всегда желательно выполнять с опцией -e, тогда для редактирования правил будет использован ваш текстовый редактор по умолчанию. Команда открывает вам временный файл, в котором уже представлены все текущие правила cron и вы можете добавить новые. После завершения работы команды cron файл будет обработан и все правила будут добавлены в /var/spool/cron/crontabs/имя_пользователя причем добавленные процессы будут запускаться именно от того пользователя, от которого вы их добавляли.

Поэтому тут нужно быть аккуратным, и если вам нужно выполнять скрипты от рута, то и crontab нужно выполнить от рута, а не от пользователя. Это часто становится причиной проблем.

Синтаксис crontab

Как я уже говорил, время задается особым синтаксисом, давайте рассмотрим синтаксис настройки одной задачи cron:

минута час день месяц день_недели /путь/к/исполняемому/файлу

Нужно сказать, что обязательно нужно писать полный путь к команде, потому что для команд, запускаемых от имени cron переменная среды PATH будет отличаться, и сервис просто не сможет найти вашу команду. Это вторая самая распространенная причина проблем с Cron. Дата и время указываются с помощью цифр или символа ‘*’. Этот символ означает, что нужно выполнять каждый раз, если в первом поле — то каждую минуту и так далее. Ну а теперь перейдем к примерам.

Примеры настройки cron

Сначала можно посмотреть задачи cron для суперпользователя, для этого можно воспользоваться опцией -l:

crontab -l

Вы можете удалить все существующие задачи командой -r:

crontab -r

Давайте предположим, что нам нужно запускать от имени суперпользователя наш скрипт по адресу /usr/local/bin/serve. Какой-нибудь обслуживающий скрипт. Самый простой пример — запускать его каждую минуту:

* * * * * /usr/local/bin/serve

Далее, усложним, будем запускать каждый час, в нулевую минуту:

0 * * * * /usr/local/bin/serve

Еще дальше:

Запускаем в нулевую минуту нулевого часа, каждый день, это в 12 ночи:

0 0 * * * /usr/local/bin/serve

Если идти так дальше, то можно запускать в первый день каждого месяца:

0 0 1 * * /usr/local/bin/serve

Можно в любой день, например, 15 числа:

0 0 15 * * /usr/local/bin/serve

В первый день недели первого месяца года, 0 часов 0 минут:

0 0 * 1 0 /usr/local/bin/serve

Или в нулевой день недели каждого месяца:

0 0 * * 0 /usr/local/bin/serve

Вы можете выбрать любую минуту, час и день недели, например, 15.30 во вторник:

30 15 * * 2 /usr/local/bin/serve

Понедельник считается первым днем, воскресенье — это седьмой или нулевой день. Еще можно писать сокращенное название дня недели, например sun — воскресенье:

30 15 * * sun /usr/local/bin/serve

Для того чтобы указать определенный интервал нужно использовать символ «-«, например, каждый час, с семи утра до семи вечера:

0 7-19  * * * /usr/local/bin/serve

Если нужно запустить команду несколько раз, можно использовать разделитель «,». Например, запустим скрипт в 5 и 35 минут пятого (16:05 и 16:35), каждый день:

5,35 16  * * * /usr/local/bin/serve

Вы можете захотеть не указывать отдельно время, а просто указать интервал, с которым нужно запускать скрипт, например, раз в 10 минут. Для этого используется разделитель косая черта — «/»:

*/10 * * * * /usr/local/bin/serve

Кроме того, для некоторых часто используемых наборов были придуманы переменные, вот они:

• @reboot — при загрузке, только один раз;
• @yearly, @annually — раз год;
• @monthly — раз в месяц;
• @weekly — раз в неделю;
• @daily, @midnight — каждый день;
•  @hourly — каждый час.

Например, вот так просто будет выглядеть команда запуска скрипта раз в час:

@hourly /usr/local/bin/serve

Если же вы собрались добавить скрипт в одну из папок, то, как я уже говорил, нужно чтобы его имя было без точек и у него были права на выполнение:

sudo vi /etc/corn.daily/backup

#!/bin/bash
......


Скрипт должен выглядеть подобным образом. Теперь вы знаете как настроить cron, осталось проверить как все работает.

Отладка работы

После того как вы настроили правила, еще хотелось бы проверить работают ли они. Для этого ждем того времени, когда скрипт уже должен быть выполнен и смотрим лог cron. Иногда он находится в /var/log/cron, а иногда пишется в syslog. Например, у меня в crontab есть такая строка:

Она должна выполняться в 19.40 каждый день, теперь смотрим лог:

grep CRON /var/log/syslog

И видим что в нашем логе она действительно есть и выполняется целиком успешно. Если бы были какие-либо ошибки, то тут же было бы выведено сообщение.

Если нужно проверить скрипт, который находится в одной из специализированных папок, то тут еще проще, просто запустите run-paths, передав ей в параметр нужную папку или даже сам скрипт:

sudo run-paths /etc/cron.daily/

Дальше вы увидите весь вывод, включая вывод скрипта и сможете быстро понять в чем проблема.

Выводы

В этой статье мы рассмотрели как выполняется настройка cron для удобного планирования автоматических задач. Надеюсь, эта информация была полезной для вас.

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.