Ubuntu запуск приложения как сервис

Обновлено: 06.01.2025

Я написал серверное приложение Java, которое работает на стандартном виртуальном размещенном решении Linux. Приложение работает все время прослушивания сокетов соединений и создания новых обработчиков для них. Это реализация на стороне сервера для клиент-серверного приложения.

Как я начинаю это, включив его в start up rc.местные скрипт сервера. Однако после запуска я не знаю, как получить к нему доступ, чтобы остановить его, и если я хочу установить обновление, поэтому я должен перезапустить сервер, чтобы перезапустить приложение.

на ПК с windows для этого типа приложений я мог бы создать службу windows, а затем я могу остановить и запустить ее, как я хочу. Есть ли что-то подобное в Linux box, чтобы при запуске этого приложения я мог остановить его и перезапустить без полного перезапуска сервера.

мое приложение называется WebServer.исполняемый. Он запускается при запуске сервера, включая его в мой rc.местные такие как:

Я написал здесь еще одну простую обертку:

вы можете следовать полный учебник для init.d здесь и для systemd (ubuntu 16+) здесь

Если вам нужен журнал вывода, замените 2

простым решением является создание скрипта start.sh это запускает Java через nohup, а затем сохраняет PID в файл:

тогда ваш сценарий остановки stop.sh прочитал бы PID из файла и убил бы приложение:

конечно, я опустил некоторые детали, например, проверить, существует ли процесс и удалить pid.txt Если вы закончили.

скрипт инициализации службы Linux хранятся в /etc/init.d . Вы можете копировать и настраивать /etc/init.d/skeleton файл, а затем вызов

возможно, не лучшее решение для dev-ops, но хорошо для общего использования сервера для вечеринки lan или аналогичного.

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

документооборот:

пуск экран: screen

запустить сервер: java -jar minecraft-server.jar

отключить нажатием: Ctl-a , d

прикрепления: screen -r

Другой альтернативой, которая также довольно популярна, является Java Service Wrapper. Это также довольно популярно в сообществе OSS.

ссыль приложение Spring Boot в качестве службы а также, я бы пошел на systemd версия, так как это самый простой, наименее подробный и лучше всего интегрирован в современные дистрибутивы (и даже не очень современные, такие как CentOS 7.икс.)

вот пример сценария оболочки (убедитесь, что вы заменили математическое имя на имя вашего приложения):

С приложение Spring Boot в качестве службы, Я могу порекомендовать Python-based supervisord приложение. См. этот вопрос переполнения стека для получения дополнительной информации. Это очень просто настроить.

Несмотря на большое количество проблем и ненависть некоторых пользователей, systemd уже стал стандартом де-факто во многих дистрибутивах Linux. С его помощью из десяток строк настроек можно за несколько минут создать несложный процесс . В то же время многие более интересные возможности документированы не очень понятным языком или требуют углубленных познаний в тонкостях работы systemd.

Основы создания сервиса Linux

Если вы еще никогда не делали свои сервисы, начнем с основ. Systemd оперирует абстрактными единицами (unit), которые бывают разных типов, могут предоставлять различные ресурсы (процессы, сокеты, абстрактные «цели») и требовать других ресурсов для запуска.

Самый распространенный вид ресурса — сервис (service). Файлы с описаниями сервисов и всего прочего лежат в каталоге /lib/systemd/system/ . Чтобы systemd нашел новый сервис, достаточно положить в этот каталог свой файл. Если этот сервис ранее не существовал, systemd прочитает файл и загрузит его в память. Однако, если вы редактируете файл ранее запущенного сервиса, не забудьте заставить systemd перечитать файлы командой sudo systemctl daemon-reload !

Сервисы типа oneshot — долой rc.local

Когда-то основным способом добавить выполнение команд в загрузку системы было дописать их в /etc/rc.local. Очевидный недостаток — нет способов следить, насколько успешно они выполнились. В systemd легко создать для такой цели свой сервис типа oneshot, и им можно будет управлять через systemctl, как любым другим. В этом случае systemd выполнит команду и посчитает запуск сервиса успешным, если она завершилась с кодом ноль.

Сохраним следующий файл в /lib/systemd/system/dumb-test.service :

Дополнительных действий не требуется, и теперь вы можеыр делать с ним все то же, что с системными сервисами: запустить с помощью sudo systemctl start dumb-test.service , поставить на загрузку с помощью sudo systemctl enable dumb-test.service и так далее.

Создание сервиса из любой программы

Любой долгоживущий процесс можно легко превратить в сервис с помощью опции Type=idle . В этом случае systemd перехватит стандартные потоки ввода-вывода и будет следить за жизнью процесса.

Затем создадим для нее файл сервиса в /lib/systemd/system/smart-test.service :

ExecStart =/ usr / bin / python3 - u / usr / local / bin / test . py

Теперь можно запустить наш сервис и убедиться, что он работает:

Loaded : loaded ( / usr / lib / systemd / system / smart - test . service ; static ; vendor preset : disabled ) Active : active ( running ) since Fri 2019 - 10 - 25 16 : 25 : 18 + 07 ; 1s ago └─ 19893 / usr / bin / python3 - u / usr / local / bin / test . py

Стандартный вывод программы пишется в journald, и его можно увидеть в journalctl -u smart-test . Ради интереса посмотрим на работу опции Restart=on-failure . Остановим наш процесс с помощью kill -9 $ и заглянем в логи:

smart - test . service : Main process exited , code = killed , status = 9 / KILL smart - test . service : Service RestartSec = 100ms expired , scheduling restart . smart - test . service : Scheduled restart job , restart counter is at 1.

Для настоящих демонов нужно использовать тип forking , но мы не будем вдаваться в детали — авторы таких пакетов наверняка все уже знают сами.

Зависимости и порядок запуска

Опций для настройки зависимости в systemd очень много. Прежде всего нужно отметить, что в нем есть два независимых механизма для указания порядка запуска сервисов и зависимостей между ними.

Порядок запуска сервисов

Порядок запуска сервисов определяется опциями Before и After . Если в настройках сервиса foo написано After=bar.service и оба сервиса должны запуститься, то systemd сначала выполнит попытку запустить bar, а затем foo.

Однако опция After=bar.service сама по себе не поставит сервис на загрузку. Более того, она никак не повлияет на решение запускать foo, даже если запуск bar завершится неудачей.

Причина существования этих опций — способность systemd запускать сервисы параллельно.

Для примера возьмем типичный веб-сервер с набором из веб-приложения FCGI, СУБД и обратного прокси. В каком порядке запускать процесс FCGI и обратный прокси, не так важно. Запросы будут работать, только когда они оба запущены, но «неверный порядок» никак не помешает им запуститься.

Если веб-приложение требует данных из базы для инициализации, то мало убедиться, что и процесс FCGI, и СУБД запущены, — приложение нужно запускать только после полного запуска СУБД. Именно для этих случаев и предназначены опции Before/After .

Зависимости

Зависимости бывают двух видов: мягкие и жесткие. Если оба сервиса запустились успешно, то никакой разницы между ними нет. Различие вступает в действие, если один из сервисов не смог запуститься: если зависимость мягкая, то зависимые сервисы все равно будут запущены, а если жесткая, то systemd не станет даже пробовать их запустить.

Мягкие зависимости указываются с помощью опции Wants= в секции [Unit] . Пример из sshd.service :

Цель sshd-keygen.target , очевидно, генерирует ключ хоста, если он отсутствует. Технически sshd не сможет запуститься без ключа хоста, поэтому, почему авторы решили сделать зависимость мягкой, можно только догадываться. Возможно, они посчитали, что в большинстве случаев ключ уже существует и устаревший ключ лучше неработающего SSH.

При копировании настроек из пакетов дистрибутива нужно быть осторожным. Разработчики дистрибутивов тоже люди и вполне могут создавать неоптимальные или ошибочные конфигурации. Кроме того, если что-то работает для одного сервиса, совсем не факт, что оно же подойдет для другого, так что сверяйтесь с документацией и тестируйте перед выпуском.

У этой опции существуют вариации, например RequiresMountsFor . Посмотрим в файл logrotate.service :

Documentation = man : logrotate ( 8 ) man : logrotate . conf ( 5 )

Для работы logrotate нужен доступ к каталогу с логами и больше ничего. Опция RequiresMountsFor=/var/log позволяет выразить именно это: сервис запустится, как только будет примонтирован каталог, содержащий путь /var/log , даже если он находится не в корневом разделе.

Внедрение в зависимости к чужим сервисам

В системах с System V init добавить что-то в зависимости к чужому сервису можно было, лишь отредактировав его скрипт. Такие изменения, очевидно, не переживут обновления системы, поэтому сделать их постоянными можно было бы только пересборкой пакета.

В systemd есть несколько способов решить эту проблему. Если нужно именно внедриться к кому-то в зависимости, можно попробовать опции обратных зависимостей: WantedBy и RequiredBy . Они должны находиться в секции [Install] , а не [Unit] . Подводных камня здесь два: они обрабатываются только при установке сервиса с помощью systemctl enable и, как все в systemd, не всегда нормально работают во всех версиях.

Второй вариант, который позволяет менять любые настройки: скопировать файл сервиса в /etc/systemd/system/ . Если один файл присутствует в обоих каталогах, то файл из /etc/systemd/system имеет приоритет.

В операционной системе linux, так же как и в Windows, кроме обычных программ, которые могут взаимодействовать с пользователем есть еще один вид программ. Это работающие в фоне службы. Важность служб тяжело переоценить, они следят за состоянием системы, обеспечивают автоматическое подключение внешних устройств и сети, позволяют процессам взаимодействовать с оборудованием (dbus), а также в виде служб реализованы различные веб-серверы и серверы баз данных. В отличие от пользовательских программ, службы выполняются в фоне, и пользователь не имеет к ним прямого доступа. Пользователь еще не вошел в систему, только началась загрузка а основные службы уже запущенны и работают.

В этой статье мы рассмотрим управление службами Linux. Мы не будем трогать уже устаревшие системы, такие как SysVinit, сосредоточимся только на Systemd. Вы узнаете, как посмотреть запущенные службы linux, а также останавливать и запускать их самому.

Немного теории

Но потом на смену этому методу пришла новая модель и система инициализации systemd. Система инициализации запускается сразу после загрузки ядра и начинает инициализировать службы, теперь появилась возможность параллельной инициализации, а также зависимостей между службами. Таким образом, теперь можно определить сложное дерево порядка запуска служб. Но мы не будем вникать в подробности создания служб, нас интересует только сам процесс запуска. После запуска systemd собирает весь вывод службы в лог, и следит за ее работой, если служба аварийно завершилась, то автоматически ее перезапускает.

Служба в Systemd описывается файлом юнита, в нем описано что с ней нужно делать и как себя вести. Существуют такие типы служб:

service - обычная служба, программа
target - группа служб
automount - точка автоматического монтирования
device - файл устройства, генерируется на этапе загрузки
mount - точка монтирования
path - файл или папка
scope - процесс
slice - группа системных служб systemd
snapshot - сохраненное состояние запущенных служб
socket - сокет для взаимодействия между процессами.

Нас будут интересовать только service, и совсем немного target, но мы рассмотрели все остальные, чтобы вы смогли взглянуть на картину немного шире. Основы рассмотрели, теперь будет настройка служб LInux.

Утилита systemctl

В Systemd есть специальный инструмент для управления службами в Linux - systemctl. Эта утилита позволяет делать очень много вещей, начиная от перезапуска службы linux и проверки ее состояния, до анализа эффективности загрузки службы. Синтаксис у утилиты такой:

$ systemctl опции команда служба служба.

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

Рассмотрим все по порядку. Опции очень сильно зависят от команд, поэтому рассмотрим их позже, а пока пройдемся по командах:

А теперь основные опции:

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

Управление службами Linux

Теперь, когда вы уже знаете все основы, команды и параметры можно переходить к делу. Со всеми остальными тонкостями разберемся по пути. Сначала давайте посмотрим запущенные службы linux. Нас будут интересовать только программы, а не все эти дополнительные компоненты, поэтому воспользуемся опцией type:

systemctl list-units --type service

Команда отобразила все службы, которые известны systemd, они сейчас запущены или были запущены. Программа не пересматривает все файлы, поэтому будут показаны только те службы, к которым уже обращались. Состояние loaded - означает, что конфигурационный файл был успешно загружен, следующая колонка active - служба была запущена, а running или exited значит выполняется ли сейчас служба или она успешно завершила свою работу. Листать список можно кнопками вверх/вниз.

Следующая команда позволяет получить список служб linux, в который входят все службы, даже не запущенные, те, которые не запускались, но известны systemd, но это еще не все службы в системе:

systemctl list-units --type service -all

Дальше больше. Вы можете отсортировать список служб systemctl по состоянию. Например, только выполняющиеся:

systemctl list-units --type service --state running

Или те, которые завершились с ошибкой:

systemctl list-units --type service --state failed

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

Теперь отфильтруем только службы linux:

systemctl list-unit-files --type service

Здесь вы тоже можете использовать фильтры по состоянию. Теперь вы знаете как посмотреть запущенные службы linux, идем дальше.

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

sudo systemctl start application.service

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

Остановить службу linux можно командой:

sudo systemctl stop application

Посмотреть состояние службы позволяет команда status:

sudo systemctl status application

Здесь вы можете видеть, состояние running, exited, dead, failed и т д. А также несколько последних строчек вывода программы, которые очень помогут решить проблему с запуском если она возникнет.

Автозагрузка служб в systemd

Как вы знаете, systemd позволяет автоматически загружать службы при запуске системы по мере их надобности. Команда list-unit-files показывает добавлена ли служба в автозагрузку.

Вообще, здесь может быть несколько состояний - enabled - в автозагрузке, disabled - автозагрузка отключена, masked - служба скрыта и static - значит что служба в автозагрузке, но вы не можете ее отключить.

Поэтому чтобы получить список служб linux, запускаемых автоматически достаточно отфильтровать ее вывод по состоянию:

systemctl list-unit-files --state enabled

Все службы, запускаемые по умолчанию. Можете также посмотреть службы static. Чтобы добавить службу в автозагрузку linux используйте команду enable:

sudo systemctl enable application

А для того чтобы убрать ее из автозагрузки:

sudo systemctl disable applciation

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

sudo systemctl is-enabled application

Утилита просто выведет состояние enabled, disabled или static.

Выводы

Теперь настройка служб Linux не вызовет у вас проблем. Много чего мы упустили, systemd - очень большая, сложная и многофункциональная система, которую не охватить в одной статье. Но и также очень сложно понять. Но я думаю, что все, что касается управления службами Linux мы разобрали. Если у вас остались вопросы, спрашивайте в комментариях!

Как и во всех других операционных системах, в Linux есть службы и процессы, выполняемые во время работы системы в фоновом режим. Когда система загружается, сервисы запускаются автоматически и продолжают работать, пока система не выключится. Однако вы можете запускать, останавливать и перезапускать службы вручную.

Рассмотрим различные способы запуска, остановки и перезапуска служб в Ubuntu с помощью systemd, команды service и сценария инициализации init.

Список всех сервисов в Ubuntu
Прежде всего нужно получить список всех служб на вашем компьютере.

Он покажет полный список сервисов на вашем компьютере.

Использование Systemd для запуска / остановки / перезапуска служб в Ubuntu

Вы можете запускать, останавливать или перезапускать сервисы с помощью утилиты systemd systemctl. Начиная с версии 16.04 Ubuntu включает в себя systemd как init-систему по умолчанию. На сегодняшний день это предпочтительный способ работы со службами.

sudo systemctl [действие] [имя службы]

Например, рассмотрим как запустить, остановить или перезапустить службу брандмауэра ufw в Ubuntu.

Откройте окно терминала и введите следующие команды.

Проверить статус службs:

Управление сервисами с помощью systemd

Запуск / остановка / перезапуск сервисов в Ubuntu с помощью команды service

Вы также можете запускать, останавливать или перезапускать службы, используя service. Откройте окно терминала и введите следующие команды.

Проверить статус службы:

Использование скриптов Init для управления сервисами в Ubuntu

Вы можете запускать, останавливать или перезапускать службы, используя сценарии инициализации в каталоге /etc/init.d. Этот каталог на самом деле содержит в себе различные скрипты для разных сервисов. Сценарии инициализации устарели с тех пор, как Ubuntu перешла на Systemd, поэтому этот метод будет использоваться, только если вам приходится иметь дело со старой версией Ubuntu. Откройте окно терминала и введите следующие команды.

Проверить статус службы:

Таким образом, вы можете запускать, останавливать и перезапускать службы разными способами, не перезагружая всю операционную систему. Вы также можете использовать эти команды в других дистрибутивах Linux.

Читайте также: