Linux. Запуск скрипта каждые N секунд
Дата 09.03.2018 Автор Alex Рубрика Программирование
Некоторые программы требуют периодического запуска. Например, каждый 5 минут. Для этого можно воспользоваться планировщиком CRON. Но прописывать cron правило будет слишком хлопотным занятием, если надо проводить запуск только в ближайший час-два. Для этого лучше воспользоваться командой watch.
К примеру, надо запускать программу каждые 5 минут в течении ближайшего часа, пока вы работаете. Для этой задачи будет хлопотно теребить файл crontab. Тем более в cron нельзя выставить периодичность менее минуты без ухищрений. Лучше открыть консоль и выполнить следующую команду:
watch -n 300 sh filename.sh
— из синтаксиса можно догадаться, что команда будет запускать исполняемый файл filename.sh. Число 300 с ключом -n означает, что запуск будет проходить каждые 300 секунд (5 минут). Если ключ -n с числом не указать, то запуск будет происходить каждые 2 секунды.
Привёл пример с запуском bash скрипта. Но можно исполнять и простые команды. К примеру:
Запуск скрипта sh в Linux
Вся сила Linux в использовании терминала. Это такая командная оболочка, где вы можете выполнять различные команды, которые будут быстро и эффективно выполнять различные действия. Ну впрочем, вы наверное это уже знаете. Для Linux было создано множество скриптов, которые выполняются в различных командных оболочках. Это очень удобно, вы просто объединяете несколько команд, которые выполняют определенное действие, а затем выполняете их одной командой или даже с помощью ярлыка.
Но у новичков может возникнуть вопрос — как запустить скрипт в Linux, что для этого нужно сделать, что будет происходить и какие команды нужно выполнить. Но сначала нужно рассмотреть как работают скрипты и что такое исполняемость.
Как работают скрипты
В Linux почти не используется расширение файла для опережения его типа на системном уровне. Это могут делать файловые менеджеры и то не всегда. Вместо этого, используются сигнатуры начала файла и специальные флаги. Система считает исполняемыми только те файлы, которым присвоен атрибут исполняемости.
Теперь о том, как работают скрипты. Это обычные файлы, которые содержат текст. Но если для них установлен атрибут исполняемости, то для их открытия используется специальная программа — интерпретатор, например, оболочка bash. А уже интерпретатор читает последовательно строку за строкой и выполняет все команды, которые содержатся в файле. У нас есть несколько способов выполнить запуск скрипта linux. Мы можем запустить его как любую другую программу через терминал или же запустить оболочку и сообщить ей какой файл нужно выполнять. В этом случае не нужно даже флага исполняемости.
Запуск скрипта sh в Linux
Сначала рассмотрим пример небольшого sh скрипта:
#!/bin/bash
echo «Hello world»
Вторая строка — это действие, которое выполняет скрипт, но нас больше всего интересует первая — это оболочка, с помощью которого его нужно выполнить. Это может быть не только /bin/bash, но и /bin/sh, и даже /usr/bin/python или /usr/bin/php. Также часто встречается ситуация, что путь к исполняемому файлу оболочки получают с помощью утилиты env: /usr/bin/env php и так далее. Чтобы выполнить скрипт в указанной оболочке, нужно установить для него флаг исполняемости:
chmod ugo+x script.sh
Мы разрешаем выполнять запуск sh linux всем категориям пользователей — владельцу, группе файла и остальным. Следующий важный момент — это то место где находится скрипт, если вы просто наберете script.sh, то поиск будет выполнен только глобально, в каталогах, которые записаны в переменную PATH и даже если вы находитесь сейчас в той папке где находится скрипт, то он не будет найден. К нему нужно указывать полный путь, например, для той же текущей папки. Запуск скрипта sh в linux:
Или полный путь от корня:
Если вы не хотите писать полный путь к скрипту, это можно сделать, достаточно переместить скрипт в одну из папок, которые указаны в переменной PATH. Одна из них, которая предназначена для ручной установки программ — /usr/local/bin.
cp script.sh /usr/local/bin/script.sh
Теперь вы можете выполнить:
Это был первый способ вызвать скрипт, но есть еще один — мы можем запустить оболочку и сразу же передать ей скрипт, который нужно выполнить. Вы могли редко видеть такой способ с bash, но он довольно часто используется для скриптов php или python. Запустим так наш скрипт:
А если нам нужно запустить скрипт на php, то выполните:
Вот так все просто здесь работает. Так можно запустить скрипт как фоновый процесс, используйте символ &:
Даже запустить процесс linux не так сложно.
Выводы
Как видите, запуск скрипта sh в linux — это довольно простая задача, даже если вы еще плохо знакомы с терминалом. Существует действительно много скриптов и некоторые из них вам возможно придется выполнять. Если у вас остались вопросы, спрашивайте в комментариях!
Автоматический перезапуск сервиса Linux
Иногда сервисы ни с того ни с сего падают и приходиться их вручную восстанавливать. Если для пользователя домашнего компьютера это не критично, потому что если сервис падает во время разработки, то это даже хорошо, можно сразу увидеть что есть проблема. Но на серверах и VPS сервисы должны работать постоянно для обеспечения доступа к веб-сайту или приложению.
В этой инструкции я покажу как настроить автоматический перезапуск сервиса Linux несколькими способами: с помощью скрипта мониторинга периодически запускаемого через cron и в systemd.
Автоматический перезапуск сервиса в systemd
По умолчанию, если ваш сервис будет убит или завершится некорректно, systemd не будет с ним ничего делать. Но можно настроить сервис так, чтобы при падении или даже остановке он автоматически перезапускался. Для этого используется директива Restart, которую надо добавить в секцию Service. Например, рассмотрим настройку автоматического перезапуска сервиса Apache:
sudo systemctl edit apache2
[Service]Restart=on-failure
RestartSec=5s
Директива RestartSec указывает сколько ждать перед перезапуском сервиса. Когда завершите сохраните изменения и выполните команду daemon-reload, чтобы перечитать конфигурацию:
sudo systemctl daemon-reload
Затем чтобы проверить что всё работает посмотрите состояние процесса, завершите процесс сигналом kill:
sudo systemctl status apache2
kill -KILL 32091
И снова посмотрите состояние. Процесс будет запущен. Система инициализации автоматически перезапустит его как только он завершится с кодом возврата ошибки. Если вы хотите чтобы процесс перезапускался всегда, необходимо использовать директиву Restart: always. Однако с ней надо быть осторожным, она вовсе не даст вам завершить процесс, даже если будет необходимо. Для того, чтобы процесс, который постоянно падает не перезапускался, можно добавить лимит на количество перезапусков в секцию Service:
sudo systemctl edit apache2
[Service]StartLimitIntervalSec=500
StartLimitBurst=5
Restart=on-failure
RestartSec=5s
Директивы StartLimitBurst и StartLimitIntervalSec указывают, что надо попытаться перезапустить сервис пять раз, и если он все эти пять раз упадёт, то больше его не трогать. Вторая директива ограничивает время перезапусков сервиса до 500 секунд.
Автоматический перезапуск сервиса с помощью скрипта
Это самый простой и самый надежный способ работающий абсолютно во всех дистрибутивах linux и не требующий установки дополнительных утилит. Для того же Apache скрипт выглядит следующим образом:
sudo vi /usr/local/bin/apache-monitor.sh
#!/bin/bash
ps -A | grep apache2 || systemctl start apache2
Сохраните файл, сделайте его исполняемым:
chmod ugo+x /usr/local/bin/apache-monitor.sh
Теперь добавьте запись в cron для периодического запуска скрипта:
На этом все, автоматический перезапуск сервисов штука может и немного сложная, но необходимая в серьезных системах.
запуск скрипта через промежуток времени
Была такая тема (https://www.linux.org.ru/forum/general/168656, сейчас она в архиве). И там предложили использовать крон, что логично, но. А если мне надо запустить скрипт через 5 минут после старта системы? Можно конечно в крон добавить
Или я что-то не недопонимаю?
PS 5 минут взято для примера, может 1 час, 2 часа любое время.
А если мне надо запустить скрипт через 5 минут после старта системы?
PS 5 минут взято для примера, может 1 час, 2 часа любое время.
Bwa-ha-ha, systemd haters, we won this battle!!
в rc.local вызывать скрипт с &, а в скрипте sleep 🙂
если оно еще актуально или вообще релевантно.
а вообще как-то корявато условие.
надо более лучше более планировать.
systemd unit в котором будет at. 🙂
Итого имеем в случае чего целых 3 точки отказа, вот помню мне основная идея systemd нравилась — унификация —, но глядя на подобные конструкции немного тошно, может оно и продуманно и правильно всё делать именно так в сложных случаях, но. но
Вам там жить не страшно, имея в собственном теле целый вагон точек отказа?
Итого имеем в случае чего целых 3 точки отказа
Очевидно основная идея systemd в том чтоб все платили за саппорт красношапке 😉
Не надо недооценивать нынешнею медицину. Укольчики нужных веществ локализуют точки отказа на раз. У меня вот организм B12 перестал усваивать, но, благодаря укольчикам, я всё ещё жив.
где-нибудь при загрузке
Лучшей эпитафии sysvinit даже специально не придумаешь.
вместо одной строки в rc.local 2 неочевидных ini-файла. таки прекрасная работа, flawless victory
Смерти боюсь, как и любой другой «нормальный» человек.
3 файла, 3 чтения и интерпретации файлов, 3 точки отказа на уровне обработки файлов. Я кода обработки юнитов/сервисов не видел поэтому и предположил наихудшее, но это просто моё мнение, не более того, но и не менее.
Лучшей эпитафии sysvinit даже специально не придумаешь.
Наоборот, это замечательная эпитафия системд. Ибо нормальный инит предоставляет бесконечные возможности, а системд огораживает всё, что только можно.
нормальный инит предоставляет бесконечные возможности, а системд огораживает всё, что только можно
А если мне надо запустить скрипт через 5 минут после старта системы?
В какой-нибудь автоисполняемый файл. Ну там etc/profile,
/.Xinitrc или подобное
Я не уверен что здесь правильно воспользовался «here» синтаксисом, вот проще вариант и надежнее
Кстати, может умельцы подскажут как правильно оформлять herein для at-расписаний? Очень сложно нагуглить этот сраный at
Bwa-ha-ha, systemd haters, we won this battle!!
Решение ненужной задачи ненужным приложением. 🙂
Вместо того, чтобы проверить что-то и выполнить, тупо 5 минут ждать зачем-то. А, вдруг, мало ?
Кстати а как эти два файла между собой связаны? Через название файла до расширения? Вот насрать в руки тому кто допускает взаимодействие через неявные связи. Нафига вообще разброс мелких фрагментов инструкций на тыщи осколков? Потому что в редхате тупые? Нет, так считать — было бы ошибкой. Ответ, логичный и исчерпывающий, только один: так задумывалось затем чтобы пользователь не мог вручную контролировать все это барахло. Только затем чтобы отжать у пользователя контроль над системой в пользу автоматики
Какой смысл бояться пока она не пришла? Какой смысл бояться когда она уже пришла? Какой смысл бояться неизбежного? Всякое яйцо рано или поздно разбивается, и в этом нет трагедии; главное чтобы не о край сковороды.
Что касается «точек отказа» в теле, то человек пока не придумал ни одной саомообучающейся, регенерирующейся и самовоспроизводящейся системы. Критиковать Творца легко, пусть попробует намутит хоть что-то близко подобное, тогда и смеет для критики клюв разверзать.
И не забыть atd включить. А то хрен его знает, может systemd и его сожрал.
Ну кто-то же добавил в crontab семантику с @reboot за много лет до systemd, значит, не такая уж и ненужная штука.
Вместо того, чтобы проверить что-то и выполнить
Так systemd тоже умеет.
Кстати а как эти два файла между собой связаны? Через название файла до расширения?
Если очень хочется можно указать явно.
А если мне надо запустить скрипт через 5 минут после старта системы?
И зачем такое может понадобиться?
Уж не для того ли чтоб дождаться пока вся система окончательно загрузится?
Если ответ «да» — эта цель достигается другими средствами:
Правильное выставление зависимости юнитов (и правильный способ сообщения юнитов о том что ready=1 )
Ну кто-то же добавил в crontab семантику с @reboot за
много лет до systemd, значит, не такая уж и ненужная штука.
Заметь: не в init, увеличивая его монстрообразность.
Ибо нормальный инит предоставляет бесконечные возможности
Бесконечные возможность одного юнита — отнимают какие-то возможности у другого юнита, в той же самой системе.
Но я пытаюсь донести НЕ якобы суть о том что якобы «в одной системе все юниты должны быть равны» (это не так! Не равны!).
. а то что — если нет строгого регулирования возможностей каждого юнита (правила! Строгие рамки!) — то ты значит ты не можешь гарантировать что каждый из юнитов сможет получить все возможности какие хочется для этого юнита.
Определяя правила (рамки) — ты гарантируешь что в рамках этих правил — каждый юнит получает нужные ему возможности, не отнимая возможностей у других юнитов
Кстати а как эти два файла между собой связаны? Через название файла до расширения?
В данном случае — да, возможно явное указание.
Вот насрать в руки тому кто допускает взаимодействие через неявные связи.
Тебе столько не съесть. Подавляющее большинство софта позволяет не задавать явно умолчательные значения.
Нафига вообще разброс мелких фрагментов инструкций на тыщи осколков?
Понятия не имею. А кто этим занимается и какое это отношение имеет к сабжу?
так задумывалось затем чтобы пользователь не мог вручную контролировать все это барахло
Кхм, «это барахло» контролировать вручную на порядок легче скриптовой лапши, так что не знаю, кто там чего планировал.
Во-первых, key=value существовало задолго до винды, винда туда только секции добавила. Во-вторых, зная любовь разработчиков винды к заимствованию идей, я сильно сомневаюсь в том, что это дополнение придумали именно они. И last but not least, даже если это сугубо их изобретение, то с какого перепугу это обязательно что-то плохое? Кстати, сейчас в самой винде таким форматом уже почти никто не пользуется, тогда как для fdo это основной формат, так что сейчас это линукс-стайл формат 🙂
Не на команду, а на одну задачу системного администрирования. Теперь можно штатными средствами делать enable/disable таймеру (напомни мне, какими штатными средствами sysvinit можно сделать disable строчке в crontab?), юнит можно использовать в зависимостях других юнитов, код возврата команды будет доступен в systemctl status, команду можно будет выполнять через systemctl start, ей можно указывать квоты, дополнительные условия запуска и тому подобное. Да даже человекочитаемый description уже большой полюс — собъёт тебя завтра автобус и новый сисадмин по по дному выхлопу systemctl —list-units уже поймёт, что это и для чего это нужно, а не будет вынужден бегать по fs, читая тут и там раскиданные скрипты.