Vendor preset disabled что означает
systemd Часть 2: Управление юнитами, зависимостями и целями
Этой вторая часть о systemd и юнитах.
В этой статье разберем управление юнитами, зависимостями и целями.
Управление юнитами через systemd
Вот как это делается?
Для примера установим пакет php-fpm :
Запускаем сервис php-fpm.service :
Как я узнал, что сервис называется именно так и что вообще при установке пакета создался и сервис?
В первой части статьи было сказано:
Поэтому вводим и получаем:
Значит юнит-файл service уже создан пакетом:
Запускаем:
Снова смотрим статус:
Сервис успешно запущен. Но чтобы он всегда запускался при загрузке системы, поставим его в автозагрузку.
Используя команду systemctl status вы можете увидеть такие состояния:
Управление зависимостями
Юниты systemctl во многих случаях имеют зависимости. Некоторые юниты будут запускаться как зависимость от других юнитов, и событие, когда запрашивается один конкретный юнит, может вызвать запуск другого юнита.
На примере всё того же php-fpm посмотрим список зависимостей:
Так как список большой, то отобразил только несколько строк.
Изолирующие цели
Чтобы посмотреть все загруженные цели, введем:
Некоторые из целей в системе играют важную роль, поскольку их можно запускать (изолировать) для определения уровня запуска системы и которые можно установить в качестве цели по умолчанию.
Система перейдет в режим восстановления:
Управляем автозагрузкой в Linux
Systemd — управление автозагрузкой служб в Linux
В большистве популярных современных популярных дистрибутивов Linux (CentOS, 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 вы получите полный список.
Добавление сервиса в systemd
Для управления сервисами в systemd используется особый синтаксис. После имени серверсв в конце нужно указывать .service. Например:
команда добавит в автозагрузку веб-сервер nginx
Данная команда создаст символическую ссылку на копию файла, указанного в команде сервиса, в директории автозапуска systemd.
Вывод этой команды показывает в какой директории был создан симлинк на файл сервиса.
Чтобы посмотреть добавлен тот или иной сервис в автозагрузку, можно проверить его статус:
При выводе нужно обратить внимание на строку:
Значение enabled означает что данный сервис загружается автоматически (добавлен в автозагрузку). Если сервис не загружается автоматом, здесь буде указано disabled.
Удаление сервиса из systemd
Вы можете удалить сервис из автозагрузки, чтобы он не запускался после старта Linux (при этом сам сервис с сервера не удаляется). Чтобы удалить сервис из автозагрузки, выполните команду (* — нужный сервис):
Например, чтобы удалить из автозагрузки nginx, выполните:
После выполнения команды, симлинк на файл сервиса будет удален из директории systemd. Можно проверить, есть ли юнит в автозагрузке:
Systemd — маскировка юнитов
Иногда встречаются ненужные сервисы, которые после удаления их из автозагрузки, все равно там оставались и запускаются после перезагрузки. Чтобы решить этот вопрос, можно замаскировать сервис:
И после этого он вообще не будет запускаться:
Снять маску можно командой:
Если после маскировки сервиса, вы проверите юнит-файлы, то увидите, что сервис помечен как замаскированный (состояние masked).
Таким нехитрым способом, можно избавить себя от удаления сервиса, даже если он не удаляется из автозагрузки systemd.
Собственный демон и добавление его в systemd
Можно создать собственный демон, которым будем управлять через systemd.
Например, нам нужно запускать все тот же скрипт /root/script.sh после перезагрузки системы. Начнем с создания файла нашей будущей службы:
Содержимое файла будет следующее:
User — пользователь под которым будет запускаться демон
Type=oneshot — процесс будет завершен до запуска дальнейших юнитов
Проверяем и перезапускаем:
Если все хорошо, добавляем его в автозагрузку:
Таким образом, мы можем добавить любой скрипт в автозагрузку через systemd.
Управление автозагрузкой сервисов и скриптов в Linux
Управление автозагрузкой сервисов и скриптов в 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, это информация будет кстати.
Управление автозагрузкой сервисов и скриптов в 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, это информация будет кстати.