Перейти к содержанию

Поиск

Показаны результаты для тегов 'cron'.

  • Поиск по тегам

    Введите теги через запятую.
  • Поиск по автору

Тип контента


Категории

  • Статьи
    • Компьютеры
    • Гаджеты
    • Медиа
  • RTFM
    • *nix
    • Windows

Блоги

  • Delirium

Категории

  • Files

Форумы

  • Статьи
    • Компьютеры
    • Гаджеты
    • Медиа
  • Постинг
    • *nix
    • Windows

Категории

  • Игры

Поиск результатов в...

Поиск контента, содержащего...


Дата создания

  • Начало

    Конец


Дата обновления

  • Начало

    Конец


Фильтр по количеству...

Регистрация

  • Начало

    Конец


Группа


About Me


Steam ID

Найдено 1 результат

  1. Статья подойдёт и для Centos 8. Cron — классический демон, использующийся для периодического выполнения заданий в определённое время. Регулярные действия описываются инструкциями, помещенными в файлы crontab и в специальные каталоги. Системный демон crond предназначен для выполнения регулярно повторяющихся заданий. Обычно crond запускается как системный сервис в процессе начальной загрузки системы и остается активным пока система не выключена. Сразу после старта он просматривает каталоги /var/spool/cron и /etc/cron.d, а также файл /etc/crontab в поисках заданий, которые нужно выполнять. Затем crond просыпается каждую минуту, выполняет предписанные ему задания и снова засыпает до начала следующей минуты. Посмотреть версию своего cron можно с помощью команды: sudo rpm -q cronie Если он не установлен, вы можете использовать yum, чтобы установить его. sudo yum -y install cronie Задания cron выбраны службой crond. Для того, чтобы проверить, работает ли служба crond на вашем CentOS 7, вы можете использовать следующую команду: sudo systemctl status crond.service -l Для реализации данного способа требуется внести задачу скрипта skript.sh в каталоге /sh/skriptiki/ на исполнение в программу cron на сервере CentOS 7. Проверим, работает ли у нас вообще cron в фоновом режиме? ps -ef | grep cron Открываем файл заданий cron: nano /etc/crontab Добавляем строки по смыслу общего синтаксиса в файле. После того, как вы сделаете изменения перезапустите службу crond с помощью команды ниже: sudo systemctl restart crond.service Шаблоны задания. Файлы crontab, создаваемые для отдельных пользователей, находятся в каталоге /usr/spool/cron/crontabs/ или /var/spool/cron/tabs/. Редактировать их вручную не рекомендуется, для этого используют команду crontab -e. Файлы crontab, используемые для управления всей системой, располагаются в каталоге /etc/cron.d/. Кроме того, в каталогах /etc/cron.daily/, /etc/cron.weekly/ и /etc/cron.monthly/ размещаются автоматически запускаемые программы (ежедневно, еженедельно или ежемесячно). Каждый пользователь системы имеет свой файл заданный crontab, в котором описано, в какое время и какие программы запускать от имени этого пользователя. Для редактирования файла crontab используется специальная одноимённая программа crontab, позволяющая не прерывать процесс cron на время редактирования. Чтобы задать cron‘у задачу лучше всего воспользоваться командой crontab, если выполнить ее с опцией -l. Для отображения содержимого crontab-файла текущего пользователя используйте команду: crontab -l Будет выведен текущий список заданий. Если вы еще никаких заданий cron‘у не давали, вы увидите в ответ сообщение «no crontab for user«. Сформулировать cron‘у задачу довольно просто, но, прежде чем пытаться задать ему работу, установите в качестве значения переменной окружения EDITOR указание на любимый (или привычный) текстовый редактор. В противном случае будет вызван редактор vi, с которым я, например, не привык работать. Поэтому я обычно выполняю команду: export EDITOR=mcedit Необязательно использовать mcedit. Можно то что удобнее, например тот же nano После чего получаю возможность использовать для редактирования списка заданий привычный CoolEdit из пакета Midnight Commander. После задания значения переменной EDITOR можно выполнить команду для редактирования заданий пользователя: crontab -e Будет вызван указанный вами редактор, причем при первом запуске такой команды откроется пустое окно, в котором вы должны сформулировать задание cron‘у. Возникает вопрос: а что мешает нам просто запустить любимый редактор, открыть для редактирования нужный файл и внести в него необходимые команды? Этому существует две причины. Во-первых, файлы, которые хранят задания для cron‘а (crontab-файлы), принадлежат root-у и защищены от модификации простыми пользователями. Команда же crontab запускается от имени root‘а (для нее установлен так называемый setuid-бит) и имеет доступ к этим файлам. Конечно, если речь идет о вашем персональном компьютере, где вы имеете все права, вам законы не писаны, но лучше все же придерживаться принятых правил игры. Вторая причина состоит в том, что записи в crontab-файлах должны подчиняться определенным стандартам, быть формализованы, чтобы crond мог их правильно интерпретировать. Команда crontab после того, как вы сохранили вновь отредактированный файл, производит его синтаксический анализ, и, если вы сделали какую-то ошибку, предлагает вам вернуться к его редактированию. Конечно, crontab не может сформулировать за вас задание cron‘у, так что правила написания заданий вам необходимо знать. Давайте их рассмотрим. Каждая строка crontab-файла (кроме строк комментариев, которые обозначаются знаком # в первой позиции) либо устанавливает значение некоторой переменной, либо представляет отдельное задание (ниже приведен пример crontab-файла, можете просмотреть его, чтоб составить первое впечатление). Строка задания состоит из шести полей, разделяемых пробелами (по крайней мере одним). Первые пять полей отведены для указания времени выполнения задания. В следующей табличке представлены значения, которые можно придавать этим полям. Шаблон задания для cron выглядит примерно так: Минуты (0-59); Часы (0-24); День месяца (1-31); Месяц (1-12) — или три первых буквы английского названия месяца (регистр не имеет значения); День недели (0-7) — или три первых буквы английского названия дня недели (регистр не имеет значения, а числа 0 и 7 оба обозначают воскресенье); Команда. В каждом из этих полей вместо простого числового значения можно прописать: список возможных значений, разделенных запятыми (в списках можно использовать только числа, имена не допускаются); интервал значений (например, 1-3); или звездочку (*), обозначающую любое из допустимых значений для данного поля. Существует также возможность указать, что данное задание должно выполняться только в каждый n-ый час (минуту, день или месяц), для чего в нужном поле записывают примерно такую комбинацию: «*/n» (кавычки, конечно, нужно опустить, а вместо n поставить конкретное число). Эти варианты записи времени выполнения заданий можно комбинировать, но об этом лучше прочитайте на man-странице crontab. Обратите внимание на то, что для указания дня отведено 2 поля: третье и пятое. Если в обоих полях заданы значения, отличные от *, то задание будет выполняться в те дни, когда хотя бы одно из значений дня совпадает с текущим. Например, если в третьем поле стоит 1,15, а в пятом поле — 5 (или FRI), то задание будет выполняться по первым и пятнадцатым числам каждого месяца, а также каждую пятницу (конечно, если в поле месяцев будет стоять *). Следующее поле (шестое) содержит подлежащую выполнению командную строку оболочки shell. Считается, что поле команда продолжается до конца строки и может содержать пробелы и символы табуляции. Причем заключать эту командную строку в кавычки не требуется. Как и в обычной командной строке shell, можно указать в этом поле несколько команд, разделенных точкой с запятой (хотя, наверное, лучше написать командный файл и указать в crontab-файле его имя). Задание переменных окружения для cron рассмотрим на примере переменной MAILTO. Надо сказать, что по умолчанию после выполнения каждой строки crontab-файла cron отсылает рапорт о выполнении задания. Содержанием такого рапорта является вывод исполнявшихся команд. Если не задавать переменную MAILTO, то сообщение отправляется тому пользователю, который задал ему данную задачу. Если вы хотите, чтобы сообщения отправлялись не вам, а, скажем, пользователю с именем fred, то в crontab-файле надо записать строку вида: MAILTO="fred" Боюсь только, что fred не обрадуется, если его почтовый ящик будет заполняться сообщениями от cron. Если они не нужны и вам, то установите переменную MAILTO в нуль: MAILTO="" После чего cron не будет загружать вас лишними письмами. Несколько переменных окружения cron устанавливает автоматически при его запуске. После завершения редактирования вы, как обычно, сохраняете результаты и выходите из редакторской программы. Если вы сделали ошибки, то увидите такое сообщение: crontab -e Ответ: crontab: installing new crontab "/tmp/crontab.10348":0: bad day-of-week errors in crontab file, can't install. Do you want to retry the same edit? y Естественно, придется ответить y. Если же ошибок не было (или вы их исправили), вы увидите только одну строку: crontab -e Ответ: crontab: installing new crontab В отличие от других процессов-демонов, которые требуют перезапуска после редактирования их конфигурационных файлов, перезапускать процесс crond после того, как пользователь задал новое задание, не требуется. Дело в том, что просыпаясь ежеминутно, cron проверяет время модификации crontab-файлов и перечитывает те файлы заданий, которые изменялись в последнее время. Поэтому не более чем через минуту ваши задания будут «приняты к исполнению«. Пользоваться услугами crond могут все пользователи, зарегистрированные в системе. Правда, суперпользователь может закрыть эту возможность для некоторых пользователей, прописав их имена в специальный файл /etc/cron.deny, либо же разрешив использовать cron только ограниченному числу пользователей, имена которых перечислены в файле /etc/cron.allow. Подробнее об этом вы можете прочитать на man-странице crontab, а пока будем считать, что вам такое право предоставлено. Чтобы изменить crontab-файл другого пользователя (например, bitrix): crontab -u bitrix -e Команда для очистки всех заданий текущего пользователя: crontab -r Команда для просмотра краткой справки по установленным таймерам: systemctl list-timers Команда чтобы увидеть загруженные, но неактивные таймеры: systemctl list-timers --all Где хранятся crontab-файлы? Дело в том, что одного такого файла нет. В GNU/Linux имеется целый каталог /var/spool/cron, в котором хранятся crontab-файлы для всех пользователей, включая root-а. Каждый такой файл имеет имя, совпадающее с регистрационным именем пользователя, по которому процесс cron определяет, какой UID надо использовать при выполнении команд из этого файла. Владельцем всех этих файлов является пользователь root. Кроме личных crontab-файлов отдельных пользователей существует также общесистемные crontab-файлы. Один из них, /etc/crontab, находится в каталоге /etc, а остальные — в каталоге /etc/cron.d. Эти файлы не доступны через команду crontab, редактировать их может только суперпользователь. Структура записей в таких файлах тоже несколько отличается от описанной выше: в строках заданий используется дополнительное поле, расположенное перед полем команды. В этом дополнительном поле суперпользователь задает имя пользователя, чей идентификатор (UID) будет использоваться при запуске данного задания. При инсталляции дистрибутива CentOS 7 создается основной файл конфигурации cron, /etc/crontab, и выглядит примерно так — формат cronjob-выражения: SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly , где минута час день месяц день_недели /путь/к/исполняемому/файлу и звёздочками обозначены конкретные блоки времени. Внимание! Каждая запись в файле crontab должна оканчиваться символом перевода строки, в том числе и последняя. В противном случае cron игнорирует её и записывает предупреждение в системный журнал, а ваш скрипт даже не срабатывает! Команда run-parts в нем служит для запуска всех скриптов из каталога, указанного в виде параметра этой команды. По большей части эти скрипты выполняют функции по обслуживанию системы: удаляют ненужные временные файлы, присматривают за быстро растущими файлами протоколов в каталоге /var/log и, при необходимости, очищают их, и тому подобное. Обратите внимание на то, что все эти работы, кроме ежечасных, выполняются в 4 часа ночи. Разработчики дистрибутива, по-видимому, имели в виду в первую очередь круглосуточно работающие сервера и установили время выполнения заданий на тот период, когда активность системы минимальна. Ведь большинство этих скриптов интенсивно работают с диском, что может существенно затормозить работу пользователей. Однако такое решение скорее всего непригодно для персонального компьютера, который пока что принято выключать на ночь. Однако, оказывается, что разработчики дистрибутива предусмотрели возможность выключения компьютера на ночь и поручили выполнение некоторых необходимых работ еще и демону anacron. Невыполненные задания и утилита anacron. Если некоторое задание не было выполнено демоном crond в указанное время, например, компьютер был выключен, то процесс crond не выполняет такую команду позже, поскольку информация о невыполнении задания ему не поступает, а для некоторых системных заданий такое явление недопустимо. Эту проблему позволяет решить другой системный демон, имя которого anacron. В отличие от cron, он работает по следующему принципу: При запуске, а запускается он во время старта системы из инициализационных скриптов, он просматривает свой конфигурационный файл, обычно /etc/anacrontab, в котором для каждого задания указывается периодичность, в сутках, с которой должно повторяться выполнение этого задания. Далее anacron проверяет, выполнялось ли данное задание в течение последних n дней. Если нет, anacron запускает на выполнение команду, указанную в строке задания. При этом выполнение команды может осуществляться с некоторой задержкой, величина которой, в минутах, должна быть указана в строке задания. После выполнения задания anacron записывает дату выполнения в специальный файл, содержащий записи о времени последнего выполнения данного задания, чтобы знать, когда надо выполнять это задание снова. Эти файлы сохраняются в каталоге /var/spool/anacron. В файл записывается только дата, часы и минуты не запоминаются. После выполнения каждого задания anacron посылает сообщение о его выполнении системному демону протоколирования syslogd, а после выполнения всех заданий из конфигурационного файла заканчивает работу. Конфигурационный файл /etc/anacrontab может содержать строки трех типов: строки описания заданий, строки задания переменных окружения, строки комментариев. Строка описания заданий имеет следующий формат: период задержка идентификатор_задания команда Как уже говорилось, период задается в днях, а задержка — в минутах. Идентификатор задания может содержать любые символы, кроме пробелов и слэшей. Он используется для идентификации задания при формировании сообщений демону протоколирования и при запоминании времени выполнения задания. В качестве команды может использоваться любая команда оболочки. Строки задания переменных имеют стандартный формат: ИМЯ_ПЕРЕМЕННОЙ = ЗНАЧЕНИЕ В качестве строк комментария может выступать пустая строка, строка состоящая только из пробелов или строка, содержащая произвольную последовательность символов, начинающуюся символом ‘#‘, перед которым может стоять любое количество пробелов. Приведу в качестве примера файл /etc/anacrontab из стандартной установки дистрибутива CentOS 7: cat /etc/anacrontab Как видно, в CentOS 7 утилита anacron «подстраховывает» демон cron, запуская периодические задания cron‘а, если последний почему-либо их не запускал. Благодаря этому, в частности, скрипт logrotate регулярно, точнее, при каждом запуске компьютера, выполняется, несмотря на то, что демоном crond он не запускается из-за выключения компьютера на ночь. Среди регулярно запускаемых cron‘ом скриптов, в каталогах /etc/cron.daily, /etc/cron.weekly и /etc/cron.monthly, вы найдете скрипт 0anacron, который заботится о том, чтобы обновить записи о времени последнего выполнения тех заданий, которые поручены обеим демонам, чтобы исключить их повторное выполнение anacron‘ом. При желании можно, очевидно, сделать так, чтобы cron, в свою очередь, «подстраховывал» anacron, периодически запуская его, хотя проще просто поручить периодические задания cron‘у. Демон anacron запускается при старте системы и, выполнив предписанные ему задания, завершает работу. Наверное поэтому нет никаких утилит, специально предназначенных для ввода новых заданий демону anacron. Такие задания может давать только суперпользователь путем прямого редактирования файла /etc/anacrontab. По-видимому, основное назначение этого демона — выполнять какие-то работы по обслуживанию системы после периодов долгого простоя. Примеры cron-заданий. Ниже приведены несколько примеров cron-заданий: Чтобы выполнять команду каждую минуту, задание должно быть такое: * * * * * <исполняемая-команда> Похожее задание, только команда будет вызываться каждые пять минут: */5 * * * * <исполняемая-команда> Вызывать команду 4 раза в час (каждые 15 минут): */15 * * * * <исполняемая-команда> Чтобы выполнить команду каждый час в 30 минут, пишем: 30 * * * * <исполняемая-команда> То есть команда будет выполняться не каждые 30 минут, а тогда, когда значение минут будет равно 30 (например, 10:30, 11:30, 12:30 и так далее). Значения времени можно комбинировать, перечислив их через запятую. Следующий код будет выполнять команду три раза в час: в 0, 5 и 10 минут. 0,5,10 * * * * <исполняемая-команда> Выполнять команду каждый час будет следующее задание: 0 * * * * <исполняемая-команда> Выполнение команды каждые два часа: 0 */2 * * * <исполняемая-команда> Чтобы выполнять команду каждый день (в 00:00): 0 0 * * * <исполняемая-команда> Выполнение команды каждый день в 03:00: 0 3 * * * <исполняемая-команда> Выполнение команды каждое воскресенье (sunday): 0 0 * * SUN <исполняемая-команда> Другой вариант задания, которое будет выполнять команду каждое воскресенье (естественно, тоже в 00:00): 0 0 * * 0 <исполняемая-команда> Выполнение команды каждый день с понедельника по пятницу: 0 0 * * 1-5 <исполняемая-команда> Следующее задание будет выполнять команду каждый месяц, 1-го числа в 00:00: 0 0 1 * * <исполняемая-команда> Выполнять команду в 16:15 каждого первого числа месяца будет это задание: 15 16 1 * * <исполняемая-команда> Выполнение команды каждые три месяца: 0 0 1 */3 * <исполняемая-команда> Выполнение команды в строго определённое время и месяц: 5 0 * 4 * <исполняемая-команда> Задание будет вызывать команду в начале каждого полугодия (в 00:00 1-го дня): 0 0 1 */6 * <исполняемая-команда> Выполнение команды каждый год 1-го января в 00:00: 0 0 1 1 * <исполняемая-команда> Готовые cron-задания. @reboot запускать при начальной загрузке сервера; @yearly заменяет ‘0 0 1 1 *‘, то есть ‘ежегодно в 00:00 1 января‘; @annually тоже что и yearly>; @monthly заменяет ‘0 0 1 * *‘ то есть ‘ежемесячно в 00:00 1 числа‘; @weekly заменяет ‘0 0 * * 0‘ то есть ‘еженедельно в 00:00 воскресенье‘; @daily заменяет ‘0 0 * * *‘ то есть ‘ежедневно в 00:00‘; @midnight тоже что и daily; @hourly заменяет ‘0 * * * *‘ то есть ‘ежечасно в 00 минут‘. Например: чтобы выполнять команду каждый раз после перезапуска сервера, используйте это задание. @reboot <исполняемая-команда> Настройка cron для web-программистов. Добавляем в cron задачу, которая будет выполнятся каждую минуту. Набираем: crontab -e И добавляем (будет выполняться под тем пользователем под кем вы зашли в SSH): */1 * * * * /usr/bin/php -q /server/cron/cron.php > /dev/null 2>&1 Сохраняемся, Где: */1 * * * * — означает что скрипт будет запускаться каждую минуту; > /dev/null — означает отправку результатов, которые выдаст скрипт, в никуда; 2>&1 — избавляет администратора сервера от писем, если скрипт закончит работу с ошибками. Для отправки на почту воспользуемся postfix. Как сделать возможность получать письма с сервера описано в статье: «CentOS 7: Postfix 3 для отправки электронной почты с внутреннего системного «почтового ящика». Набираем: crontab -e И добавляем (будет выполняться под тем пользователем под кем вы зашли в SSH): Выполнение команды архивирования материалов сайта и выгрузка базы данных каждый день с понедельника по пятницу с последующей отправкой файла результатов работы скрипта по указанной почте: 0 0 * * 1-5 /usr/bin/bash /sh/directory.ru-backup-day.sh > /tmp/backup-day.txt && mail -s "Site directory.ru day rotate" admin@yandex.ru < /tmp/backup-day.txt Выполнение команды сканирования открытых портов указанного IP-адреса, например, по воскресениям с последующей отправкой файла результатов работы nmap по указанной почте: 0 0 * * SUN nmap -T4 -A -v 192.168.0.31 > /tmp/nmap.txt && mail -s "Nmap usage" admin@yandex.ru < /tmp/nmap.txt Выполнение команды оценки занятого дискового пространства каждый день с последующей отправкой просто результатов работы nmap по указанной почте: 0 0 * * * df -h | mail -s "Disk usage" admin@mail.ru Сохраняемся, Добавляем в cron задачу, которая будет выполнятся, сохранит результат выполнения скрипта в файл и отправит его на почту с темой, в нашем случае в теле письма, но можно и приложением. Иногда надо запускать по cron скрипт который лежит уже на сайте и использует окружение сайта. Установим менеджер загрузок wget: yum -y install wget Набираем: crontab -e И добавляем (будет выполняться под тем пользователем под кем вы зашли в SSH): */5 * * * * /usr/bin/wget --no-check-certificate -O /dev/null https://www.linuxshop.ru/cronit.sh Сохраняемся, Где: wget — как бы выкачивает скрипт (что нам и нужно web-сервер его исполняет); --no-check-certificate не проверять сертификат https; -O /dev/null — не сохранять выкаченный файл на жесткий диск. Настройка cron для системных администраторов. Фактически, cron — это сервис, как и большинство других сервисов CentOS 7, он запускается при старте системы и работает в фоновом режиме. Его основная задача выполнять нужные процессы в нужное время. Существует несколько конфигурационных файлов, из которых он берет из них информацию о том что и когда нужно выполнять. Сервис открывает файл /etc/crontab (тут могут быть тоже прописаны задачи) и они не будут отображаться по команде crontab –l. Так же существует anacron (anachronistic cron или асинхронный (анахроничный) cron) и его запуск и его задания тоже нужно учитывать, смотрите файл /etc/anacrontab и каталоги /etc/cron.daily/, /etc/cron.hourly/, /etc/cron.monthly/ и /etc/cron.weekly/. Часто, в современных дистрибутивах там прописан запуск утилиты run-parts, которая запускает нужные скрипты из следующих папок: /etc/cron.minutely — каждую минуту; /etc/cron.hourly — каждый час ещё cat /etc/cron.d/0hourly — тут настроен; /etc/cron.daily — каждый день; /etc/cron.weekly — каждую неделю; /etc/cron.monthly — каждый месяц. Список всех задач cron у всех пользователей. К сожалению для системного администратора нет такого инструмента, так как задачи в CentOS 7 могут храниться в нескольких местах: Клиентский crontab (# crontab -u user -l) /etc/crontab — можно посмотреть cat /etc/crontab; /etc/anacrontab — можно посмотреть cat /etc/anacrontab; /etc/cron.d/ — cron считывает файлы в каталоге /etc/cron.d/; /etc/cron.daily/ — запуск всех скриптов один раз в день; /etc/cron.hourly/ — запуск всех скриптов один раз в час; /etc/cron.monthly/ — запуск всех скриптов один раз в месяц; /etc/cron.weekly/ — запуск всех скриптов один раз в неделю. Иногда конкретные пользователи могут создавать задачи тоже, как описано в общих методах. Задания cron для конкретных пользователей расположены в /var/spool/cron/username. При создании задач для конкретных пользователей, вам не нужно указать имя пользователя в cron. Для того чтобы пройти руками все клиентские crontab (# crontab -u user -l), можно автоматизировать для всех пользователей очевидно нужно взять список пользователей в системе из /etc/passwd и сделать для каждого пользователя: crontab -u USERNAME -l , то есть: for user in $(cut -d':' -f1 /etc/passwd); do crontab -u $user -l; done Недостаток этого решения очевиден: Нужно всегда помнить эту команду. Если у пользователя нет задач в планировщике то мы получим сообщение «no crontab for vasua» и таких сообщений может быть десятки если у вас много пользователей — это неудобно. Вывод информации неудобно читать. Решение простое — создадим функцию allcrontab в файле ~/.bashrc для ввода информации в более удобном виде: # Определим цвета вывода red='\e[0;31m' RED='\e[1;31m' green='\e[0;32m' GREEN='\e[1;32m' NC='\e[0m' # Определим нашу функцию вывода списка всех задач cron у всех пользователей function allcrontab() { for user in $(cut -d':' -f1 /etc/passwd); do usercrontab=$(crontab -l -u ${user} 2>/dev/null) if [ -n "${usercrontab}" ]; then echo -e "${RED}====== Start crontab for user ${NC}${GREEN}${user}${NC} ${RED}======${NC}" crontab -l -u ${user} | sed '/ *#/d; /^ *$/d' echo -e "${RED}====== End crontab for user ${NC}${GREEN}${user}${NC} ${RED}========${NC}\n" fi done } Выполняем source ~/.bashrc или перелогиниваемся и выполняем в консоли allcrontab и видим красивый вывод списка всех задач cron у всех пользователей. Но это не финишная прямая, а только начало, ведь опытный системный администратор знает, что кроме вывода списка заданий командой # crontab -u user -l есть еще задания планировщика в каталоге /etc/cron.d/ и это тоже нужно учитывать, потому что например панель хостинга ISPConfig сохраняет задания cron в каталоге /etc/cron.d/ с именами ispc_webXXX, где webXXX — это логин системного пользователя, например web30 и вывод # crontab -u web30 -l нам скажет «no crontab for web30», а на самом деле в файле /etc/cron.d/ispc_web30 может быть такая картина: SHELL='/bin/sh' */2 * * * * web30 /usr/bin/php -f /var/www/mysite.ru/web/yii cron-origin/index Чтобы вывести список всех заданий cron от всех пользователей вашей системы создайте скрипт: #!/bin/bash for user in $(cut -f1 -d: /etc/passwd) do echo $user crontab -u $user -l done Альтернативой вашей проблеме может быть размещение их в папке cron.d и указание соответствующего пользователя для каждого cron, как в примере: 0 1 * * * user /home/user/user-script.sh Отладка работы cron. После того как вы настроили правила, еще хотелось бы проверить работают ли они. Для этого ждем того времени, когда скрипт уже должен быть выполнен и смотрим log cron. Обычно он находится в /var/log/cron. Если нужно проверить скрипт, который находится в одной из специализированных папок, то тут еще проще, просто запустите run-paths, передав ей в параметр нужную папку или даже сам скрипт: sudo run-paths /etc/cron.daily/ Примерно вот так: SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # For details see man 4 crontabs # Example of job definition: # .---------------- minute (0 - 59) # | .------------- hour (0 - 23) # | | .---------- day of month (1 - 31) # | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | | # * * * * * user-name command to be executed 37 * * * * root run-parts /etc/cron.hourly 23 5 * * * root run-parts /etc/cron.daily 19 3 * * 0 root run-parts /etc/cron.weekly 23 0 6 * * root run-parts /etc/cron.monthly Файлы справки и помощи по cron. Для получения дополнительной информации вы можете проверить страницу man: man cron , а также: man crontab Cron калькуляторы. Если трудно установить правильную задачу в начале, вы можете использовать cron калькулятор, чтобы сгенерировать выражение требуемой задачи. Можно найти несколько хороших калькуляторов cron в Интернете. freeformatter.com — сайт с анкетой запуска заданий, заполняете анкету и получаете строку для cron. crontab.guru — сайт для генерации случайного времени исполнения задания, нажали кнопочку — получили рандомную строку для cron. sysmasters.net — обратный калькулятор, вводим в поле строку из cron и получаем расшифровку, что и когда будет исполняться. Как можно получить «копию» crontab? Внимание! На самом деле не рекомендуется обработать те файлы вручную! На crontab странице справочника есть упоминание, что: Файлы под /var/spool считаются временными/рабочими, вот почему они, вероятно, будут удалены во время обновления, хотя если более внимательно рассмотреть cron сценарии обновления пакета, то можно понять некоторые интересные детали. Так или иначе это, всегда хорошо, создать резервную копию записей крона или сохранить их в файле в корневом каталоге. Я предполагаю, что вы используете crontab -e создать crontab файлы на лету. Если так, можно получить «копию» crontab файла путем выполнения crontab -l. Выводим информацию в файл для получения эффекта «резервного копирования»: crontab -l > my-crontab Затем можно отредактировать это мой-crontab файл, чтобы добавить или изменить записи и затем «установить» его путем предоставления его crontab: crontab my-crontab Это делает тот же эффект, как проверяющая команда crontab -e. Житейские примеры из практики. Вариант записи в crontab: # как обычно, с символа '#' начинаются комментарии # в качестве командного интерпретатора использовать /bin/sh SHELL=/bin/sh # результаты работы можно отправлять по этому адресу MAILTO=paul@example.org # добавить в PATH домашний каталог пользователя PATH=/bin:/usr/bin:/home/paul/bin #### Здесь начинаются задания # выполнять каждый день в 0 часов 5 минут, результат складывать в log/daily 5 0 * * * $HOME/bin/daily.job >> $HOME/log/daily 2>&1 # выполнять 1 числа каждого месяца в 14 часов 15 минут 15 14 1 * * $HOME/bin/monthly # каждый рабочий день в 22:00 0 22 * * 1-5 echo "Пора домой" | mail -s "Уже 22:00" john 23 */2 * * * echo "Выполняется в 0:23, 2:23, 4:23 и т. д." 5 4 * * sun echo "Выполняется в 4:05 в воскресенье" 0 0 1 1 * echo "С новым годом!" 15 10,13 * * 1,4 echo "Эта надпись выводится в понедельник и четверг в 10:15 и 13:15" 0-59 * * * * echo "Выполняется ежеминутно" 0-59/2 * * * * echo "Выполняется по чётным минутам" 1-59/2 * * * * echo "Выполняется по нечётным минутам" # каждые 5 минут */5 * * * * echo "Прошло пять минут" # каждое первое воскресенье каждого месяца. -eq 7 это код дня недели, т. е. 1 -> понедельник , 2 -> вторник и т. д. 0 1 1-7 * * [ "$(date '+\%u')" -eq 7 ] && echo "Эта надпись выводится каждое первое воскресенье каждого месяца в 1:00" # Cert Renewal 30 6 1 * * root /usr/local/bin/certbot-auto renew --post-hook "nginx -s reload" >> /var/log/le-renew.log # Site hamsterden.ru day rotate 10 4 * * * root /usr/bin/bash /sh/hamsterden.ru-backup-day.sh > /dev/null 2>&1 # Clean Trash Yandex.Disk 0 5 * * * root /usr/bin/bash /sh/mycleantrash.sh > /dev/null 2>&1 # для принудительного "сброса" содержимого временных буферов памяти на диск 0,30 * * * * date; sync; echo "запись данных на диск" # прочие примеры /5 * * * * /misc/git_ansible_update.sh > /misc/last_update.log 2>&1 11 * * * * /usr/bin/find /etc/ansible -name "*.retry" -type f -delete 2>&1 */5 * * * * cd ~/.ssh && eval `ssh-agent -s` && $(cat /home/username/.ssh/someway | ssh-add -) && git pull &> ~/last_udpate.log */5 * * * * cd ~/.ssh/config.d/ && git pull &> ~/last_udpate.log # запустить скрипт после перезагрузки сервера, через 600 секунд @reboot sleep 600; find ${HOME}/my_app/check_conn.sh Оригиналы источников информации. ru.wikipedia.org «cron». linuxshop.ru «Настройка cron». andreyex.ru «Автоматизация системных задач с использованием cron на CentOS 7». rus-linux.net «Домашнее задание для компьютера». askubuntu.ru «Где хранится пользовательский crontab?» Источник Открыть запись
×
×
  • Создать...