ubuntu cron запуск скрипта bash
Настройка Cron
Именно для этих задач в Linux используется системный сервис cron. Это планировщик, который позволяет выполнять нужные вам скрипты раз в час, раз в день, неделю или месяц, а также в любое заданное вами время или через любой интервал. Программа часто используется даже другими службами операционной системы. В этой статье мы рассмотрим как выполняется настройка Cron и разберем основные часто используемые примеры.
Как работает Cron?
В этих папках должны находиться скрипты, которые нужно выполнять с указанным интервалом. Скрипты должны иметь права на выполнение и их имя не должно содержать точки. Это очень сильно облегчает работу с планировщиком для новых пользователей. Также в файле crontab прописан запуск команды anacron, которая работает так же как и cron, только предназначена для задач, которые нужно выполнять раз в длительный период, например, раз в день, неделю, месяц, год.
Она позволяет выполнять их даже если компьютер работает не всегда и время от времени выключается. Дата выполнения задания последний раз записывается в файл /var/spool/anacron, а затем, при следующем запуске anacron проверяет был ли запущен нужный процесс в нужное время, и если нет, то запускает его. Сам же сервис cron больше рассчитан на выполнение задач в течение дня или с точно расписанным временем и датой.
Настройка Cron
Для настройки времени, даты и интервала когда нужно выполнять задание используется специальный синтаксис файла cron и специальная команда. Конечно, вы всегда можете отредактировать файл /etc/crontab, но этого делать не рекомендуется. Вместо этого, есть команда crontab:
Поэтому тут нужно быть аккуратным, и если вам нужно выполнять скрипты от рута, то и crontab нужно выполнить от рута, а не от пользователя. Это часто становиться причиной проблем.
Синтаксис crontab
Как я уже говорил, время задается особым синтаксисом, давайте рассмотрим синтаксис настройки одной задачи cron:
минута час день месяц день_недели /путь/к/исполняемому/файлу
Примеры настройки cron
Далее, усложним, будем запускать каждый час, в нулевую минуту:
Запускаем в нулевую минуту нулевого часа, каждый день, это в 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
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
Кроме того, для некоторых часто используемых наборов были придуманы переменные, вот они:
Например, вот так просто будет выглядеть команда запуска скрипта раз в час:
Если же вы собрались добавить скрипт в одну из папок, то, как я уже говорил, нужно чтобы его имя было без точек и у него были права на выполнение:
sudo vi /etc/corn.daily/basckup
Скрипт должен выглядеть подобным образом. Теперь вы знаете как настроить cron, осталось проверить как все работает.
Отладка работы
После того как вы настроили правила, еще хотелось бы проверить работают ли они. Для этого ждем того времени, когда скрипт уже должен быть выполнен и смотрим лог cron. Иногда он находится в /var/log/cron, а иногда пишется в syslog. Например, у меня в crontab есть такая строка:
Она должна выполняться в 19.40 каждый день, теперь смотрим лог:
grep CRON /var/log/syslog
И видим что в нашем логе она действительно есть и выполняется целиком успешно. Если бы были какие-либо ошибки, то тут же было бы выведено сообщение.
Если нужно проверить скрипт, который находится в одной из специализированных папок, то тут еще проще, просто запустите run-paths, передав ей в параметр нужную папку или даже сам скрипт:
sudo run-paths /etc/cron.daily/
Дальше вы увидите весь вывод, включая вывод скрипта и сможете быстро понять в чем проблема.
Выводы
В этой статье мы рассмотрели как выполняется настройка cron для удобного планирования автоматических задач. Надеюсь, эта информация была полезной для вас.
запуск скрипта sh через crontab
Добрый день, понимаю конечно, что вопрос может и дебильный, но никак не могу решить задачу по запуску скрипта через крон.
И так задача: нужно запускать каждое воскресенье в 0.00 скрипт restart_squid.sh в crontab из под root добавил следующие:
на скрипт сделал chmod +x вручную скрипт запускается, но через крон не работает.
решил проверить работает ли вообще крон сделал следующие
Подскажите пожалуйста, в чем моя ошибка?
по идеи каждую минуту, должно ведь каждую минуту выводиться сообщение IT WORKS
Куда оно должно выводиться? Ну и не каждую минуту, а в первую минуту каждого часа.
я думал что должно выводиться на экран консоли или я ошибаюсь?
Что бы оно выводилось на экран консоли нужно вызывать команду в консоли или сделать перенаправление вывода в нужную консоль:
каждую минуту будет так */1, на счет выводится тоже ошибаешся сделай например для теста запись вывода в какой нибуть файл. И еще к исполняемым файла путь нужно указывать полный, смотреть с помощью which echo например. чтоб тебе легче біло можешь воспользоватся http://www.crontab-generator.org/
ну чтоб в какой либо работающий шел віводилось нужно смотреть с помощью w или who
И еще к исполняемым файла путь нужно указывать полный,
Необязательно, но лучше указать.
та да, я делаю так */1 чтоб себя не путать, как бы наглядно видно. Но тоже правильно. 🙂
ну чтоб в какой либо работающий шел віводилось нужно смотреть с помощью w или who
Чтобы в какой-либо «шел» выводилось нужно просто перенаправить вывод на соответствующий /dev/ttyN.
не обязательно это /dev/ttyN
Необязательно, но если говорить о консоли, то верно.
В данном случае «необязательно» является наречием.
не понял насчет «первой консоли» это как? сейчас вбил эту строчку получилось вот так
эффекта ноль, tty1 это рутовая консоль? а если консоль пользователя это будет tty2?
мне похер, я не русский, и русский не учил.
да нет необходимости, кому нужно и так поймет 🙂
В какой файл пишете правило для cron`а, в /etc/crontab или персональный файл пользователя?
в персональный, а лучше писать в /etc/crontab?
Читать текст написанный неграмотно неприятно, к тому же сразу складывается не особо лестное мнение о человеке, который хотя бы не старается писать более правильно.
Даже помогать такому человеку на форуме, если он при оформлении шапки темы совершает много грамматических ошибок, не ставит знаки препинания, путает банальное «ться» и «тся», неправильно склоняет и ещё кичится этим, не хочется.
так и писал, но ничего не происходит, даже не выводится it works в консоль
в персональный, а лучше писать в /etc/crontab?
Попробуйте, только там после интервалов запуска нужно указать имя пользователя. Ну и попробуйте указать полный путь даже просто до echo.
У тебя сам демон крона хоть запущен? Какой дистрибутив?
извините меня конечно, я скорей всего туплю, но я не понимаю о какой консоли идет через, я к машине через putty подключаюсь, потом логинюсь через аккаунт manage, далее пишут su и уже правлю кронтаб
Как создать задание cron с помощью Bash автоматически без интерактивного редактора?
имеет ли crontab аргумент для создания заданий cron без использования редактора (crontab-e). Если да, то какой код создаст cronjob из сценария Bash?
16 ответов
вы можете добавить в crontab следующим образом:
Cron line explaination
вы можете сделать это на лету
этот короткий не требует временного файла, он невосприимчив к нескольким вставкам и позволяет изменять расписание существующей записи.
скажите, что у вас есть это:
чтобы добавить его в crontab, без дублирования:
чтобы удалить его из crontab независимо от его текущего расписания:
спасибо всем за помощь. Собрав воедино все, что я нашел здесь и в других местах, я пришел к следующему выводу:—22—>
я не мог понять, как устранить необходимость в двух переменных, не повторяясь.
подробности
в двух словах:
эта строка кода отфильтровывает все задания cron, соответствующие команде, а затем записывает оставшиеся задания cron с новым, эффективно действует как функция» добавить «или» обновить». Чтобы использовать это, все, что вам нужно сделать, это поменять значения command и job переменные.
EDIT (исправлена перезапись):
чтобы дать исчерпывающий ответ, давайте посмотрим на различия между crontab vs cron/crond :
для тех, кто хочет запустить задание в контексте своего пользователя в системе, используя crontab может иметь смысл.
быстрый отрывок из manpages дает вам несколько примеров того, что и не делать:
/etc /crontab и файлы в/etc / cron.d должен принадлежать root и не должен быть доступен для групповой или другой записи. В отличие от области катушки, файлы под /etc/cron.d или файлы в разделе /etc / cron.ежечасно, / etc / cron.ежедневно, /и т. д./cron.еженедельно и / etc / cron.месячные также могут быть ссылки, при условии, что оба ссылке и файл, на который он указывает, принадлежит root. Файлы в разделе /etc / cron.d не обязательно быть исполняемым, в то время как файлы под /etc/cron.ежечасно, / etc / cron.ежедневно, /и т. д./cron.еженедельно и / etc / cron.ежемесячно, так как они выполняются частями выполнения (см. run-parts(8) для получения дополнительной информации).
управление кронами таким образом проще и масштабируемо от системная перспектива, но не всегда будет лучшим решением.
Cron в Ubuntu. + bash-cкрипт резервного копирования
Для начала создадим какой-нибудь простой bash-скрипт, например скрип резервного копирования и архивирования конфигурационных файлов, в моём случае конфигурационных файлов Apache2 и ftp-сервера.
mkdir / home / user / bash-scripts / backup
cp / etc / apache2 / apache2.conf / home / user / bash-scripts / backup / apache2.conf-backup
cp / etc / apache2 / sites-available / site / home / user / bash-scripts / backup / site-backup
cp / etc / proftpd / proftpd.conf / home / user / bash-scripts / backup / proftpd.conf-backup
tar cvvzf «/home/user/bash-scripts/backup-`date +%F-%X`.tar.gz» / home / user / bash-scripts / backup /
Этот скрипт копирует конфигурационные файлы и архивирует их в папку, в названии которой присутствует дата и время сохранения. Назовём его ‘ backup-script ‘ а лежать он у нас будет в домашнем каталоге (/home/user/). Теперь нам надо чтобы этот скрипт запускался, ну допустим, каждые 10 минут. Для этого введём команду
Этой командой мы открываем для редактирования файл crontab для данного пользователя, в моём случае это user. Если нашему скрипту нужны права супер пользователя, то нужно редактировать crontab суперпользователя. Делается это командой
Сразу напишу, чтобы посмотреть файл crontab введите команду.
Файл crontab имеет следующую структуру:
поле1 поле2 поле3 поле4 поле5 команда
Значения первых пяти полей:
1.минуты— число от 0 до 59
2.часы — число от 0 до 23
3.день месяца — число от 1 до 31
4.номер месяца в году — число от 1 до 12
5.день недели — число от 0 до 7 (0-Вс,1-Пн,2-Вт,3-Ср,4-Чт,5-Пт,6-Сб,7-Вс)
Все поля обязательны для заполнения. Не сложно догадаться что первые 5 отвечают за определения периодичности запуска команды, а последняя собственно команда или полный путь к скрипту. Таким образом, чтобы запустить наш скрипт резервного копирования раз в 10 минут надо вписать следующую строчку.
*/ 10 * * * * / home / user / backup-script
Ну вот и всё, в заключение пару примеров:
0 */ 3 * * 2,5 / home / user / backup-script
#Каждые три часа только по вторникам и пятницам
15 */ 3 * * * / home / user / backup-script
#Каждые три часа в 15 минут
45 15 * * 1 / home / user / backup-script
#По понедельникам в 15:45
13 13 13 * 5 / home / user / backup-script
#в пяnницу 13 числа в 13 часов 13 минут
30 00 * * 0 / home / user / backup-script
#Раз в неделя по воскресеньем в 00:30
Запуск Bash в деталях
Если вы нашли эту страницу в поиске, то наверняка пытаетесь решить какую-то проблему с запуском bash.
Возможно, в вашем окружении bash не устанавливается переменная среды и вы не понимаете, почему. Возможно, вы засунули что-то в различные загрузочные файлы bash или в профили, или во все файлы наугад, пока это не сработало.
В любом случае, смысл этой заметки — как можно проще изложить процедуру запуска bash, чтобы вы могли справиться с проблемами.
Диаграмма
Эта блок-схема обобщает все процессы при запуске bash.
Теперь подробнее рассмотрим каждую часть.
Login Shell?
Сперва нужно выбрать, находитесь вы в командной оболочке входа (login shell) или нет.
Оболочка входа настраивает базовую среду при первом запуске оболочки bash.
Интерактивный?
Затем вы определяете, является оболочка интерактивной или нет.
Это можно проверить по наличию переменной PS1 (она устанавливает функцию ввода команд):
В оболочке входа?
Если вы находитесь в оболочке входа, то bash ищет файл /etc/profile и запускает, если он существует.
Затем ищет любой из этих трёх файлов в следующем порядке:
Когда находит один, то запускает его и пропускает другие.
В интерактивной оболочке?
Если вы находитесь в интерактивной оболочке без входа в систему (non-login shell), предполагается, что вы уже побывали в оболочке входа, окружение настроено и будет унаследовано.
В этом случае выполняются по порядку следующие два файла, если они существуют:
Ни один вариант?
Если вы не находитесь ни в оболочке входа, ни в интерактивной оболочке, то ваше окружение действительно будет пустым. Это вызывает большую путаницу (см. ниже о заданиях cron).
В этом случае bash смотрит на переменную BASH_ENV вашей среды и выполняет соответствующий файл, который там указан.
Типичные трудности и эмпирические правила
Задания cron
У меня в 95% случаев отладка запуска bash связана с тем, что задание cron работает не так, как ожидалось.
Эта проклятая задача работает нормально, когда я запускаю её в командной строке, но фейлится при запуске в crontab.
Вот почему зачастую приходится установить конкретный PATH для задачи cron, как здесь:
Скрипты, вызывающие друг друга
Обычно так происходит, когда кто-то пытался исправить какую-то ошибку и вроде бы всё заработало. К сожалению, когда нужно разделить эти разные типы сессий, то возникают новые проблемы.
Образ Docker в песочнице
Чтобы поэкспериментировать с запуском оболочки, я создал образ Docker, который можно использовать для отладки запуска оболочки в безопасной среде.
Для принудительного логина и имитации оболочки входа:
Для проверки набора переменных BASH_ENV :
Для отладки crontab каждую минуту выполнятся простой скрипт (в /root/ascript ):