Что такое cron?

Cron — это стандартный инструмент в Unix-подобных системах, предназначенный для выполнения задач в установленное время или периодически. Он основан на файлах cron, в которых определены задания и их расписание. Эти файлы хранятся в каталоге /etc/cron.d/ или /var/spool/cron/ и обычно недоступны для редактирования напрямую.

Работа с cron

Создание и редактирование cron-задач

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

crontab -e

Она открывает текстовый редактор, в котором можно определить расписание и команду для выполнения. Например, чтобы запустить скрипт “myscript.sh” каждый день в 2 часа ночи, добавьте следующую строку:

0 2 * * * /путь/к/скрипту/myscript.sh

Редактировать команды другого пользователя можно так:

sudo crontab -u username -e

Листинг задач

Список текущих cron-задач можно просмотреть с помощью команды:

crontab -l

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

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

sudo crontab -u username -l

Удаление задач

Эта команда удаляет все cron-задачи пользователя:

crontab -r

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

crontab -l

чтобы увидеть ее номер, а затем:

crontab -r номер

Вывод результата в лог-файл

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

* * * * * /путь/к/вашему/скрипту.sh >> /путь/к/лог-файлу.log 2>&1

Здесь >> используется для добавления вывода в конец файла, 2>&1 перенаправляет стандартные ошибки в стандартный вывод, чтобы они также попадали в лог-файл.

Указание времени выполнения задач

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

* * * * *
- - - - -
| | | | |
| | | | +----- День недели (0 - воскресенье, 1 - понедельник, ..., 6 - суббота)
| | | +------- Месяц (1 - январь, 2 - февраль, ..., 12 - декабрь)
| | +--------- День месяца (1 - 31)
| +----------- Час (0 - 23)
+------------- Минуты (0 - 59)

Каждое поле может принимать определенные значения или диапазоны значений, а также знаки “*” (звездочка) и “/” (косая черта).

• *: Означает “каждый”. Например, если в поле минут стоит “*”, это означает, что задача будет выполняться каждую минуту.
• число: Определенное значение. Например, если в поле часов стоит “3”, задача будет выполняться в 3 часа.
• число-число: Диапазон значений. Например, “1-5” в поле дней недели означает с понедельника по пятницу.
• */число: Каждый определенный интервал. Например, “*/15” в поле минут означает каждые 15 минут.

Примеры:

Запуск задачи каждый день в 3 часа утра:

0 3 * * *

Запуск задачи каждый понедельник и среду в 12:30:

30 12 * * 1,3

Запуск задачи каждый час:

0 * * * *

Запуск задачи каждый день в 5 утра и 8 вечера:

0 5,20 * * *

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

Эта проблема довольно серьёзная, так как ip адрес сервера после такой рассылки обычно попадает в различные “чёрные списки”, из-за чего и легитимную почту с сервера перестают принимать многие почтовые сервисы. И удалить ip из этих “чёрных списков” не всегда просто. К тому же за рассылку спама сервер может быть заблокирован хостером или дата-центром.

Данный метод мониторинга основан на том, что обычно при массовой рассылке почты с сервера, существенно возрастает количество исходящих писем в почтовой очереди exim. Конечно он не совсем сгодится для серверов, на которых размещается множество клиентов виртуального хостинга, где желательно использовать более точные системы мониторинга, анализирующие содержание самих писем. Но для сервера с небольшим количеством сайтов, где их поведение, и рассылки с них заведомо известны, вполне подходит.

Для начала рекомендую посмотреть, сколько в данный момент сообщений в почтовой очереди exim. Сделать это можно командой:

exim -bpc

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

Пишем скрипт мониторинга почтовой очереди exim

В этом примере администратор получит уведомление на почту, если число писем в почтовой очереди больше 100. Если у вас обычно там больше писем, увеличьте это значение. К тому же к письму будет прикреплён файл с выводом последних 50 строк команды, отображающей почтовую очередь

#!/bin/bash

# Проверяем количество писем в очереди
queue_count=$(exim -bpc)

# Если писем больше 100, отправляем уведомление на почту
if [ $queue_count -gt 100 ]; then
    # Получаем список последних писем в очереди
    queue_list=$(exim -bp | tail -n 50)
    
    # Создаем временный файл для сохранения списка писем
    temp_file=$(mktemp)
    echo "$queue_list" > $temp_file
    
    # Отправляем письмо администратору с вложенным файлом
    echo "Количество писем в очереди превышает 100. Проверьте состояние очереди." | mail -s "Важное уведомление: очередь exim" -a $temp_file admin@site.com
    
    # Удаляем временный файл
    rm $temp_file
fi

Сохраняем этот скрипт в файл, например с именем exim-check.sh в папке /opt/, меняем в нём почту администратора, и даём ему права на выполнение:

chmod +x /opt/exim-check.sh

Проверяем работоспособность скрипта

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

/opt/exim-check.sh

Если не получили письмо с уведомлением, возможно на сервере не установлен mailx. Тогда его нужно установить.

Добавляем скрипт в планировщик

Если уведомление успешно получено, добавляем этот скрипт в планировщик cron, например с временем выполнения каждые 15 минут:

*/15 * * * * /opt/exim-check.sh

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

Я, например, люблю текстовый редактор mcedit, который устанавливается вместе с файловым менеджером Midnight Commander (mc).

Когда работаешь в консоли, легко можно вызвать нужный редактор, просто написав его имя перед файлом, который мы хотим отредактировать. Например, если написать в консоли команду

mcedit file

то откроется редактор mcedit, в котором будет содержимое файла file, доступное для редактирования.

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

crontab -e

Откроется файл, редактирования списка заданий планировщика. Но откроется он в редакторе, установленном в системе по умолчанию. Обычно это vim. А я хочу, чтобы он открывался в mcedit

Как изменить текстовый редактор по умолчанию в Debian/Ubuntu.

Посмотреть, какой редактор установлен по умолчанию, можно командой:

ls -l /etc/alternatives/editor

А для изменения редактора по умолчанию в Debian/Ubuntu нужно выполнить команду:

sudo update-alternatives --config editor

Появится список всех редакторов, установленных в системе, под определёнными номерами. Для изменения достаточно просто указать цифру нужного редактора. Выглядит это так:

В этом примере по умолчанию был установлен редактор 0, то есть nano.

Отправив цифру 3, я изменил его на mcedit.

Как изменить текстовый редактор по умолчанию в Centos.

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

echo $EDITOR

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

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

export EDITOR=mcedit

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

Ещё может быть другая ошибка: «Ошибка! Не настроен запуск cron_events. php на cron, последний агент отработал больше суток назад»

Как в Битрикс быстро и правильно перевести выполнение всех агентов на cron.

В админке Битрикса идём в раздел Настройки / Инструменты / Командная PHP-строка. Вводим и выполняем там команду для отключения выполнение всех агентов на хитах:

COption::SetOptionString("main", "agents_use_crontab", "N");
echo COption::GetOptionString("main", "agents_use_crontab", "N");

COption::SetOptionString("main", "check_agents", "N");
echo COption::GetOptionString("main", "check_agents", "Y");

В результате выполнения команды должно получиться “NN”. Выглядит это так:

Дальше нужно отредактировать файл /bitrix/php_interface/dbconn.php

Если там есть такие строки, одна или обе:

define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);

удаляем их. В этот же файл добавляем:

if(!(defined("CHK_EVENT") && CHK_EVENT===true))
   define("BX_CRONTAB_SUPPORT", true);

Должно получиться примерно вот так:

Следующий шаг: в этой же папке /bitrix/php_interface/ создаём новый файл с именем cron_events.php. В него вставляем такой код:

<?php
$_SERVER["DOCUMENT_ROOT"] = realpath(dirname(__FILE__)."/../..");
$DOCUMENT_ROOT = $_SERVER["DOCUMENT_ROOT"];

define("NO_KEEP_STATISTIC", true);
define("NOT_CHECK_PERMISSIONS",true);
define('BX_NO_ACCELERATOR_RESET', true);
define('CHK_EVENT', true);
define('BX_WITH_ON_AFTER_EPILOG', true);


require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");

@set_time_limit(0);
@ignore_user_abort(true);

CAgent::CheckAgents();
define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);
CEvent::CheckEvents();

if(CModule::IncludeModule('sender'))
{
    \Bitrix\Sender\MailingManager::checkPeriod(false);
    \Bitrix\Sender\MailingManager::checkSend();
}

require($_SERVER['DOCUMENT_ROOT']."/bitrix/modules/main/tools/backup.php");
?>

Ну и последнее, добавляем наш файл cron_events.php в планировщик cron с временем выполнения каждую минуту. Команда для планировщика cron должна выглядеть так:

/opt/php72/bin/php -f /var/www/user/data/www/site.ru/bitrix/php_interface/cron_events.php

Где:

• /opt/php72/bin/php – путь к бинарнику той версии php, на которой работает сайт. Если версия php на сервере одна, и она установлена из пакетов, можно написать просто php.
• /var/www/user/data/www/site.ru/bitrix/php_interface/cron_events.php – полный путь к созданному нами файлу cron_events.php от корня сервера.

Через пару минут идём в админку Битрикса в раздел Инструменты / Проверка системы, запускаем проверку, и видим, что «Замечание. Агенты выполняются на хитах, рекомендуется перевести выполнение агентов на cron» исчезло. Это значит, что всё хорошо, мы успешно перевели выполнение всех агентов на cron.

Проверить, как выполняются Агенты можно в админке Битрикс в разделе Настройки / Настройки продукта / Агенты.

Ищем там Агента с интервалом выполнения 60 секунд. Запоминаем время его последнего запуска. Через минуту обновляем страницу – время последнего запуска должно измениться.

Как перейти по ссылке при помощи Cron.

Обычно это делают при помощи Wget, сохраняя содержимое ссылки, как файл в /dev/null то есть сразу его удаляя. Команда выглядит так:

/usr/bin/wget -O /dev/null http://domain.com/cron.php

Это прекрасно работает, если в ссылке отсутствуют параметры в url.

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

http://domain.com/cron.php?param1=1&param2=2

то перейти он по ней уже не сможет из за символа &. Он не передаст всё, что после него. Тоже самое будет, если в ссылке будут некоторые другие специальные символы, например %.

Как перейти по ссылке с параметрами в url.

Всё просто, нужно экранировать специальные символы обратной косой чертой \, вставив её перед специальным символом. Таким образом команда Cron для перехода по ссылке при помощи Wget, с параметрами в url, будет выглядеть вот так:

/usr/bin/wget -O /dev/null http://domain.com/cron.php?param1=1\&param2=2