Linux как запускать сервисы

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Как запустить, остановить и перезапустить сервисы в Linux

Start — Stop — Restart — Reload

3 минуты чтения

Linux обеспечивает детальный контроль над системными службами через systemd с помощью команды systemctl. Службы могут быть включены, выключены, перезапущены, перезагружены или даже включены или отключены при загрузке. Если вы используете Debian, CentOSили Ubuntu, ваша система, вероятно, использует systemd.

Мини — курс по виртуализации

Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

Это руководство покажет вам, как использовать основные команды для запуска, остановки и перезапуска служб в Linux.

Базовый синтаксис команды systemctl

Основной синтаксис для использования команды systemctl:

Как правило, вам нужно запускать это как суперпользователь поэтому команды будут начинаться с sudo.

Как проверить, работает ли служба в Linux

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

Замените SERVICE_NAME на нужный сервис.

В нашем случае мы будем брать за пример веб-сервер Apache.

Интересный факт: в Ubuntu и других дистрибутивах на основе Debian служба Apache называется apache2. В CentOS и других дистрибутивах RedHat служба Apache называется httpd или httpd.service

Так мы проверили состояние Apache. Выходные данные показывают, что служба активна (работает), как на рисунке ниже:

Как перезапустить сервис

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

Где SERVICE_NAME — имя вашего сервиса.

После выполнения команды ваш сервис должен снова заработать. Вы можете проверить состояние с помощью команды status

Для перезапуска нашего сервера Apache используем:

Как перезагрузить конфигурационные файлы сервиса

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

После перезагрузки проверьте ее состояние командой status для подтверждения.

В нашем примере мы перезагрузили Apache, используя:

Как запустить сервис

Чтобы запустить службу в Linux вручную, введите в терминале следующее:

Например, команда для запуска службы Apache:

Как остановить сервис

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

Для нашего апача используем команду

Проверьте, остановился ли сервис с помощью команды status . Вывод должен показать, что сервис неактивен — inactive (dead)

Как включить сервис при загрузке

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

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

Как отключить сервис при загрузке

Вы можете запретить запуск службы при загрузке с помощью команды:

Онлайн курс по Linux

Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps

Полезно?

Почему?

😪 Мы тщательно прорабатываем каждый фидбек и отвечаем по итогам анализа. Напишите, пожалуйста, как мы сможем улучшить эту статью.

😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.

Источник

Запуск worker’ов сервиса с помощью systemd

После выхода Ubuntu 16.04 (новый LTS релиз), systemd стал реальностью всех основных дистрибутивов Linux, использующихся на серверах. Это означает, что можно закладываться на расширенные возможности systemd, не рискуя оставить часть пользователей приложения «за бортом».

Этот пост о том, как реализовать многоворкерное приложение средствами systemd.

Abstract: Использование шаблонов сервисов и target’ов для запуска нескольких инстансов сервиса (реализация «воркеров»). Зависимость PartOf. Немного про [install] секцию у unit’ов.

Вступление

Многие языки программирования с плохой или никакой многопоточностью (Python, Ruby, PHP, довольно часто C/C++) используют концепцию «воркера». Вместо того, чтобы городить сложные отношения между тредами внутри приложения, они запускают несколько однопоточных копий приложения, каждое из которых берёт на себя кусок нагрузки. Благодаря опции SO_REUSEPORT есть даже возможность «вместе» слушать на одном и том же порту, что покрывает большинство задач, в которых возникает потребность в воркерах (собственно, обычные серверные приложения, реализующие API или обслуживающие веб-сайт).

Но такой подход требует наличия «супервизора», который отвечает за запуск копий, следит за их состоянием, обрабатывает ошибки, завершает при всякого рода stop/reload и т.д. При кажущейся тривиальности — это совершенно не тривиальная задача, полная нюансов (например, если один из воркеров попал в TASK_UNINTERRUPTIBLE или получил SIGSTOP, то могут возникнуть проблемы при restart у не очень хорошо написанного родителя).

Есть вариант запуска без супервизора, но в этом случае задача reload/restart перекладывается на администратора. При модели «один процесс на ядро» перезапуск сервиса на 24-ядерном сервере становится кандидатом в автоматизацию, которая в свою очередь требует обработки всех тех же самых SIGSTOP и прочих сложных нюансов.

Одним из вариантов решения проблемы является использование шаблонов сервисов systemd вместе с зависимостью от общего target’а.

Теория

Шаблоны

systemd поддерживает «шаблоны» для запуска сервисов. Эти шаблоны принимают параметр, который потом можно вставить в любое место в аргументах командной строки (man systemd.service). Параметр передаётся через символ ‘@’ в имени сервиса. Часть после ‘@’ (но до точки) называется ‘instance name’, кодируется %i или %I. Полный список параметров — www.freedesktop.org/software/systemd/man/systemd.unit.html#Specifiers. Наличие ‘@’ в имени сервиса (перед точкой) указывает на то, что это шаблон.

Попробуем написать простейший template:

И запустим несколько таких:

Теперь мы хотим каким-то образом запускать всех их общим образом. Для этого существуют target’ы

Target’ы

Target — это такой юнит systemd, который ничего не делает, но может использоваться как элемент зависимостей (target может зависеть от нескольких сервисов, или сервисы могут зависеть от target’а, который так же зависит от сервисов).

target’ы имеют расширение .target.

Напишем наш простейший target:
vim /etc/systemd/system/foobar.target

(внимание на .service, оно обязательно!)
Про ‘Wants’ мы поговорим чуть ниже.

Теперь мы можем запускать все три foobar-worker одновременно:
systemctl start foobar.target
(внимание на target — в случае с .service его можно опускать, в случае с .target — нет).

В списке процессов появилось три sleep’а. К сожалению, если мы сделаем systemctl stop foobar.target, то они не исчезнут, т.е. на «worker’ов» они мало похожи. Нам надо как-то объединить в единое целое target и worker’ов. Для этого мы будем использовать зависимости.

Зависимости

Systemd предоставляет обширнейший набор зависимостей, позволяющий описать что именно мы хотим. Нас из этого списка интересует ‘PartOf’. До этого мы использовали wants.
Сравним их поведение:
Wants (который мы использовали) — упомянутый сервис пытается стартовать, если основной юнит стартует. Если упомянутый сервис упал или не может стартовать, это не влияет на основной сервис. Если основной сервис выключается/перезапускается, то упомянутые в зависимости сервисы остаются незатронутыми.
PartOf — Если упомянутый выключается/перезапускается, то основной сервис так же выключется/перезапускается.

Как раз то, что нам надо.

Добавляем зависимость в описание воркера:

Всё. Если мы сделаем systemd stop foobar.target, то все наши воркеры остановятся.

Install-зависимости

Ещё одна интереснейшая фича systemd — install-зависимости. В sysv-init была возможность enable/disable сервисов, но там было очень трудно объяснить, как именно надо делать enable. На каких runlevel’ах? С какими зависимостями?

В systemd всё просто. Когда мы используем команду ‘enable’, то сервис «добавляется» (через механизм slice’ов) в зависимость к тому, что мы указали в секции [install]. Для нашего удобства есть зависимость WantedBy, которая по смыслу обратная к Wanted.

Есть куча стандартных target’ов, к которым мы можем цепляться. Вот некоторые из них (все — man systemd.special):
* multi-user.target (стандартное для «надо запуститься», эквивалент финального runlevel’а для sysv-init).
* default.target — алиас на multi-user
* graphical.target — момент запуска X’ов

Давайте прицепимся к multi-user.target.

Новое содержимое foobar.target:

Теперь, если мы его сделаем enable:

Всё, наш сервис, слепленный из нескольких worker’ов готов запуску/перезапуску как единое целое, плюс его будут запускать при старте нашего компьютера/сервера.

Источник

Шпаргалка по управлению сервисами CentOS 7 с systemd

Systemd – менеджер системы и сервисов в операционной системе Linux. При разработке eго стремились спроектировать обратно совместимым со скриптами инициализации SysV init и предоставить полезные функции, такие, как параллельный запуск системных сервисов во время загрузки, активацию демонов по требованию, поддержку снепшотов состояния системы и логику управления сервисами, основанную на зависимостях. В CentOS 7 systemd заменяет Upstart как систему инициализации по умолчанию.

В этой статье мы рассмотрим процесс управления сервисами в systemd для пользователя CentOS 7. Эти знания будут полезны и в других дистрибутивах, ведь systemd уже давно используется в Fedora и планируется в Ubuntu 14.10 и Debian 8. Хорошо это или нет — оставим за кадром.

В процессе чтения статьи вы можете попробовать systemd на классических VPS и облачных VPS от Infobox. Мы стремимся своевременно добавлять поддержку современных ОС, чтобы вы могли использовать последние технологии для более эффективной работы. Сама идея написания статьи родилась после очередного вопроса пользователей об использовании сервисов в CentOS 7.

Введение

Systemd приносит концепцию юнитов systemd. Юниты представлены конфигурационными файлами, размещенными в одной из директорий:

• /usr/lib/systemd/system/ – юниты из установленных пакетов RPM.
• /run/systemd/system/ — юниты, созданные в рантайме. Этот каталог приоритетнее каталога с установленными юнитами из пакетов.
• /etc/systemd/system/ — юниты, созданные и управляемые системным администратором. Этот каталог приоритетнее каталога юнитов, созданных в рантайме.

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

Типы юнитов systemd:

• .service – системный сервис
• .target — группа юнитов systemd
• .automount – точка автомонтирования файловой системы
• .device – файл устройства, распознанного ядром
• .mount – точка монтирования файловой системы
• .path – файл или директория в файловой системе
• .scope – процесс, созданный извне
• .slice – группа иерархически организованных юнитов, управляющая системными процессами
• .snapshot – сохраненное состояние менеджера systemd
• .socket – сокет межпроцессного взаимодействия
• .swap – Свап-устройство или свап-файл (файл подкачки)
• .timer – таймер systemd

Основные функции systemd в CentOS 7

• Активация, основанная на сокетах. Во время загрузки systemd прослушивает сокеты для всех системных сервисов, поддерживает этот тип активации и передает сокеты этим сервисам сразу после старта сервисов. Это позволяет systemd не только запускать сервисы параллельно, но также дает возможность перезапускать сервисы без потери любых отправленных им сообщений, пока сервисы были недоступны. Соответствующий сокет остается доступным и все сообщения выстраиваются в очередь.
• Активация, основанная на D-Bus. Системные сервисы, использующие D–Bus для межпроцессного взаимодействия, могут быть запущены по требованию, когда клиентское приложение пытается связаться с ними.
• Активация, основанная на девайсах. Системные сервисы, поддерживающие активацию, основанную на девайсах, могут быть запущены, когда определенный тип оборудования подключается или становится доступным.
• Активация, основанная на путях. Системные сервисы могут поддерживать этот вид активации, если изменяется состояние папки или директории.
• Снепшоты системных состояний. Система может сохранять состояние всех юнитов и восстанавливать предыдущее состояние системы.
• Управление точками монтирования и автомонтирования. Systemd отслеживает и управляет точками монтирования и автомонтирования.
• Агрессивная параллелизация Systemd запускает системные сервисы параллельно из-за использования активации, основанной на сокетах. В комбинации с сервисами, поддерживающими активацию по требованию, параллельная активация значительно уменьшает время загрузки системы.
• Транзакционная логика активации юнитов. До активации и деактивации юнитов systemd вычисляет их зависимости, создает временную транзакцию и проверяет целостность этой транзакции. Если транзакция нецелостная, systemd автоматически пытается исправить ее и удалить не требующиеся задания из нее до формирования сообщения об ошибке.
• Обратная совместимость с инициализацией SysV. SystemD полностью поддерживает скрипты инициализации SysV, как описано в спецификации Linux Standard Base (LSB), что упрощает переход на systemd.

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

В предыдущих версиях CentOS использовалась SysV или Upstart. Скрипты инициализации располагались в директории /etc/rc.d/init.d/. Такие скрипты обычно писались на Bash и позволяли администратору управлять состоянием сервисов и демонов. В CentOS 7 скрипты инициализации были заменены сервисными юнитами.

По способу использования сервисные юниты .service напоминают скрипты инициализации. Для просмотра, старта, остановки, перезагрузки, включения или выключения системных сервисов используется команда systemctl. Команды service и chkconfig по-прежнему включены в систему, но только по соображениям совместимости.

При использовании systemctl указывать расширение файла не обязательно.

Ниже представлены основные команды systemctl:

• systemctl start name.service – запуск сервиса.
• systemctl stop name.service — остановка сервиса
• systemctl restart name.service — перезапуск сервиса
• systemctl try-restart name.service — перезапуск сервиса только, если он запущен
• systemctl reload name.service — перезагрузка конфигурации сервиса
• systemctl status name.service — проверка, запущен ли сервис с детальным выводом состояния сервиса
• systemctl is-active name.service — проверка, запущен ли сервис с простым ответом: active или inactive
• systemctl list-units —type service —all – отображение статуса всех сервисов
• systemctl enable name.service – активирует сервис (позволяет стартовать во время запуска системы)
• systemctl disable name.service – деактивирует сервис
• systemctl reenable name.service – деактивирует сервис и сразу активирует его
• systemctl is–enabled name.service – проверяет, активирован ли сервис
• systemctl list-unit-files —type service – отображает все сервисы и проверяет, какие из них активированы
• systemctl mask name.service – заменяет файл сервиса симлинком на /dev/null, делая юнит недоступным для systemd
• systemctl unmask name.service – возвращает файл сервиса, делая юнит доступным для systemd

Работаем с целями (targets) Systemd

Предыдущие версии CentOS с SysV init или Upstart включали предопределенный набор уровней запуска (runlevels), которые представляли специфичные режимы для операций, пронумерованные от 0 до 6. В CentOS 7 концепция уровней запуска была заменена целями systemd.

Файлы целей systemd .target предназначены для группировки вместе других юнитов systemd через цепочку зависимостей. Например юнит graphical.target, использующийся для старта графической сессии, запускает системные сервисы GNOME Display Manager (gdm.service) и Accounts Service (accounts–daemon.service) и активирует multi–user.target. В свою очередь multi–user.target запускает другие системные сервисы, такие как Network Manager (NetworkManager.service) или D-Bus (dbus.service) и активирует другие целевые юниты basic.target.

В CentOS 7 присутствуют предопределенные цели, похожие на стандартный набор уровней запуска. По соображениям совместимости они также имеют алиасы на эти цели, которые напрямую отображаются в уровнях запуска SysV.

• poweroff.target (runlevel0.target) – завершение работы и отключение системы
• rescue.target (runlevel1.target) – настройка оболочки восстановления
• multi–user.target (runlevel2.target, runlevel3.target, runlevel4.target) – настройка неграфической многопользовательской системы
• graphical.target (runlevel5.target) – настройка графической многопользовательской системы
• reboot.target (runlevel6.target) – выключение и перезагрузка системы

Команды runlevel и telinit по-прежнему доступны, но оставлены в системе по соображениям совместимости. Рекомендуется использовать systemctl для изменения или настройки системных целей.

Для определения, какой целевой юнит используется по умолчанию, полезна следующая команда: systemctl get–default.

Для просмотра всех загруженных целевых юнитов воспользуйтесь командой systemctl list-units —type target, а для просмотра вообще всех целевых юнитов командой: systemctl list-units —type target —all.

Для изменения цели по умолчанию поможет команда systemctl set-default name.target.

Для изменения текущей цели: systemctl isolate name.target. Команда запустит целевой юнит и все его зависимости и немедленно остановит все остальные.

Выключение и перезагрузка системы

В CentOS 7 systemctl заменяет значительное количество команд управления питанием. Прежние команды сохранены для совместимости, но рекомандуется использовать systemctl:
systemctl halt – останавливает систему
systemctl poweroff – выключает систему
systemctl reboot – перезагружает систему

Управление systemd на удаленной машине

Systemd позволяет управлять удаленной машиной по SSH. Для управления используйте команду:
systemctl —host user_name@host_name command, где user_name – имя пользователя, host_name – имя хоста, которым осуществляется удаленное управление, а command – выполняемая команда systemd.

Типичный systemd .service

Этот раздел поможет вам, если вам необходимо быстро сделать поддержку управления сервисом из systemd. Подробная информация о всех параметрах файла .service есть в соответствующем разделе документации по systemd.

Давайте посмотрим на секцию [Unit]. Она содержит общую информацию о сервисе. Такая секция есть не только в сервис-юнитах, но и в других юнитах (например при управлении устройствами, точками монтирования и т.д.). В нашем примере мы даем описание сервиса и указываем на то, что демон должен быть запущен после Syslog.

В следующей секции [Service] непосредственно содержится информация о нашем сервисе. Используемый параметр ExecStart указывает на исполняемый файл нашего сервиса. В Type мы указываем, как сервис уведомляет systemd об окончании запуска.

Финальная секция [Install] содержит информацию о цели, в которой сервис должен стартовать. В данном случае мы говорим, что сервис должен быть запущен, когда будет активирована цель multi–user.target.

Это минимальный работающий файл сервиса systemd. Написав свой, для тестирования скопируйте его в /etc/systemd/system/имя_сервиса.service. Выполните команды systemctl daemon-reload. Systemd узнает о сервисе и вы сможете его запустить.

Дополнительная информация

Заключение

В этой статье мы научились управлять сервисами CentOS 7. Конечно, это далеко не единственная функция systemd и другие ее стороны будут рассмотрены в будущем. Сама ОС практически со времени релиза доступна на классических VPS и облачных VPS от Infobox. Попробуйте systemd прямо сейчас. Эти знания будут полезны в связи с переходом многих дистрибутивов на systemd.

Если вы обнаружили ошибку в статье, автор ее с удовольствием исправит. Пожалуйста напишите в ЛС или на почту о ней.
В случае, если вы не можете оставлять комментарии на Хабре, можно написать их в блоге Сообщества InfoboxCloud или в нашей группе в Facebook.

Источник