Для изменения списка сервисов загружаемых при старте linux

Управление службами Systemd. Часть 1 из 3

Systemd — это система инициализации и системный менеджер, который становится новым стандартом для Linux. Systemd управляет юнитами, которые определяются в так называемых юнит-файлах. Cамым распространённым юнитом является сервис (файл с расширением .service). Основной инструмент для управления сервисами — команда systemctl .

Управление сервисами

Основная цель Systemd — инициализировать компоненты, которые должны запускаться после загрузки ядра Linux. Systemd (и команда systemctl ) также используется для управления сервисами и демонами сервера.

Запуск и остановка сервиса

Для запуска сервиса предназначена команда start :

Чтобы остановить сервис, достаточно ввести команду stop :

Перезапуск и перезагрузка

Для запуска сервиса systemd предназначена команда restart :

Если приложение может перезагрузить свои конфигурационные файлы (без перезапуска), можно использовать команду reload :

Если не известно, может ли сервис перезагрузить свои файлы, тогда используется команда reload-or-restart . Она перезагрузит сервис, а если это невозможно — перезапустит его.

Включение и отключение сервисов

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

Это создаст символическую ссылку на файл сервиса (этот файл обычно расположен в /lib/systemd/system или /etc/systemd/system ) в специальном каталоге, где Systemd ищет файлы для автозапуска (обычно /etc/systemd/system/something.target.want ).

Посмотрим содержимое каталога /etc/systemd/system и отфильтруем только директории *.wants :

Заглянем в директорию bluetooth.target.wants :

Заглянем в директорию multi-user.target.wants :

Чтобы убрать сервис из автозагрузки, нужно ввести:

Это удалит символическую ссылку, после этого сервис перестанет запускаться автоматически.

Проверка состояния сервиса

Для проверки состояния сервиса предназначена команда status :

Эта команда выведет состояние сервиса, иерархию групп и первые несколько строк лога. Например, при проверке состояния сервера Nginx, можно увидеть такой вывод:

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

Последняя команда позволяет определить, находится ли юнит в состоянии сбоя. Это указывает на то, что возникла проблема с запуском рассматриваемого юнита.

Обзор состояния системы

Ранее мы рассмотрели команды, необходимые для управления отдельными сервисами, но они не очень полезны для изучения текущего состояния системы. Существует несколько команд systemctl, которые предоставляют эту информацию.

Просмотр списка текущих юнитов

Для просмотра списка текущих юнитов предназначена команда list-units :

В выводе есть такие столбцы:

• UNIT — название юнита
• LOAD — конфигурация юнита обработана?
• ACTIVE — сводное состояние юнита (запущен или нет)
• SUB — состояние более низкого уровня
• DESCRIPTION — краткое описание функций юнита

Поскольку команда list-units показывает по умолчанию только активные юниты, все записи будут показывать loaded в столбце LOAD и active в столбце ACTIVE .

Чтобы увидеть все юниты, которые загрузила (или попыталась загрузить) система Systemd, независимо от того, активны ли они в данный момент:

Можно использовать другие флаги для фильтрации результатов. Например, флаг state можно использовать для определения состояний LOAD , ACTIVE или SUB . Флаг all нужно оставить, чтобы система отображала неактивные юниты:

Еще один популярный фильтр — это type :

Флаги можно комбинировать:

Список юнит-файлов

Команда list-units отображает только юниты, которые система Systemd попыталась обработать и загрузить в память. Поскольку Systemd избирательно читает только те юнит-файлы, которые кажутся ей необходимыми, список не будет включать все доступные юнит-файлы. Чтобы просмотреть список всех доступных юнит-файлов (включая те, что Systemd не пыталась загрузить), нужно использовать команду list-unit-files .

Обычно столбец STATE содержит значения enabled , disabled , static или masked . В этом контексте static означает, что в юнит-файле нет раздела install , который используется для включения юнита. Таким образом, эти юниты невозможно включить. Обычно это означает, что юнит выполняет одноразовое действие или используется только как зависимость другого юнита и не должен запускаться сам по себе.

Источник

Как изменить порядок запуска / загрузки служб Linux?

Как видно из названия, как изменить порядок запуска / загрузки служб Linux?

Вы можете изменить порядок, переименовав символические ссылки в /etc/rcX.d/, где x будет вашим уровнем выполнения.

Вы увидите кучу файлов, начинающихся с Sxx или Kxx. S-ссылки отслеживаются во время запуска, а K-ссылки анализируются на отключение. Хх здесь представляет порядок.

Но этот порядок установлен по причине, поэтому будьте осторожны при их изменении. Например. ntpd должен запускаться только после инициализации сетевой подсистемы.

Вместо того, чтобы делать это вручную, как предложено в других ответах, вы также можете изменить скрипт инициализации. Просто добавьте такую ​​строку в шапку:

Это даст указание chkconfig добавить службу к уровням выполнения 3 и 5 с начальной позицией 90 и позицией уничтожения 10.

Вы хотите прочитать немного о своих уровнях запуска и каталогах rc.d. Внутри каталогов rc.d вы можете найти ссылки S и K, например, S20apache K10apache, который в основном определяет порядок запуска / выключения скриптов.

В эту архитектуру вносятся некоторые изменения, но большинство linux до сих пор ее используют.

Если вы прибыли сюда, скорее всего, у вас есть две службы, одна из которых зависит от другой, но, поскольку они запускаются в неправильном порядке, служба с зависимостью не запускается. Предложения по редактированию символических ссылок являются информативными, с точки зрения иллюстрации того, как выполняется последовательность запуска, и будут работать нормально, пока кто-то не выполнит «chkconfig on» в вашем сервисе, после чего символические ссылки будут воссозданы в том виде, в котором они были изначально. На самом деле, вы хотите решить проблему на уровне сценария инициализации, что на самом деле гораздо менее грязно. Он также будет одинаковым для разных уровней выполнения. Вероятно, вам не нужно добавлять строку «# chkconfig», как предложено в ответе 4, поскольку там, вероятно, уже будет аналогичная строка.

Я буду использовать пример сервера под управлением Openldap (slapd) с базой данных MySQL (mysqld). Конфигурирование этой пары, и почему вы можете захотеть, это совсем другая история.

При загрузке Openldap не запускается, потому что это зависит от MySQL, и последовательность запуска пытается запустить его раньше — slapd имеет позицию 27, а mysqld — позицию 64

Соответствующие символические ссылки в /etc/rc3.d/

Я ищу значения, установленные в двух сценариях инициализации:

Я редактирую строку chkconfig в /etc/rc.d/init.d/slapd, чтобы иметь стартовую позицию выше, чем в /etc/rc.d/init.d/mysqld (я выбрал 85)

Я делаю «chkconfig slapd on» и перепроверяю символические ссылки

Теперь, когда этот сервер запускается, mysqld запускается до slapd, и с миром все в порядке.

Источник

Управление автозагрузкой сервисов и скриптов в 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 после загрузки ОС или нет).

Чтобы вывести список активных сервисов и их состояние, выполните:

# systemctl list-units -t service

Следующая команда выведет список юнитов, которые загрузил или пытался загрузить systemd. Так как после запуска некоторые юниты могут стать неактивными, с помощью флага —all вы получите полный список.

# systemctl list-units —all

Как видим из списка, здесь отображаются даже сервисы, которые не были найдены на диске «not-found».

Использую данную команду, вы можете добавить и другие флаги, например:

• —state — используется для определения состояния демона Load, Active, Sub
• —type — позволяет фильтровать юниты по их типу.

systemctl list-units —all —state=active — выведет список только активных юнитов

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-ом:

crontab -e — открыть терминал для написания задания cron

И добавьте туда нужное вам задание, например:

* * * * * /root/test.sh — запускать скрипт каждую минуту.

Можно написать скрипт watch-dog, который по заданию будет проверять, например, статус какого-либо сервиса и, если он не работает, запускать его. На нескольких своих проектах я использую подобную схему.

Чтобы вывести список всех заданий в крон, нужно выполнить команду:

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

• Минуты от 0 до 59
• Часы от 0 до 59
• День месяца от 1 до 31
• Месяц от 1 до 12
• День недели от 0 до 7 (0 или 7 это воскресение)

В нашем задании скрипт запускается каждую минуту, поэтому там стоят «*».

Так же вы можете разместить нужный вам скрипт в директориях cron:

• /cron.daily – выполнение скрипта ежедневно
• /cron.hourly – выполнение скрипта ежечасно
• /cron.monthly — выполнение скрипта ежемесячно
• /cron.weekly — выполнение скрипта еженедельно

Скрипты в указанных директория будут запускаться согласно автоматически подготовленного расписания.

.bashrc: автозапуск скриптов при запуске терминала

Если вам требуется выполнять какие-то действия при запуске терминала ssh, вы можете добавить любую команду или выполнение скрипта в .bash_profile или .bashrc. Теоретически, вы можете добавить какое-либо действие в любой из этих файлов, оно выполнится в любом случае. Обычно все необходимое добавляется в .bashrc, а сам .bashrc запускают из .bash_profile.

Я добавил в файл .bashrc команду на рестарт веб-сервиса nginx:

service nginx restart

После этого сохранил файл и перезапустил терминал:

Как видите, при запуске терминала, веб-сервер был перезапущен. Какие действия можно выполнять при запуске терминала? Вероятно, запускать какие-то вспомогательные утилиты, например, проверка uptime сервера:

Или вы хотите, чтобы при запуске терминала, вы сразу попадали в нужную вам директорию и запускали mc, добавьте в .bashrc

Надеюсь эта статья по управлению автозапуском сервисов и скриптов в LInux (статья писалась для CentOS) оказалась полезной для вас. Наверняка тем, кто только познает азы системного администрирования Linux, это информация будет кстати.

Источник