3.13. CRON – Запуск скрипта по расписанию
Вызвать запуск нужного вам скрипта с помощью планировщика CRON можно двумя способами: c помощью эмуляции загрузки определённого URL вашего сайта, что приводит к запуску нужного вам скрипта и с помощью прямого запуска скрипта без обращений к веб-сервисам по протоколу HTTP/HTTPS.
Способ №1 — Эмуляция загрузки URL сайта
Данный способ максимально прост и приводит к запуску скрипта в среде обычной работы сайта на хостинге. Существенным плюсом этого метода является возможность передачи нужному скрипту дополнительных GET параметров, в которых могут храниться ключи запуска, идентификаторы, токены и т.д. Минусом этого метода является то, что обращение к скрипту выполняется с помощью HTTP запроса к веб-сервису, что накладывает дополнительное ограничение на время выполнения запроса.
В панели управления ISPManager в разделе «Инструменты» — «Планировщик (cron)» добавьте задание в формате:
Важно использовать двойные кавычки для URL вашего CRON скрипта, т.к. в противном случае не будут переданы все параметры HTTP GET запросов
Пример CRON задания, при работе сайта по протоколу HTTP
В данном примере скрипт «cron.php» будет вызван с помощью интерпретатора PHP, установленного для сайта «website.com». При этом скрипту будет передан HTTP GET параметр «action» со значением «perform».
Пример CRON задания сайта работающего по протоколу HTTPS
Если ваш сайт использует для работы защищённый протокол HTTPS, тогда крайне рекомендуем использовать параметр wget «—no-check-certificate», отключающий проверку используемого на сайте SSL сертификата.
Способ №2 — Прямой запуск скрипта CRON
Описанный способ запускает необходимый вам скрипт с помощью прямого запуска интерпретатора, который исключает какие-либо обращения к веб-сервисам. Сильной стороной этого метода является отсутствие каких-либо прослоек в виде веб-сервисов при выполнении. Минусом является необходимость прямого указания интерпретатора для запуска того или иного скрипта, а для PHP ещё и требует указание версии интерпретатора, например PHP 7.1 или 8.0. К неприятным особенностям данного метода можно отнести и отсутствие возможности передачи POST/GET параметров. Единственное что можно передать − это ENV параметры, о чём будет написано ниже.
Для использования данного метода, в панели управления ISPManager в разделе «Инструменты» — «Планировщик (cron)» нужно добавить задание в формате:
Пример CRON с передачей PHP скрипту ENV параметра
Как ранее описывалось, при таком методе запуска, единственной возможностью передать какой-либо дополнительный параметр будет использование ENV переменных в формате:
В данном примере скрипту «cron.php» был передан ENV параметр «MODE» со значением «production».
Отображение добавленного CRON задания
После добавления задания планировщика CRON, оно должно отобразится в перечне заданий. Для того, чтобы пользователи не получали большое количество мусорных сообщений, связанных с выполнением CRON, к каждому заданию автоматически будет добавлено » >/dev/null 2>&1 «. Наличие такой конструкции в конце команды является нормальным поведением панели управления хостингом и планировщика CRON.
Настройте Cron в планировщике задач Windows
Это первый этап нашего пути к автоматизации cron. Перейдем ко второй части с планировщиком заданий. Коснитесь клавиши Windows на клавиатуре и найдите «Планировщик заданий». Запустите ярлык «Планировщик заданий».
Когда он запустится, загляните в раздел «Действия» и выберите «Создать базовую задачу».
Откроется мастер основных задач. Во-первых, он попросит вас назвать задачу и дать ей описание. Вы можете ввести здесь все, что хотите. Мы назвали задачу «cron», и ее описание звучало так: «Задача для запуска cron при запуске системы». Теперь нажмите «Далее».
В следующем разделе мы перейдем к делу. Во-первых, Windows хочет знать, когда мы хотим запустить задачу. Установите переключатель «Когда компьютер запускается» и нажмите «Далее».
В следующем разделе мы хотим «Начать программу». Этот вариант выбран по умолчанию, поэтому нажмите «Далее».
Теперь нам нужно указать программу, которую мы хотим запустить, а именно WSL. Введите в текстовое поле «Программа / сценарий» следующее: C: Windows System32 wsl.exe
Нам также нужно добавить некоторые аргументы, поскольку все, что мы до сих пор сделали, это запустили WSL, но внутри WSL нам нужно указать Ubuntu запустить cron. Итак, в поле «Добавить аргументы» добавьте: sudo / usr / sbin / service cron start
Еще раз нажмите «Далее», установите флажок «Открыть диалоговое окно свойств, когда я нажму« Готово », а затем нажмите« Готово ».
Задача создана, но нужно сделать последнее, чтобы убедиться, что все работает. Откроется новое окно, в котором отображается сводная информация о созданной вами задаче, но она настроена на запуск только тогда, когда вы вошли в систему. Нам нужно выбрать переключатель с надписью «Запускать независимо от того, вошел ли пользователь в систему или нет», а затем нажать «ОК».
Теперь давайте протестируем нашу задачу двумя способами. Сначала в главном окне Планировщика заданий прокрутите вниз, пока не увидите название своей задачи. Если вы использовали имя «cron», оно должно находиться в верхней части списка. Щелкните задачу правой кнопкой мыши и выберите «Выполнить».
Затем вернитесь к своему терминалу WSL и введите sudo service cron status, и он должен сказать, что cron запущен. Если это не так, еще раз проверьте, правильно ли вы ввели все на предыдущих шагах.
Если при первой проверке все заработало, пришло время для большого теста. Перезагрузите компьютер, а когда вернетесь, откройте терминал WSL и запустите sudo service cron status, который должен сообщить, что cron теперь запущен.
Поздравляю! Вы сделали свой первый шаг в большой автоматизированный мир. Если cron работает в фоновом режиме, задания cron, которые вы настраиваете в WSL, будут автоматически запускаться по расписанию.
Настройка Cron
Для настройки времени, даты и интервала когда нужно выполнять задание используется специальный синтаксис файла cron и специальная команда. Конечно, вы всегда можете отредактировать файл /etc/crontab, но этого делать не рекомендуется. Вместо этого, есть команда crontab:
Ее всегда желательно выполнять с опцией -e, тогда для редактирования правил будет использован ваш текстовый редактор по умолчанию. Команда открывает вам временный файл, в котором уже представлены все текущие правила cron и вы можете добавить новые. После завершения работы команды cron файл будет обработан и все правила будут добавлены в /var/spool/cron/crontabs/имя_пользователя причем добавленные процессы будут запускаться именно от того пользователя, от которого вы их добавляли.
Поэтому тут нужно быть аккуратным, и если вам нужно выполнять скрипты от рута, то и crontab нужно выполнить от рута, а не от пользователя. Это часто становится причиной проблем.
Синтаксис crontab
Как я уже говорил, время задается особым синтаксисом, давайте рассмотрим синтаксис настройки одной задачи cron:
минута час день месяц день_недели /путь/к/исполняемому/файлу
Нужно сказать, что обязательно нужно писать полный путь к команде, потому что для команд, запускаемых от имени cron переменная среды PATH будет отличаться, и сервис просто не сможет найти вашу команду. Это вторая самая распространенная причина проблем с Cron. Дата и время указываются с помощью цифр или символа ‘*’. Этот символ означает, что нужно выполнять каждый раз, если в первом поле — то каждую минуту и так далее. Ну а теперь перейдем к примерам.
Примеры настройки cron
Сначала можно посмотреть задачи cron для суперпользователя, для этого можно воспользоваться опцией -l:
Вы можете удалить все существующие задачи командой -r:
Давайте предположим, что нам нужно запускать от имени суперпользователя наш скрипт по адресу /usr/local/bin/serve. Какой-нибудь обслуживающий скрипт. Самый простой пример — запускать его каждую минуту:
Далее, усложним, будем запускать каждый час, в нулевую минуту:
Еще дальше:
Запускаем в нулевую минуту нулевого часа, каждый день, это в 12 ночи:
Если идти так дальше, то можно запускать в первый день каждого месяца:
Можно в любой день, например, 15 числа:
В первый день недели первого месяца года, 0 часов 0 минут:
Или в нулевой день недели каждого месяца:
Вы можете выбрать любую минуту, час и день недели, например, 15.30 во вторник:
Понедельник считается первым днем, воскресенье — это седьмой или нулевой день. Еще можно писать сокращенное название дня недели, например sun — воскресенье:
Для того чтобы указать определенный интервал нужно использовать символ «-«, например, каждый час, с семи утра до семи вечера:
Если нужно запустить команду несколько раз, можно использовать разделитель «,». Например, запустим скрипт в 5 и 35 минут пятого (16:05 и 16:35), каждый день:
Вы можете захотеть не указывать отдельно время, а просто указать интервал, с которым нужно запускать скрипт, например, раз в 10 минут. Для этого используется разделитель косая черта — «/»:
Кроме того, для некоторых часто используемых наборов были придуманы переменные, вот они:
- @reboot — при загрузке, только один раз;
- @yearly, @annually — раз год;
- @monthly — раз в месяц;
- @weekly — раз в неделю;
- @daily, @midnight — каждый день;
- @hourly — каждый час.
Например, вот так просто будет выглядеть команда запуска скрипта раз в час:
Если же вы собрались добавить скрипт в одну из папок, то, как я уже говорил, нужно чтобы его имя было без точек и у него были права на выполнение:
Скрипт должен выглядеть подобным образом. Теперь вы знаете как настроить cron, осталось проверить как все работает.
Отладка работы
После того как вы настроили правила, еще хотелось бы проверить работают ли они. Для этого ждем того времени, когда скрипт уже должен быть выполнен и смотрим лог cron. Иногда он находится в /var/log/cron, а иногда пишется в syslog. Например, у меня в crontab есть такая строка:
Она должна выполняться в 19.40 каждый день, теперь смотрим лог:
И видим что в нашем логе она действительно есть и выполняется целиком успешно. Если бы были какие-либо ошибки, то тут же было бы выведено сообщение.
Если нужно проверить скрипт, который находится в одной из специализированных папок, то тут еще проще, просто запустите run-paths, передав ей в параметр нужную папку или даже сам скрипт:
Дальше вы увидите весь вывод, включая вывод скрипта и сможете быстро понять в чем проблема.
Как составить расписание задач с помощью Cron
Звучит просто: для планирования задач просто добавьте их в свой crontab. Поскольку crontab — это специальный файл конфигурации, редактировать его вручную не рекомендуется. Вместо этого используйте команду . Чтобы отредактировать crontabs root или других пользователей, запустите команду с правами администратора и добавьте их имя пользователя после опции -u:
Файл crontab состоит из двух разделов. Первый содержит переменные среды, которые устанавливаются автоматически. Вы можете безопасно изменять переменные PATH, HOME и SHELL и изменять переменную MAIL.
Вторая часть файла — это фактическое «расписание» с вашими запланированными заданиями. Каждая задача занимает строку (строку) в таблице со столбцами, представляющими следующие значения:
Чтобы успешно планировать задачи, вам нужно немного узнать о синтаксисе crontab:
- Числа должны быть целыми числами (целыми числами), и вы можете использовать звездочку (*) в любом из столбцов в качестве подстановочного знака, что означает «каждую минуту / день / месяц…».
- В столбце «День месяца» старайтесь не устанавливать дату, которая не встречается в месяце, указанном в столбце «Месяц» (например, 30 февраля).
- Столбцы «Месяц» и «День недели» принимают короткие имена для месяцев и дней соответственно и нечувствительны к регистру.
- В столбце «День недели» 0 и 7 обозначают воскресенье. В столбце «Час» требуется формат «военное время» (24 часа), но вы не можете использовать число 24 — вместо этого 0 означает 12:00. Это происходит потому, что значения минут, часов и дня недели начинаются с 0 вместо 1.
- Секунды не поддерживаются, поэтому вы не можете запланировать задачу на определенную секунду.
Что вы можете сделать, так это запланировать интервалы времени с использованием дефиса (14-22 в разделе «Часы» будут запускать задачу непрерывно с 14:00 до 22:00) или запустить одну задачу несколько раз, определив список через запятую (1, 3,5 в «День недели» будет запускать задание в понедельник, среду и пятницу).
Между тем, значения шага представлены косой чертой (/), и они указывают количество пропусков в пределах диапазона; например, 3-20 / 3 в разделе «Часы» будет запускать задачу каждые три часа с 3:00 до 20:00. Это полезно, если вы хотите повторять задачи каждые X часов, поскольку вы можете объединить звездочку и шаг (* / ИКС). Вы можете комбинировать диапазоны со списками и шаги с диапазонами, если вы используете числа. Другими словами, такие комбинации, как «джан-мар» или «вт, пт-вс» не допускаются.
В качестве альтернативы, вместо установки значения для каждого столбца, вы можете просто написать @weekly, @yearly, @monthly, @daily или @hourly в начале строки, а затем команду. Запланированные так, задачи будут запускаться при первой возможности, поэтому @weekly будет выполняться в полночь первого дня недели. Если вы хотите запустить задачу сразу после запуска системы (re), используйте команду @reboot.
В этом примере мы запланировали резервное копирование каждый день на 08:20 и 20:20. Обои меняются автоматически каждые три дня в 19:00, и скрипт проверяет наличие новых подкастов каждый понедельник в 10:20 и 20:20. Напоминание о дне рождения назначено на 25 марта и выполняется каждые 30 минут в течение указанного периода времени. Наконец, скрипт проверяет электронную почту каждые 15 минут с 8 до 20, но только в рабочие дни. Вы можете свободно организовать свой crontab с пробелами и табуляциями между столбцами, но не внутри них (не ставьте пробелы между запятыми, дефисами и косой чертой).
Если все это звучит слишком сложно, не волнуйтесь — вы всегда можете положиться на Интернет. Такие инструменты, как Crontab Generator , Crontab.guru и Corntab, помогут вам создавать задания cron, не зная синтаксиса crontab. Они показывают, когда задание будет выполнено следующим, и предоставляют шаблоны для часто используемых выражений. Crontab.guru — лучший из всех, потому что он позволяет вам протестировать синтаксис crontab в режиме реального времени, чтобы вы могли сразу увидеть, как ваши изменения повлияют на расписание.
Использование cronbase
Код Системный crontab по умолчанию
*/15 * * * * test -x /usr/sbin/run-crons && /usr/sbin/run-crons 0 * * * * rm -f /var/spool/cron/lastrun/cron.hourly 0 3 * * * rm -f /var/spool/cron/lastrun/cron.daily 15 4 * * 6 rm -f /var/spool/cron/lastrun/cron.weekly 30 5 1 * * rm -f /var/spool/cron/lastrun/cron.monthly
Чтобы избежать углубления в излишние подробности, предположим, что эти команды будут фактически запускать ваши сценарии каждый час, день, неделю и месяц. Этот метод планирования задач cron имеет несколько важных преимуществ:
- они будут запускаться даже когда компьютер был выключен, в то время, когда им было необходимо выполниться;
- облегчается работа сопроводителей пакета по размещению сценариев в тех хорошо определенных местах;
- администратор точно знаете где хранятся задачи cron и crontab, что делает легким процесс создания резервных копий и восстановления этой части системы.
ЗаметкаИ снова, полезно отметить, что vixie cron, cronie и bcron автоматически считывают содержимое файла /etc/crontab, в то время как dcron и fcron нет. Пожалуйста прочитайте раздел , чтобы изучить это подробнее.
Что такое WP Cron
WP Cron — это встроенный в ядро WordPress планировщик, позволяющий выполнять различные задачи строго по заранее заданному расписанию, например:
- Публикация запланированных записей;
- Проверка обновлений ядра WordPress;
- Проверка обновлений плагинов (если плагин зарегистрирован в репозитории плагинов WordPress);
- Проверка обновлений тем (если тема есть в репозитории тем WordPress);
- Рассылка email уведомлений;
- И прочее подобное.
Преимущество WP Cron в том, что он абсолютно не зависит от настроек сервера и будет работать на любой платформе. Про недостатки будет ниже, когда дойдём до оптимизации настроек, а пока пару примеров, как создать и добавить своё событие в планировщик.
Как посмотреть список ежедневных заданий Cron
Просмотреть список ежедневных заданий cron можно с помощью следующей команды:
$ ls -la /etc/cron.daily/ total 72 drwxr-xr-x 2 root root 4096 Apr 24 20:46 . drwxr-xr-x 96 root root 4096 May 19 17:12 .. -rw-r--r-- 1 root root 102 Feb 9 2013 .placeholder -rwxr-xr-x 1 root root 376 Apr 4 2014 apport -rwxr-xr-x 1 root root 15481 Apr 10 2014 apt -rwxr-xr-x 1 root root 314 Feb 18 2014 aptitude -rwxr-xr-x 1 root root 355 Jun 4 2013 bsdmainutils -rwxr-xr-x 1 root root 256 Mar 7 2014 dpkg -rwxr-xr-x 1 root root 372 Jan 22 2014 logrotate -rwxr-xr-x 1 root root 1261 Sep 23 2014 man-db -rwxr-xr-x 1 root root 435 Jun 20 2013 mlocate -rwxr-xr-x 1 root root 249 Feb 17 2014 passwd -rwxr-xr-x 1 root root 2417 May 13 2013 popularity-contest -rwxr-xr-x 1 root root 214 Mar 27 2017 update-notifier-common -rwxr-xr-x 1 root root 328 Jul 18 2014 upstart
Что такое Крон?
Cron — это системная служба, которая работает в фоновом режиме, проверяет запланированные задачи и выполняет их, если обнаружит. Задачи, также называемые « заданиями cron» »- определены в специальных конфигурационных файлах (crontabs), которые cron сканирует каждую минуту. Несколько версий cron можно найти в разных дистрибутивах Linux. Например, форка cron в Fedora называется cronie , и есть также fcron , bcron и dcron . У некоторых есть дополнительные функции, в то время как другие больше сосредоточены на безопасности, но все они основаны на одной и той же идее.
Это руководство написано для vixie-cron, самой распространенной версии cron, которую вы найдете в Ubuntu и ее производных. Хотя большинство инструкций применимо и к другим реализациям cron, могут быть небольшие отличия, поэтому проверьте их руководства, если вы решите переключиться.
Что такое Crontab?
Если вы серьезно относитесь к управлению своим временем, возможно, у вас есть какой-то календарь. — приложение или хотя бы лист бумаги. Crontab очень похож на календарь вашего компьютера. Он содержит информацию о запланированных задачах, сообщая cron, какие команды запускать и в какое время.
На самом деле, в вашей системе есть несколько crontabs. У каждого пользователя есть свой crontab, включая root (администратор). Пользовательские crontabs хранятся в . Команда выведет список файла crontab для текущего пользователя. Вы можете проверить корневой crontab с помощью .
Кроме того, существует системный файл crontab который используется для общесистемных задач. Обычно они принимают форму исполняемых скриптов, принадлежащих пользователю root, которые папках , , и , и в некоторых дистрибутивах также папка . Вообще говоря, вам не нужно иметь дело с этими задачами, так как большинство из них создаются автоматически установленными приложениями.
Cron не запускается по умолчанию
В Windows 10 и Windows 11 cron входит в состав сред Linux, таких как Ubuntu. Проблема в том, что WSL не запускает cron автоматически, а это означает, что ваши автоматические задачи не выполняются по умолчанию.
Чтобы исправить это, вы можете запускать cron вручную каждый раз, когда открываете командную строку, но ручной запуск инструмента, который должен автоматизировать задачи, вроде как упускает суть.
К счастью, есть простой способ исправить это, и он требует использования планировщика заданий.
Если вы никогда не использовали cron в Linux для выполнения задач, ознакомьтесь с нашим предыдущим руководством о том, как планировать задачи в Linux. Для наших целей здесь мы предполагаем, что вы уже создали несколько заданий cron в своей установке WSL и вам нужна помощь, чтобы они работали, а не постоянно присматривали за cron.
В этом руководстве мы собираемся использовать службу sudo для проверки и запуска cron, что является рекомендуемым способом остановки и запуска служб в современных сборках Ubuntu — самого популярного дистрибутива для WSL.
Также обратите внимание, что в этом руководстве предполагается, что у вас есть права администратора в вашей версии WSL. Если вы единственный пользователь своего ПК и включили WSL самостоятельно, у вас есть права администратора
Совет: это работает и в подсистеме Windows для Linux в Windows 11, а не только в Windows 10.
Ошибки, связанные с WP Cron
There was a problem spawning a call to the WP-Cron system on your site
There was a problem spawning a call to the WP-Cron system on your site. This means WP-Cron events on your site may not work. The problem was: cURL error 7: Failed to connect example.com port 80 443: connection refused
Ошибка выше означает, что curl не может получить доступ к сайту по стандартным портам или .
Вы можете решить эту проблему, включив альтернативный вариант для работы WP Cron, прописав в :
define('ALTERNATE_WP_CRON', true);
Однако, у этого подхода есть недостаток — иногда к адресам страниц будут добавляться параметры . Если Вас это не смущает, выбирайте его, он самый простой в настройке. Если нет — расскажу, как убрать из адреса страницы и настроить серверный планировщик cron взамен WP Cron.
Убираем doing_wp_cron из URL
?doing_wp_cron= появляется в адресе страницы, когда используется альтернативная версия , то есть, в корне сайта в файле определена константа:
define('ALTERNATE_WP_CRON', true);
Как правило, её включают, когда WP Cron не работает в стандартном варианте. Вам нужно постараться избежать её использования:
// Отключаем альтернативную версию WP CRON
define('ALTERNATE_WP_CRON', false);
Если WP Cron не заработает или будет выдавать ошибку в работе, можно полностью отключить WP Cron и использовать серверный крон (подробнее были выше).
Также, не лишним будет настроить редирект с на оригинальную версию страницы:
- Как сделать редирект из ?doing_wp_cron= в NGINX
-
# В секции location / location / { # ... if ( $arg_doing_wp_cron ) { # Если в query string есть запрос ?doing_wp_cron= return 301 $uri; # Редиректим на основной адрес } # Тут обычно далее идёт try_files $uri $uri/ /index.php?$args # ... } - Как сделать редирект из ?doing_wp_cron= в .htaccess (Apache)
-
# Прописываем блок в самом начале .htaccess <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron= RewriteRule (.*) /$1? </IfModule>
Бывает так, что, казалось бы, WP Cron отключен (всё сделано по инструкции выше), однако, в логах всё равно появляются отметки о том, что идут стандартные запросы
127.0.0.1 - - [08/Jun/2017:06:38:49 +0300] "POST /wp-cron.php?doing_wp_cron=1496893129.1262209415435791015625 HTTP/1.0" 200 236 "https://sheensay.ru/wp-cron.php?doing_wp_cron=1496893129.1262209415435791015625" "WordPress/4.7.5; https://sheensay.ru"
Дело в том, что тут может быть так, что Вы неверно прописали отключение WP Cron, а именно, строку прописали в самом конце файла . Обязательно перенесите её к :
define( 'WP_DEBUG', false ); define( 'DISABLE_WP_CRON', true );
Далее, попробуйте очистить все запланированные задания (об этом ниже).
WP Cron очень сильно тормозит, валятся ошибки, что делать?
Для начала, установите плагин WP Crontrol (про него описано выше). Затем зайдите в Инструменты — Cron Events ():
Список событий в WP Crontrol
Если страница не открывается, либо открывается, но в её таблице очень много позиций, значит, стоит их очистить.
Самое простое: через functions.php:
- Открываете functions.php и прямо в самом начале файла под прописываете:
<?php update_option('cron', '');и сохраняете результат;
- Открываете любую страницу сайта;
- Возвращаетесь в и удаляете строку , сохраняете результат;
- Снова открываете Инструменты — Cron Events и смотрите, таблица должна придти в норму (быть пустой или иметь мало значений).
Всё, теперь WP Cron должен работать нормально. Но я советую отключить его и настроить серверный планировщик (инструкция выше), тогда сайт будет работать, как часы.
Есть ли альтернативы Cron?
В то время как cron является в значительной степени стандартным планировщиком задач для Linux. , это, конечно, не единственный. Команда at идеально подходит для быстрых одноразовых заданий, которые можно запланировать прямо из командной строки, без специальных файлов конфигурации. Если вам нужно больше, есть GNUbatch , который вводит понятие зависимости. С помощью GNUbatch вы можете установить конкретные условия для каждого задания или сделать запланированное задание зависимым от предыдущего. Нечто подобное можно достичь с помощью системных таймеров . Хотя таймеры systemd менее удобны в настройке, чем cron, системные запоминающие устройства могут помнить, пропустила ли задача свое расписание, когда компьютер был выключен, и запускать его при следующем включении.
Это то, что cron не может сделать в одиночку. Таким образом, он подходит для серверов и компьютеров, которые постоянно работают, но он не будет выполнять работу, которая была запланирована, когда компьютер был выключен. Это где анакрон вступает в игру. Технически это не «альтернатива» или замена cron. Вместо этого anacron дополняет cron и должен использоваться вместе с ним, что имеет место во многих дистрибутивах Linux, включая продукты на основе Ubuntu и Ubuntu. Anacron регистрирует время последнего выполнения задачи и проверяет наличие пропущенных экземпляров при выключении системы. Он будет запускать их при включении компьютера, но каждую задачу можно выполнять только один раз в день.
Некоторые версии cron, такие как fcron, по умолчанию предлагают функции anacron. Опытные пользователи, возможно, захотят взглянуть на Hcron или SuperCron , которые вносят множество улучшений в базовые функции cron, но в то же время являются сложными в управлении.
Использование anacron
Как было упомянуто ранее, anacron используется на системах, не предназначенных для непрерывной работы (подобно большинству настольных компьютеров). Его файл конфигурации по умолчанию, /etc/anacrontab, обычно выглядит так:
Файл
SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # format: period delay job-identifier command 1 5 cron.daily run-parts /etc/cron.daily 7 10 cron.weekly run-parts /etc/cron.weekly 30 15 cron.monthly run-parts /etc/cron.monthly
Главным различием между этим файлом crontab и другими является то, что у anacron-а нет фиксированной даты/часа для планирования работы, но только период между каждым запуском. Когда anacron запущен, он проверит содержимое набора файлов в /var/spool/anacron и вычислит, не истекла ли соответствующая запись в файле конфигурации с момента предыдущего запуска. Если это произошло, то команда вызывается снова.
В заключение, важно закомментировать какие-либо совпадающие записи в любом другом cron, установленном на системе, так, как в следующем примере с файлом crontab программы vixie-cron:
Файл
# для vixie-cron # $Header: /var/cvsroot/gentoo-x86/sys-process/vixie-cron/files/crontab-3.0.1-r4,v 1.3 2011/09/20 15:13:51 idl0r Exp $ # Глобальные переменные SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # проверять сценарии в cron.hourly, cron.daily, cron.weekly и cron.monthly 59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly #9 3 * * * root rm -f /var/spool/cron/lastrun/cron.daily #19 4 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly #29 5 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly #*/10 * * * * root test -x /usr/sbin/run-crons && /usr/sbin/run-crons @hourly root test ! -e /var/spool/cron/lastrun/cron.hourly && touch /var/spool/cron/lastrun/cron.hourly && run-parts --report /etc/cron.hourly
Без этого, части daily, weekly и monthly будут выполняться — в разное время — как демоном cron, так и anacron, приводя к возможным повторениям выполнения работ.
Недостатки WP Cron
Вся суть механизма работы встроеного планировщика заключается в том, что при каждом посещении сайта на WordPress любым пользователем идёт обращение к файлу . Тот, в свою очередь, при каждом обращении проверяет расписание, и если время исполнения какого-то события в очереди наступило или уже прошло, то запускает его. Отсюда, понятно, какие могут быть недостатки у данного подхода:
- Если у сайта большой трафик, то обращения к WP Cron будут слишком частыми, избыточными, что на сайтах с большой нагрузкой трафика может вызывать некоторые проблемы с производительностью сервера;
- Если у сайта мало посетителей, то WP Cron может сильно запаздывать в работе.
Отсюда вывод — если есть возможность, постарайтесь настроить серверный cron взамен встроенному, а встроенный WP Cron отключить (инструкция будет далее).
«Жду ваших указаний»
Мы подробно рассмотрели что нужно сделать, чтобы компьютер периодически
выполнял какие-то работы без нашего участия. А что, если нужно заставить его
выполнить какую-то работу только один раз. Например, выключиться в полночь или
еще что-нибудь в этом роде. Для таких случаев в Linux имеется еще один демон — atd,
который, так же как и crond, постоянно находится «на посту». В этом вы можете убедиться,
выполнив команду
$ ps -ax | grep atd
Для того, чтобы задать работу этому демону, применяются команды at
и batch.
Команда at в простейшем случае запускается с единственным параметром —
временем выполнения задания:
$ at TIME
После этого появляется следующее предупреждение:
warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh at>
и программа ожидает ввода вашего задания. В качестве задания может использоваться любая
команда оболочки (в том числе скрипты). После завершения ввода команды надо нажать комбинацию
клавиш . В ответ вы увидите сообщение о том, что ваше задание принято под таким-то номером:
job 4 at 2002-09-26 12:15
Вы можете просмотреть очередь ждущих своего времени заданий с помощью
команды atq (к сожалению, выводятся только номера ожидающих
выполнения работ и время их выполнения, а содержание задания, то есть
вызываемая команда, не выводится). Если
вы не суперпользователь, вам будут показаны только ваши задания. Суперпользователь видит список
заданий, введенных всеми пользователями системы. С помощью команды atrm вы можете удалить
задание из этой очереди. Для этого надо указать его номер в качестве параметра команды atrm.
Посмотрим теперь как правильно задать время выполнения вашего задания, то есть правила
формирования параметра TIME для команды at. В простейшем варианте указывается только час и минута
запуска задания, разделенные двоеточием: «hh:mm». Можно указывать время «в американском стиле»,
добавив после минут окончание AM (до полудня) или PM (после полудня). Если сегодня указанное время
уже прошло, задание будет выполняться завтра. Допускается прямо указать команде at, что задание
должно быть выполнено сегодня (at 10:00PM today) или завтра (at 10:00PM tomorrow).
Можно также указать дату выполнения задания в формате
MMDDYY, или MM/DD/YY, или DD.MM.YY. Допускается использовать название месяца с числовым указанием дня и
(необязательным) указанием года. При этом указание на время выполнения в течение заданного дня должно
стоять перед указанием даты, например at 10:00PM Jul 31. Можно также указать программе at,
что выполнение задания нужно повторить несколько раз. Для этого после указания времени добавляют количество
повторений с указанием через какой интервал (час, день, неделя или месяц) надо повторить задание. Например,
по команде at 10:00PM + 3 days задание будет выполняться в 10 вечера сегодня и еще в течение
3 дней в то же время. В общем, вариантов указания времени выполнения задания существует множество,
их полная спецификация приведена в файле /usr/sharedoc/at-3.1.8/timespec (цифры 3.1.8 обозначают версию утилиты
at и у вас могут быть другими).
Как и в случае с демоном crond, суперпользователь может лишить некоторых пользователей
права запускать команду at, прописав их имена в специальный файл /etc/at.deny,
либо же разрешить использовать at только тем пользователям, имена которых перечислены
в файле /etc/at.allow. Причем оболочка сначала ищет файл /etc/at.allow и, если он есть,
проверяет наличие вашего имени в нем. Второй файл уже не анализируется. Если же файла /etc/at.allow
не существует, проверяется /etc/at.deny, и вам разрешается выполнить at, если ваше имя в этом
файле не встречается. Если ни того, ни другого файла не существует, программу at может запускать
только суперпользователь. В Red Hat Linux по умолчанию создается пустой файл /etc/at.deny, то
есть давать задания демону atd могут все пользователи.
Кроме выполнения заданий в указанное время демон atd может выполнять какие-то работы
в периоды низкой загруженности системы. Задания на
этот случай формулируются с помощью утилиты batch и ждут своего часа в очереди. Когда
загрузка системы снизится до уровня, указанного параметром -l (задается
при запуске atd, по умолчанию равен 0.8),
задания из очереди запускаются на выполнение.
Подготовьте Linux
Первое, что нам нужно сделать, это разрешить компьютеру запускать cron без пароля. Когда вы запускаете такую службу, как cron, вы используете команду sudo service cron start. Но для этой команды требуется пароль, к которому у Windows не будет доступа при запуске. Чтобы решить эту проблему, нужно отключить требование пароля для этой команды.
Для этого откройте окно терминала WSL и введите sudo visudo. Нажмите Enter на клавиатуре, введите свой пароль Linux и снова нажмите клавишу Enter. Если вы используете Ubuntu, это открывает файл «sudoers» с помощью удобного для начинающих текстового редактора командной строки Nano. Sudoers — это файл для системных администраторов, который может изменять привилегии и права доступа пользователей.
Добавьте следующую команду в конец файла sudoers, а затем нажмите Ctrl + o для сохранения и Ctrl + x для выхода из файла.
% sudo ALL = NOPASSWD: / usr / sbin / service cron start
Эта команда sudoers говорит, что любому пользователю, имеющему достаточно прав для использования команды sudo (которая должна включать вас), не требуется пароль для запуска команды sudo service cron start, которая запускает демон cron.
После сохранения файла вы можете проверить, выполняет ли команда свою работу, набрав sudo service cron start, и она должна запускать cron без запроса пароля. Если это сработало, давайте снова выключим cron, чтобы мы могли проверить, правильно ли работает задача, которую мы создаем на следующем шаге. Для этого запустите sudo service cron stop.
Заключение
Итак, теперь вы в общих чертах знаете, как задать вашему компьютеру «работу на
дом» (подробнее смотрите в man-страницах ). Дерзайте! Только имейте в виду, что те команды,
которые вы прописываете в crontab-файлах, должны быть написаны без ошибок.
Дело в том, что если команда задана с ошибкой, результатом ее выполнения, в лучшем
случае, будет появление в вашем почтовом ящике сообщения об ошибке. Проснувшись утром вы
не обнаружите тех положительных результатов, на которые рассчитывали, задавая с вечера
работу вашему электронному другу. Не говоря уж о гораздо более неприятной ситуации, когда
увидев результаты выполнения «домашнего задания», вы испытаете желание ударить по компьютеру кувалдой.
Помните, что источником всех ошибок является не компьютер, а его владелец. Компьютер пока что
не более чем «тупая» машина, которая слепо и точно выполняет все, что вы ему задали. Поэтому,
прежде чем прописать задание на ночь, несколько раз проверьте, как оно будет выполняться
под вашим присмотром.
