Запуск bash скрипта в фоновом режиме через Systemd
Понадобилось на днях написать простой bash-скрипт, для постоянного мониторинга каталога на наличие в нем файлов *.pdf, с последующей их конвертацией в формат txt. Скрипт должен был работать в фоновом режиме и автоматически запускаться при перезагрузке.
Для начала нужно убедиться, что ваш дистрибутив работает с Systemd, командой:
/run/systemd/system/ — юниты, созданные в рантайме. Этот каталог приоритетнее каталога с установленными юнитами из пакетов.
/etc/systemd/system/ — юниты, созданные и управляемые системным администратором. Этот каталог приоритетнее каталога юнитов, созданных в рантайме. В этом каталоге мы и будем создавать свой юнит.
Переходим в каталог /etc/systemd/system/ и создаем в нем, либо копируем какой-либо существующий файл, к примеру sshd.service, и в нем пишем:
Подробнее о каждой секции:
Секция [Unit]:
Содержит общую информацию о сервисе, его описание, и то, что он должен стартовать после запущенного демона Syslog.
Секция [Service]
Непосредственная информация о нашем сервисе.
Параметр ExecStart указывает на исполняемый файл нашего сервиса. Нужно указывать абсолютные пути, в случае с bash-скриптом путь до скрипта берем в одинарные кавычки.
Type=forking означает, что запускаемый скрипт будет работать в режиме демона. Если мы хотим, чтобы скрипт выполнился один раз, то указываем Type=simple.
Это работающий файл сервиcа Systemd, с небольшим функционалом. Сохраняем файл, и выполняем команду systemctl daemon-reload, чтобы Systemd узнал о нашем сервисе, и вы могли его запустить командой systemctl start bash.service.
У меня запустить получилось не с первого раза, так как сначала я указал не абсолютный путь в параметре ExecStart секции [Service]. После исправления Systemd все равно ругался на ту же ошибку, помогла перезагрузка.
Для просмотра состояния, старта, остановки, перезагрузки, включения или выключения системных сервисов используется команда systemctl. В более ранних версиях Systemd использовались команды service и chkconfig, они по прежнему включены в систему, в основном для обратной совместимости.
Ниже представлены основные команды systemctl:
Для более подробного знакомства с Systemd рекомендую почитать:
Как создать собственный скрипт для автоматического запуска во время загрузки в systemd
В старых версиях Linux для запуска своего скрипта при загрузке системы мы использовали /etc/rc.d/init.d Практически все основные дистрибутивы Linux отказались от init и перешли на systemd и предыдущий метод теперь не рекомендуется.
Создание собственного скрипта
1.Создадим образец пользовательского сценария, который будет автоматически запускаться при загрузке системы.
2. Добавим права на запуск
Создание нового сервиса systemd.
Создайте новый файл сервисного модуля в /etc/systemd/system/test.service с содержанием ниже. Название сервиса определяется пользователем и может иметь любое имя по вашему выбору.
After = : если сценарию требуются другие системные средства. Измените раздел [Unit], включив в него соответствующие директивы After =, Wants = или Require =.
Type = : переключатель Type = simple для Type = idle в разделе [Service], чтобы отложить выполнение сценария до тех пор, пока не будут выполнены все другие задания.
WantedBy = : цель для запуска сценария примера
Как включить системный сервисный модуль
1. Необходимо перезагрузить процесс systemd, чтобы учесть вновь созданный test.service. Тоже самое нужно делать каждый раз, когда test.service изменяется.
2. Включите эту службу, чтобы запускаться автоматически после перезагрузки.
3. Запустите сервис.
4. Перезагрузите компьютер, чтобы убедиться, что сценарии запускаются должным образом во время загрузки системы.
Посмотреть список установленных системных модулей можно просто набрав в терминале команду systemctl
Systemd за пять минут
Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).
В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.
Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…
Но что делать, если стоит задача быстро-быстро, вот прямо вчера, сделать автозапуск некоего сервиса?
Давайте выжмем из документации минимально необходимый набор информации для создания простых старт-стоп скриптов.
Systemd запускает сервисы описанные в его конфигурации.
Конфигурация состоит из множества файлов, которые по-модному называют юнитами.
Все эти юниты разложены в трех каталогах:
/usr/lib/systemd/system/ – юниты из установленных пакетов RPM — всякие nginx, apache, mysql и прочее
/run/systemd/system/ — юниты, созданные в рантайме — тоже, наверное, нужная штука
/etc/systemd/system/ — юниты, созданные системным администратором — а вот сюда мы и положим свой юнит.
[Название секции в квадратных скобках]
имя_переменной = значение
Для создания простейшего юнита надо описать три секции: [Unit], [Service], [Install]
В секции Unit описываем, что это за юнит:
Названия переменных достаточно говорящие:
Далее следует блок переменных, которые влияют на порядок загрузки сервисов:
Запускать юнит после какого-либо сервиса или группы сервисов (например network.target):
After=syslog.target
After=network.target
After=nginx.service
After=mysql.service
В итоге переменная Wants получается чисто описательной.
Если сервис есть в Requires, но нет в After, то наш сервис будет запущен параллельно с требуемым сервисом, а не после успешной загрузки требуемого сервиса
В секции Service указываем какими командами и под каким пользователем надо запускать сервис:
(по умолчанию): systemd предполагает, что служба будет запущена незамедлительно. Процесс при этом не должен разветвляться. Не используйте этот тип, если другие службы зависят от очередности при запуске данной службы.
systemd предполагает, что служба запускается однократно и процесс разветвляется с завершением родительского процесса. Данный тип используется для запуска классических демонов.
Также следует определить PIDFile=, чтобы systemd могла отслеживать основной процесс:
Команды на старт/стоп и релоад сервиса
Тут есть тонкость — systemd настаивает, чтобы команда указывала на конкретный исполняемый файл. Надо указывать полный путь.
Таймаут в секундах, сколько ждать system отработки старт/стоп команд.
Попросим systemd автоматически рестартовать наш сервис, если он вдруг перестанет работать.
Контроль ведется по наличию процесса из PID файла
В секции [Install] опишем, в каком уровне запуска должен стартовать сервис
multi-user.target или runlevel3.target соответствует нашему привычному runlevel=3 «Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть»
Вот и готов простейший стартап скрипт, он же unit для systemd:
myunit.service
Кладем этот файл в каталог /etc/systemd/system/
Смотрим его статус systemctl status myunit
Если нет никаких ошибок в юните — то вывод будет вот такой:
systemd ubuntu или автозагрузка скриптов и демонов
Добавить в автозагрузку:
Удалить из автозагрузки:
Проверить есть ли в автозагрузке сервис:
Какие сервисы добавлены в автозагрузку:
systemctl list-unit-files | grep enabled
Для начала нужно убедиться, что ваш дистрибутив работает с Systemd, командой:
Systemd осуществляет свою работу с помощью так называемых юнитов systemd.
/run/systemd/system/ — юниты, созданные в рантайме. Этот каталог приоритетнее каталога с установленными юнитами из пакетов.
/etc/systemd/system/ — юниты, созданные и управляемые системным администратором. Этот каталог приоритетнее каталога юнитов, созданных в рантайме. В этом каталоге мы и будем создавать свой юнит.
Description=My Script Iptables
chmod 644 /lib/systemd/system/iptables.service
systemctl enble iptables.service
Переходим в каталог /etc/systemd/system/ и создаем в нем, либо копируем какой-либо существующий файл, к примеру sshd.service, и в нем пишем:
ExecStart=/bin/bash ‘/home/user/scripts/script.sh’
Type=forking
Секция [Unit]:
Содержит общую информацию о сервисе, его описание, и то, что он должен стартовать после запущенного демона Syslog.
Секция [Service]:
Непосредственная информация о нашем сервисе.
Параметр ExecStart указывает на исполняемый файл нашего сервиса. Нужно указывать абсолютные пути, в случае с bash-скриптом путь до скрипта берем в одинарные кавычки.
Type=forking означает, что запускаемый скрипт будет работать в режиме демона. Если мы хотим, чтобы скрипт выполнился один раз, то указываем Type=simple.
Секция [Install]:
Последняя секция [Install] содержит информацию о цели, в которой сервис должен стартовать. В данном случае мы хотим, что сервис должен быть запущен, когда будет активирована цель multi–user.target (это аналог init 3 в SysV).
Сохраняем файл, и выполняем команду
Запускаем наш новый сервис:
В простом варианте юнит состоит из трех секции:
[Unit], [Service], [Install].
Далее указываем порядок загрузки, после какого сервиса systemd запустить наш юнит:
Задаем тип сервиса:
Используется по умолчанию. Служба будет запущена незамедлительно. Процесс при этом не должен разветвляться. Не Используйте этот тип, если другие службы зависят от очередности при запуске данной службы.
Указывают если служба запускается однократно и процесс разветвляется с завершением родительского процесса.
Рабочий каталог приложения:
Пользователь и группа, под которым будет запускаться сервис:
Задаем приоритет убийства процесса при нехватке памяти:
Команды запуска, остановки и перезапуска сервиса:
Таймаут запуска или остановки сервиса:
Контроль запуска сервиса и автоматический запуск в случае крєша:
Уровень запуска сервиса:
Ниже представлены основные команды systemctl:
Управление автозагрузкой сервисов и скриптов в Linux
В данной статье мы рассмотрим основы управлением автозагрузкой сервисов и скриптов в Linux CentOS 7/8. В частности, разберем основы работы с демоном systemd, научимся добавлять в автозагрузку сервисы и убирать их оттуда, а также рассмотрим альтернативные варианты запуска скриптов или демонов после старта системы.
Задача статьи – научить вас быстро разобраться со списками служб и скриптов которые запускаются в Linux автоматически, добавить в автозагрузку свои службы или скрипты, или отключить автозапуск определённых программ.
Systemd: управление автозагрузкой служб в Linux
В большистве популярных современных популярных дистрибутивов Linux (CentOS 7, RHEL, Debian, Fedora и Ubuntu) в качестве демона автозагрузки вместо init.d используется systemd. Systemd – менеджер системы и служб Linux, используется для запуска других демонов и управления ими в процессе работы, использует unit-файлы из /etc/systemd/system (init.d использовал скрипты из каталога /etc/init.d/). Systemd позволяет распараллелить запуск служб в процессе загрузки ОС, тем самым ускоряя запуск.
Для управления system используется команда systemctl.
Для начала, после загрузки системы, мы проверим список юнитов, которые в данный момент добавлены в systemd:
Список unit-файлов можно получить командой:
Данная команда отобразит все доступные юнит-файлы (не зависимо от того, были они загружены в systemd после загрузки ОС или нет).
Чтобы вывести список активных сервисов и их состояние, выполните:
Следующая команда выведет список юнитов, которые загрузил или пытался загрузить systemd. Так как после запуска некоторые юниты могут стать неактивными, с помощью флага —all вы получите полный список.
Как видим из списка, здесь отображаются даже сервисы, которые не были найдены на диске «not-found».
Использую данную команду, вы можете добавить и другие флаги, например:
systemctl list-units —type=service — выведет список юнитов, которые являются сервисом.
Добавление сервиса в systemd
Для управления сервисами в systemd используется особый синтаксис. После имени серверсв в конце нужно указывать .service. Например:
systemctl enable nginx.service – команда добавит в автозагрузку веб-сервер nginx
Данная команда создаст символическую ссылку на копию файла, указанного в команде сервиса, в директории автозапуска systemd.
# systemctl enable nginx.service
Чтобы посмотреть добавлен тот или иной сервис в автозагрузку, можно проверить его статус:
systemctl status nginx.service
При выводе нужно обратить внимание на строку:
Значение enabled означает что данный сервис загружается автоматически (добавлен в автозагрузку). Если сервис не загружается автоматом, здесь буде указано disabled.
Удаление сервиса из systemd
Вы можете удалить сервис из автозагрузки, чтобы он не запускался после старта Linux (при этом сам сервис с сервера не удаляется). Чтобы удалить сервис из автозагрузки, выполните команду:
systemctl disable нужный_сервис
Например, чтобы удалить из автозагрузки nginx, выполните:
# systemctl disable nginx.service
После выполнения команды, симлинк на файл сервиса будет удален из директории systemd. Можно проверить, есть ли юнит в автозагрузке:
# systemctl is-enabled sshd
Systemd: маскировка юнитов
В моей практике встречались «вредные» сервисы, которые после удаления их из автозагрузки, все равно там оставались и запускались после рестарта ОС. Чтобы решить этот вопрос, можно замаскировать сервис:
systemctl mask nginx.service
И после этого, он вообще не будет запускаться, ни вручную, ни после перезагрузки ОС:
# systemctl mask nginx.service
# service nginx restart
Снять маску можно командой:
# systemctl unmask nginx.service
Если после маскировки сервиса, вы проверите юнит-файлы, то увидите, что сервис помечен как замаскированный (состояние masked):
Таким нехитрым способом, можно избавить себя от удаления сервиса, даже если он не удаляется из автозагрузки systemd.
Автозапуска скриптов и сервисов с помощью rc.local
Для запуска различных скриптов при загрузке Linux чаще всего используется rc.local.
Но помимо скриптов, через rc.local так же можно и запускать сервисы, даже те, которые запускаются через systemd. Не могу ответить на вопрос, для чего использовать в таком случае rc.local, если есть systemd, но пару примеров я приведу.
Начнем с того, что файл /etc/rc.local должен быть исполняемым:
chmod +x /etc/rc.local
Rc.local должен быть добавлен в автозагрузку systemd:
systemctl enable rc-local
И на примере того же nginx, мы можем добавить в rc.local команду запуска веб-сервера:
service nginx start
Но я редко использую rc.local для запуска сервисов. Чаще rc.local используется, когда нужно запустить скрипт, либо выполнить разово какую-то команду.
К примеру, я создал скрипт /root/test.sh который выполняет некоторые действия, и хочу запустить его сразу после запуска системы. Добавляем в файл rc.local строку:
Начиная с CentOS 7, разработчики указывают на то, что rc.local устаревший демон и осуществлять автозапуск скриптов или сервисов через него, это прошлый век. Но пока он работает, я пользуюсь им, так как он очень прост в эксплуатации.
Создание собственного демона и добавление его в systemd
Вы можете создать собственный демон, которым можно будет управлять через systemd.
Например, нам нужно запускать все тот же скрипт /root/test.sh после перезагрузки системы. Начнем с создания файла нашей будущей службы:
touch /etc/systemd/system/test-script.service
chmod 664 /etc/systemd/system/test-script.service
nano /etc/systemd/system/test-script.service
Содержимое файла будет следующее:
User – пользователь под которым будет запускаться демон
Type=oneshot — процесс будет завершен до запуска дальнейших юнитов
Проверяем и перезапускаем:
# systemctl daemon-reload
# systemctl start test-script.service
# systemctl status test-script.service
Если вас устроило то, как работает сервис, добавьте его в автозагрузку:
# systemctl enable test-script.service
Таким образом, вы можете добавить любой ваш скрипт в автозагрузку через systemd.
Автозапуск через cron
Если вам с какой-то периодичностью нужно запускать скрипт или команду, вы можете воспользоваться cron-ом:
И добавьте туда нужное вам задание, например:
* * * * * /root/test.sh — запускать скрипт каждую минуту.
Можно написать скрипт watch-dog, который по заданию будет проверять, например, статус какого-либо сервиса и, если он не работает, запускать его. На нескольких своих проектах я использую подобную схему.
Чтобы вывести список всех заданий в крон, нужно выполнить команду:
Допустимые значения для времени запуска заданий cron по порядку:
В нашем задании скрипт запускается каждую минуту, поэтому там стоят «*».
Так же вы можете разместить нужный вам скрипт в директориях cron:
Скрипты в указанных директория будут запускаться согласно автоматически подготовленного расписания.
.bashrc: автозапуск скриптов при запуске терминала
Если вам требуется выполнять какие-то действия при запуске терминала ssh, вы можете добавить любую команду или выполнение скрипта в .bash_profile или .bashrc. Теоретически, вы можете добавить какое-либо действие в любой из этих файлов, оно выполнится в любом случае. Обычно все необходимое добавляется в .bashrc, а сам .bashrc запускают из .bash_profile.
Я добавил в файл .bashrc команду на рестарт веб-сервиса nginx:
service nginx restart
После этого сохранил файл и перезапустил терминал:
Как видите, при запуске терминала, веб-сервер был перезапущен. Какие действия можно выполнять при запуске терминала? Вероятно, запускать какие-то вспомогательные утилиты, например, проверка uptime сервера:
Или вы хотите, чтобы при запуске терминала, вы сразу попадали в нужную вам директорию и запускали mc, добавьте в .bashrc
Надеюсь эта статья по управлению автозапуском сервисов и скриптов в LInux (статья писалась для CentOS) оказалась полезной для вас. Наверняка тем, кто только познает азы системного администрирования Linux, это информация будет кстати.