Главная » Linux

Linux service is dead

На чтение 9 мин Просмотров 1 Опубликовано
Содержание
  1. Управление службами Systemd. Часть 1 из 3
  2. Управление сервисами
  3. Запуск и остановка сервиса
  4. Перезапуск и перезагрузка
  5. Добавление в автозагрузку
  6. Проверка состояния
  7. Обзор состояния системы
  8. Просмотр списка текущих юнитов
  9. Список юнит-файлов
  10. Linux Service unexpectedly died

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

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

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

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

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

  • /lib/systemd/system — юниты из установленных пакетов — nginx, apache, mysql
  • /run/systemd/system — нужен самому Systemd для динамически создаваемых юнитов
  • /etc/systemd/system — юниты, созданные администратором сервера

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

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

$ sudo systemctl start application.service

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

$ sudo systemctl stop application.service

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

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

$ sudo systemctl restart application.service

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

$ sudo systemctl reload application.service

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

$ sudo systemctl reload-or-restart application.service

Добавление в автозагрузку

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

$ sudo systemctl enable application.service

Это команда создаем символическую ссылку в директории /etc/systemd/system на файл в директории /lib/systemd/system .

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

$ sudo systemctl disable application.service

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

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

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

$ systemctl status application.service

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

$ systemctl status nginx ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2020-01-06 10:15:31 EET; 4min 3s ago Docs: man:nginx(8) Process: 677 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 639 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 688 (nginx) Tasks: 2 (limit: 3542) CGroup: /system.slice/nginx.service ├─688 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; └─689 nginx: worker process янв 06 10:15:30 ubuntu-lemp systemd[1]: Starting A high performance web server and a reverse proxy server. янв 06 10:15:31 ubuntu-lemp systemd[1]: nginx.service: Failed to parse PID from file /run/nginx.pid: Invalid argumen янв 06 10:15:31 ubuntu-lemp systemd[1]: Started A high performance web server and a reverse proxy server.

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

$ systemctl is-active application.service
$ systemctl is-enabled application.service
$ systemctl is-failed application.service

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

Читайте также:  Как установить powerpoint на линукс

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

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

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

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

$ systemctl list-units UNIT LOAD ACTIVE SUB DESCRIPTION --------------------------------------------------------------------------------------------------------------------- sys-devices-pci0000:00-0000:00:03.0-net-enp0s3.device loaded active plugged 82540EM Gigabit Ethernet C sys-devices-pci0000:00-0000:00:05.0-sound-card0.device loaded active plugged 82801AA AC'97 Audio Contro . phpsessionclean.timer loaded active waiting Clean PHP session files ev systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 178 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'.

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

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

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

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

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

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

$ systemctl list-units --all --state=inactive

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

$ systemctl list-units --type=service

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

$ systemctl list-units --type=service --state=not-found UNIT LOAD ACTIVE SUB DESCRIPTION ----------------------------------------------------------------------------------------- ● auditd.service not-found inactive dead auditd.service ● connman.service not-found inactive dead connman.service ● console-screen.service not-found inactive dead console-screen.service ● festival.service not-found inactive dead festival.service ● kbd.service not-found inactive dead kbd.service ● oem-config.service not-found inactive dead oem-config.service ● resolvconf.service not-found inactive dead resolvconf.service ● sssd.service not-found inactive dead sssd.service ● systemd-sysusers.service not-found inactive dead systemd-sysusers.service ● systemd-update-done.service not-found inactive dead systemd-update-done.service ● systemd-vconsole-setup.service not-found inactive dead systemd-vconsole-setup.service LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 11 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'.

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

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

$ systemctl list-unit-files UNIT FILE STATE ---------------------------------------------------- proc-sys-fs-binfmt_misc.automount static -.mount generated dev-hugepages.mount static . snapd.snap-repair.timer enabled systemd-tmpfiles-clean.timer static ureadahead-stop.timer static 337 unit files listed.

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

Читайте также:  Rebooting server in linux

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

  • 1С:Предприятие (31)
  • API (29)
  • Bash (43)
  • CLI (99)
  • CMS (139)
  • CSS (50)
  • Frontend (75)
  • HTML (66)
  • JavaScript (150)
  • Laravel (72)
  • Linux (146)
  • MySQL (76)
  • PHP (125)
  • React.js (66)
  • SSH (27)
  • Ubuntu (68)
  • Web-разработка (509)
  • WordPress (73)
  • Yii2 (69)
  • БазаДанных (95)
  • Битрикс (66)
  • Блог (29)
  • Верстка (43)
  • ИнтернетМагаз… (84)
  • КаталогТоваров (87)
  • Класс (30)
  • Клиент (27)
  • Ключ (28)
  • Команда (68)
  • Компонент (60)
  • Конфигурация (62)
  • Корзина (32)
  • ЛокальнаяСеть (28)
  • Модуль (34)
  • Навигация (31)
  • Настройка (140)
  • ПанельУправле… (29)
  • Плагин (33)
  • Пользователь (26)
  • Практика (99)
  • Сервер (74)
  • Событие (27)
  • Теория (105)
  • Установка (66)
  • Файл (47)
  • Форма (58)
  • Фреймворк (192)
  • Функция (36)
  • ШаблонСайта (68)

Источник

Linux Service unexpectedly died

Running Ubuntu 17.04, I’d like to have a systemctl service which oversees a main bash script, where three programs (here substituted by dummy script foo_script tagged with an argument) run under an endless loop (because of possible program crashes). The main script, foo_main.sh , works correctly if called from a command line; but the service I’m trying to set up from it crashes soon. File foo_script.sh :

#!/bin/bash echo "FooScripting "$1 >> "foo.d/"$1 
#!/bin/bash nLoop=0 prgName=$1 prgArg=$2 echo " $" loop >>" while : do let nLoop=nLoop+1 echo " $" >>" $ "./"$ $ sleep 1 done echo " << END of "$$" loop >>" 
#!/bin/bash echo "foo_main start in "$ ./loop.sh "foo_script.sh" "fb" & sleep 2 ./loop.sh "foo_script.sh" "gc" & ./loop.sh "foo_script.sh" "gb" & echo "foo_main end" 
[Unit] Description = Foo Daemon After = network.target [Service] Type = simple # User = > # PIDFile=/var/food.pid WorkingDirectory = /home/john/bin ExecStart = /home/john/bin/foo_main.sh # ExecStop = killall loop.sh # ExecReload = killall loop.sh && /home/john/bin/foo_main.sh # Restart = on-abort [Install] WantedBy = multi-user.target

What I obtain from every sudo systemctl status food.service (after a start ofc) is almost the same output

● food.service — Foo Daemon Loaded: loaded (/etc/systemd/system/food.service; disabled; vendor preset: enabled) Active: inactive (dead) Sep 28 14:54:30 john-host systemd[1]: Started Foo Daemon. Sep 28 14:54:30 john-host foo_main.sh[7376]: foo_main script start in /home/john/bin Sep 28 14:54:30 john-host foo_main.sh[7376]: > Sep 28 14:54:30 john-host foo_main.sh[7376]: > 1 Sep 28 14:54:31 john-host foo_main.sh[7376]: > 2 Sep 28 14:54:32 john-host foo_main.sh[7376]: foo_main script end Sep 28 15:24:30 john-host foo_main.sh[7921]: > Sep 28 15:24:30 john-host foo_main.sh[7921]: > Sep 28 15:24:30 john-host foo_main.sh[7921]: > 1 Sep 28 15:24:30 john-host foo_main.sh[7921]: > 1

Источник

Оцените статью
© 2023 Posetke
Adblock
detector