[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"/ru/kb/how-to/vps/systemctl-upravlenie-servisami-i-yunitamiKbData":3},{"page":4,"pages":161,"recommendedPages":162,"category":69,"categoryTree":69,"total":15,"currentOrder":190,"activeManualCategoryId":69,"tag":-1},{"route":5,"uuid":8,"title":9,"excerpt":10,"content":11,"view_count":12,"published_at":13,"modified_at":13,"like":14,"category":17,"hero_image":62,"seo_metadata":63,"schema_org_metadata":67,"open_graph_metadata":70,"sections":71,"tags":152,"breadcrumbs":153,"images":160},{"language":6,"path":7},"ru","/kb/how-to/vps/systemctl-upravlenie-servisami-i-yunitami","eea004ca-c0b6-ea33-427e-ef0ad77faade","Systemctl: управление сервисами и юнитами Systemd","Запустить программу в фоне, обеспечить ее автоматический запуск после перезагрузки сервера, разобраться, почему она перестала отвечать, – все эти задачи на Линукс-сервере решает systemctl, штатный инструмент управления службами (сервисами). Он работает во всех операционных системах с systemd: Ubuntu, Debian, AlmaLinux, Rocky Linux.","\n\u003Cp>Запустить программу в фоне, обеспечить ее автоматический запуск после перезагрузки сервера, разобраться, почему она перестала отвечать, – все эти задачи на Линукс-сервере решает \u003Ccode>systemctl\u003C/code>, штатный инструмент управления службами (сервисами). Он работает во всех \u003Ca href=\"https://beget.com/ru/cloud/marketplace/category/operating-system?utm_source=kb&utm_medium=article&utm_campaign=systemctl&utm_content=marketplace_operating_system\">операционных системах\u003C/a> с systemd: Ubuntu, Debian, AlmaLinux, Rocky Linux. Логи служб показывает соседняя утилита \u003Ccode>journalctl\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>В статье разберем, как устроен systemd, где используется, какие команды нужны для повседневной работы с VPS, как читать вывод \u003Ccode>systemctl status\u003C/code> и как оформить собственное приложение как службу.\u003C/p>\n\n\n\n\u003Cp>Примеры в статье приведены для \u003Ca href=\"https://beget.com/ru/cloud/marketplace/ubuntu-24-04?utm_source=kb&utm_medium=article&utm_campaign=systemctl&utm_content=marketplace_ubuntu_24_04\">Ubuntu 24.04 LTS\u003C/a> (systemd 255). В других дистрибутивах команды те же, но могут отличаться имена служб и детали вывода. Чтобы выполнять команды, \u003Ca href=\"https://beget.com/ru/kb/how-to/ssh/kak-podklyuchitsya-po-ssh-iz-windows?utm_source=kb&utm_medium=article&utm_campaign=systemctl&utm_content=kb_ssh\">подключитесь к серверу по SSH\u003C/a>.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-ustroen-systemd\">Как устроен systemd\u003C/h2>\n\n\n\n\u003Cp>Если упростить, загрузка сервера выглядит так: загрузчик запускает ядро Linux, ядро инициализирует оборудование и запускает первый пользовательский процесс, который отвечает за дальнейшую загрузку системы. В большинстве современных дистрибутивов этим процессом является \u003Ccode>systemd\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Процесс \u003Ccode>systemd\u003C/code> получает номер 1 (\u003Ccode>PID 1\u003C/code>) и работает до выключения сервера. Он монтирует файловые системы, поднимает сеть и запускает системные службы с учетом зависимостей между ними и заданного порядка. Независимые службы запускаются параллельно, поэтому система загружается быстрее.\u003C/p>\n\n\n\n\u003Cp>Кроме того, \u003Ccode>systemd\u003C/code> следит за состоянием запущенных служб и может перезапустить “упавшую” службу, если это предусмотрено ее настройками.\u003C/p>\n\n\n\n\u003Ch2 id=\"chto-delaet-systemctl\">Что делает systemctl\u003C/h2>\n\n\n\n\u003Cp>\u003Ccode>systemctl\u003C/code> – основная утилита для управления \u003Ccode>systemd\u003C/code>. Сама она службы не запускает и не останавливает: она передает \u003Ccode>systemd\u003C/code> запрос, например, на запуск или перезапуск службы, а действие выполняет \u003Ccode>systemd\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Настройки юнитов \u003Ccode>systemd\u003C/code> хранит в памяти. Поэтому, если изменить файл юнита, \u003Ccode>systemd\u003C/code> не заметит изменений, пока его не попросить перечитать конфигурацию командой \u003Ccode>systemctl daemon-reload\u003C/code>. \u003C/p>\n\n\n\n\u003Ch2 id=\"yunity-to-chem-upravlyaet-systemd\">Юниты: то, чем управляет systemd\u003C/h2>\n\n\n\n\u003Cp>Объекты, которыми управляет \u003Ccode>systemd\u003C/code>, называются юнитами (unit). Тип юнита определяется суффиксом его имени. Основные типы:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Cstrong>.service\u003C/strong> – служба, например, \u003Ccode>nginx.service\u003C/code>. Так оформляют веб-серверы, базы данных и другие приложения, которые работают в фоне.\u003C/li>\u003Cli>\u003Cstrong>.timer\u003C/strong> – таймер, который запускает связанный с ним юнит по расписанию или через заданный интервал. Это альтернатива cron: задание описывается юнитом, а результат его выполнения виден в журнале. Например, в Ubuntu и Debian при установке certbot из репозитория \u003Ccode>certbot.timer\u003C/code> дважды в сутки запускает службу, которая проверяет, не пора ли продлить TLS-сертификаты. Если certbot установлен через snap, таймер называется \u003Ccode>snap.certbot.renew.timer\u003C/code>.\u003C/li>\u003Cli>\u003Cstrong>.socket\u003C/strong> – сетевой сокет, Unix-сокет или FIFO. \u003Ccode>systemd\u003C/code> может сам слушать сокет и запускать связанную службу при первом обращении к нему.\u003C/li>\u003Cli>\u003Cstrong>.target\u003C/strong> – цель, которая объединяет юниты и задает определенное состояние системы. Например, \u003Ccode>multi-user.target\u003C/code> соответствует многопользовательскому режиму без графической оболочки – обычному режиму работы сервера.\u003C/li>\u003Cli>\u003Cstrong>.mount\u003C/strong> – точка монтирования файловой системы.\u003C/li>\u003Cli>\u003Cstrong>.path\u003C/strong> – наблюдение за файлом или каталогом: когда выполняется заданное условие, например, файл появился или изменился, \u003Ccode>systemd\u003C/code> запускает связанную службу.\u003C/li>\u003C/ul>\n\n\n\n\u003Cp>Есть и другие типы – \u003Cstrong>.device\u003C/strong>, \u003Cstrong>.swap\u003C/strong>, \u003Cstrong>.automount\u003C/strong>, \u003Cstrong>.slice\u003C/strong>, \u003Cstrong>.scope\u003C/strong>, – но при администрировании VPS с ними приходится работать редко.\u003C/p>\n\n\n\n\u003Cp>Чаще всего администратор работает со службами, поэтому в большинстве примеров ниже используется служба веб-сервера nginx. С юнитами других типов команды те же, только имя нужно указывать с суффиксом, например, \u003Ccode>systemctl status certbot.timer\u003C/code>. Если суффикс не указан, \u003Ccode>systemctl\u003C/code> считает, что речь идет о службе, и добавляет \u003Cstrong>.service\u003C/strong> сам.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-zapustit-i-ostanovit-sluzhbu\">Как запустить и остановить службу\u003C/h2>\n\n\n\n\u003Cp>Для управления службами нужны права суперпользователя, поэтому в примерах используется \u003Ccode>sudo\u003C/code>. Смотреть состояние службы можно и без них, но тогда в выводе \u003Ccode>systemctl status\u003C/code> могут не отобразиться строки журнала. Чтобы их увидеть, выполните команду через \u003Ccode>sudo\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Запустить службу можно командой \u003Ccode>sudo systemctl start <имя_службы>\u003C/code>. Например: \u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl start nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Для остановки используется \u003Ccode>sudo systemctl stop <имя_службы>\u003C/code>. Например: \u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl stop nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Команды \u003Ccode>start\u003C/code> и \u003Ccode>stop\u003C/code> меняют только текущее состояние службы. После перезагрузки VPS служба запустится, только если для нее включен автозапуск или она нужна другому юниту. Как включить автозапуск – в разделе «Как включить и отключить автозапуск службы».\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-alert alert-block alert-block-info\">\u003Cdiv class=\"alert-block-title\">Обратите внимание!\u003C/div>\u003Cdiv class=\"alert-block-content\">В Ubuntu и Debian пакеты со службами обычно сразу включают автозапуск и запускают службу при установке. Поэтому, например, nginx начинает работать сразу после \u003Ccode>apt install nginx\u003C/code>.\u003C/div>\u003C/div>\n\n\n\n\u003Ch2 id=\"kak-perezapustit-sluzhbu\">Как перезапустить службу\u003C/h2>\n\n\n\n\u003Cp>Команда \u003Ccode>restart\u003C/code> останавливает службу и запускает ее заново. Если служба была остановлена, команда просто запустит ее:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl restart nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Перезапуск нужен, чтобы применить изменения, которые требуют повторного запуска службы, или восстановить ее работу после сбоя. Во время перезапуска служба недоступна, а активные соединения обрываются.\u003C/p>\n\n\n\n\u003Ch2 id=\"reload-perechitat-konfiguraciyu-bez-perezapuska\">Reload: перечитать конфигурацию без перезапуска\u003C/h2>\n\n\n\n\u003Cp>Многие службы умеют применять новую конфигурацию без остановки. Для этого используйте команду:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl reload nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Если в юните задана команда перезагрузки конфигурации (параметр \u003Ccode>ExecReload=\u003C/code>), \u003Ccode>systemd\u003C/code> выполняет ее. Основной процесс службы продолжает работать, и соединения не обрываются. Например, nginx при reload запускает новые рабочие процессы с обновленной конфигурацией, а старые завершают обработку текущих запросов и останавливаются.\u003C/p>\n\n\n\n\u003Cp>Если служба не поддерживает \u003Ccode>reload\u003C/code>, команда завершится ошибкой. Например, так выглядит попытка перезагрузить конфигурацию cron в Ubuntu:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>Failed to reload cron.service: Job type reload is not applicable for unit cron.service.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>\u003Ccode>systemctl reload\u003C/code> перечитывает только конфигурацию самого приложения, например, файлы в \u003Ccode>/etc/nginx/\u003C/code> для nginx. Если вы изменили файл юнита службы, \u003Ccode>systemctl\u003C/code> \u003Ccode>reload\u003C/code> эти изменения не применит: выполните \u003Ccode>sudo systemctl daemon-reload\u003C/code>, а затем перезапустите службу. \u003C/p>\n\n\n\n\u003Ch2 id=\"universalnaya-komanda-reload-or-restart\">Универсальная команда reload-or-restart\u003C/h2>\n\n\n\n\u003Cp>Если вы не знаете, поддерживает ли служба \u003Ccode>reload\u003C/code>, используйте \u003Ccode>systemctl\u003C/code> \u003Ccode>reload-or-restart\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl reload-or-restart nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Команда перечитывает конфигурацию, если юнит это поддерживает, а в противном случае перезапускает службу. Если служба остановлена, команда ее запустит.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-vklyuchit-i-otklyuchit-avtozapusk-sluzhby\">Как включить и отключить автозапуск службы\u003C/h2>\n\n\n\n\u003Cp>Чтобы \u003Ccode>systemd\u003C/code> запускал службу при загрузке VPS, выполните:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl enable nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Команда создает символические ссылки, которые описаны в секции \u003Ccode>[Install]\u003C/code> файла юнита, – так служба становится частью загрузки системы.\u003C/p>\n\n\n\n\u003Cp>Отключите автозапуск командой:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl disable nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>\u003Ccode>systemctl enable\u003C/code> не запускает службу сразу, а \u003Ccode>systemctl disable\u003C/code> не останавливает уже работающую. Чтобы сделать и то и другое одной командой, добавьте флаг \u003Ccode>--now\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl enable --now nginx\nsudo systemctl disable --now nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Проверьте, включен ли автозапуск:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>systemctl is-enabled nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Основные ответы команды:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Ccode>enabled\u003C/code> – автозапуск включен;\u003C/li>\u003Cli>\u003Ccode>disabled\u003C/code> – автозапуск отключен;\u003C/li>\u003Cli>\u003Ccode>masked\u003C/code> – юнит заблокирован, запустить его нельзя;\u003C/li>\u003Cli>\u003Ccode>static\u003C/code> – у юнита нет секции [Install], поэтому включить его нельзя; такие юниты запускаются как зависимости других юнитов или по таймеру;\u003C/li>\u003Cli>\u003Ccode>enabled-runtime\u003C/code> – автозапуск включен до следующей перезагрузки (командой \u003Ccode>enable --runtime\u003C/code>).\u003C/li>\u003C/ul>\n\n\n\n\u003Cp>Полный список состояний приведен в документации \u003Ccode>systemctl\u003C/code> в описании команды \u003Ccode>is-enabled\u003C/code>.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-zablokirovat-i-razblokirovat-sluzhbu-mask-i-unmask\">Как заблокировать и разблокировать службу: mask и unmask\u003C/h2>\n\n\n\n\u003Cp>Команда \u003Ccode>disable\u003C/code> отключает только автозапуск: службу по-прежнему можно запустить вручную, и ее может запустить другой юнит как зависимость. Чтобы запретить любой запуск, используйте маскирование:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl mask apache2\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>\u003Ccode>systemd\u003C/code> создаст в директории \u003Ccode>/etc/systemd/system/\u003C/code> ссылку \u003Ccode>apache2.service\u003C/code>, указывающую на \u003Ccode>/dev/null\u003C/code>. Пока маска действует, службу нельзя запустить ни вручную, ни через зависимости других юнитов:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>Failed to start apache2.service: Unit apache2.service is masked.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Команда \u003Ccode>mask\u003C/code> не останавливает уже работающую службу. Чтобы замаскировать и сразу остановить ее, добавьте \u003Ccode>--now\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl mask --now apache2\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Снимите блокировку командой:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl unmask apache2\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>\u003Ccode>systemctl unmask\u003C/code> удаляет ссылку на \u003Ccode>/dev/null\u003C/code> и возвращает юнит в состояние, в котором он был до маскирования. Если автозапуск был включен, он сохранится, и служба запустится при следующей загрузке. Проверьте это командой \u003Ccode>systemctl is-enabled apache2\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Маскирование применяется к службам, установленным из пакетов. Для собственной службы, файл которой вы создали в \u003Ccode>/etc/systemd/system/\u003C/code>, команда \u003Ccode>mask\u003C/code> не сработает: ссылку на \u003Ccode>/dev/null\u003C/code> systemd создает в этом же каталоге, а файл с таким именем там уже есть:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>Failed to mask unit: File /etc/systemd/system/myapp.service already exists.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Если собственная служба больше не нужна, можно остановить ее, отключить автозапуск и удалить файл юнита:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl disable --now myapp\nsudo rm /etc/systemd/system/myapp.service\nsudo systemctl daemon-reload\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Блокируйте юниты осторожно: если заблокировать юнит, от которого зависят другие службы или загрузка системы, они перестанут работать.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-uznat-sostoyanie-sluzhby\">Как узнать состояние службы\u003C/h2>\n\n\n\n\u003Cp>Основная команда для диагностики – \u003Ccode>status\u003C/code>. Она показывает состояние службы, ее процессы и последние записи журнала:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>systemctl status nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Пример вывода:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>● nginx.service - A high performance web server and a reverse proxy server\n     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)\n     Active: active (running) since Fri 2026-09-18 12:22:58 UTC; 8min ago\n       Docs: man:nginx(8)\n   Main PID: 1534 (nginx)\n      Tasks: 2 (limit: 2315)\n     Memory: 1.7M (peak: 3.9M)\n        CPU: 191ms\n     CGroup: /system.slice/nginx.service\n             ├─1534 \"nginx: master process /usr/sbin/nginx -g daemon on; master_process on;\"\n             └─1537 \"nginx: worker process\"\n\nSep 18 12:22:58 ugwhktphat systemd[1]: Starting nginx.service - A high performance web server and a reverse proxy server...\nSep 18 12:22:58 ugwhktphat systemd[1]: Started nginx.service - A high performance web server and a reverse proxy server.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Что означает каждая строка:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Cstrong>значок в начале строки\u003C/strong> – визуальный индикатор состояния юнита;\u003C/li>\u003Cli>\u003Cstrong>Loaded\u003C/strong> – загружен ли юнит, путь к его файлу, состояние автозапуска и \u003Ccode>preset\u003C/code> – настройка автозапуска по умолчанию, которую задает дистрибутив;\u003C/li>\u003Cli>\u003Cstrong>Active\u003C/strong> – текущее состояние юнита и время, с которого он в нем находится;\u003C/li>\u003Cli>\u003Cstrong>Docs\u003C/strong> – ссылка на документацию из настроек юнита;\u003C/li>\u003Cli>\u003Cstrong>Main PID\u003C/strong> – идентификатор главного процесса службы;\u003C/li>\u003Cli>\u003Cstrong>Tasks\u003C/strong> – число процессов и потоков службы и в скобках их максимальное количество;\u003C/li>\u003Cli>\u003Cstrong>Memory\u003C/strong> – объем памяти, который использует служба, и пиковое потребление;\u003C/li>\u003Cli>\u003Cstrong>CPU\u003C/strong> – процессорное время, израсходованное с момента запуска;\u003C/li>\u003Cli>\u003Cstrong>CGroup\u003C/strong> – контрольная группа, через которую \u003Ccode>systemd\u003C/code> учитывает процессы службы, и дерево этих процессов;\u003C/li>\u003Cli>\u003Cstrong>строки внизу\u003C/strong> – последние записи журнала, связанные с юнитом.\u003C/li>\u003C/ul>\n\n\n\n\u003Cp>В примере служба nginx загружена и настроена на автозапуск (\u003Ccode>enabled\u003C/code>), а \u003Ccode>preset: enabled\u003C/code> указывает, что автозапуск включен и по умолчанию. Служба работает (\u003Ccode>active (running)\u003C/code>) с 12:22:58 UTC. Главный процесс имеет \u003Ccode>PID 1534\u003C/code>, всего служба использует два процесса. Пиковое потребление памяти составило 3,9 МБ, а процессорное время – 191 мс. Внизу журнала видны сообщения об успешном запуске nginx. \u003C/p>\n\n\n\n\u003Ch3 id=\"chto-pokazyvaet-pole-active\">Что показывает поле Active\u003C/h3>\n\n\n\n\u003Cp>Основные варианты:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Ccode>active (running)\u003C/code> – служба запущена, ее процесс работает;\u003C/li>\u003Cli>\u003Ccode>active (exited)\u003C/code> – юнит активен, хотя его процесс уже завершился. Так выглядят службы, которые выполняют разовую задачу при загрузке (\u003Ccode>Type=oneshot\u003C/code> с параметром \u003Ccode>RemainAfterExit=yes\u003C/code>), например, \u003Ccode>ufw.service\u003C/code>;\u003C/li>\u003Cli>\u003Ccode>active (waiting)\u003C/code> – так выглядит работающий таймер, который ждет следующего срабатывания;\u003C/li>\u003Cli>\u003Ccode>inactive (dead)\u003C/code> – юнит не запущен;\u003C/li>\u003Cli>\u003Ccode>failed\u003C/code> – юнит завершился с ошибкой или не смог запуститься. В скобках указывается причина, например, \u003Ccode>failed (Result: exit-code)\u003C/code>;\u003C/li>\u003Cli>\u003Ccode>activating (auto-restart)\u003C/code> – служба упала, и systemd ждет паузу перед повторным запуском.\u003C/li>\u003C/ul>\n\n\n\n\u003Ch3 id=\"korotkie-proverki\">Короткие проверки\u003C/h3>\n\n\n\n\u003Cp>Когда подробный вывод не нужен, используйте команды с кратким ответом:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>systemctl is-active nginx\nsystemctl is-enabled nginx\nsystemctl is-failed nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cul>\u003Cli>\u003Ccode>is-active\u003C/code> выводит состояние юнита: \u003Ccode>active\u003C/code>, \u003Ccode>inactive\u003C/code>, \u003Ccode>failed\u003C/code> и др.;\u003C/li>\u003Cli>\u003Ccode>is-enabled\u003C/code> выводит состояние автозапуска: \u003Ccode>enabled\u003C/code>, \u003Ccode>disabled\u003C/code>, \u003Ccode>masked\u003C/code>, \u003Ccode>static\u003C/code> и др.;\u003C/li>\u003Cli>\u003Ccode>is-failed\u003C/code> выводит то же состояние, что и \u003Ccode>is-active\u003C/code>, – для работающей службы это \u003Ccode>active\u003C/code>. Находится ли юнит в состоянии сбоя, команда сообщает кодом возврата: \u003Ccode>0\u003C/code> – юнит в состоянии \u003Ccode>failed\u003C/code>, любое другое значение – нет. Посмотреть код возврата можно командой \u003Ccode>echo $?\u003C/code> сразу после проверки.\u003C/li>\u003C/ul>\n\n\n\n\u003Cp>Эти команды удобно использовать в скриптах: с флагом \u003Ccode>--quiet\u003C/code> они ничего не выводят и сообщают результат только кодом возврата. Например, так можно запустить nginx, если он не работает:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>if ! systemctl is-active --quiet nginx; then\n  sudo systemctl start nginx\nfi\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Ch2 id=\"kak-posmotret-spisok-sluzhb\">Как посмотреть список служб\u003C/h2>\n\n\n\n\u003Cp>Если на сервере возникла проблема и неизвестно, какой юнит ее вызывает, начните с поиска сбоев:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>systemctl --failed\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Команда показывает все юниты в состоянии \u003Ccode>failed\u003C/code> – не только службы. Чтобы оставить в списке только службы, добавьте фильтр по типу:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>systemctl --failed --type=service\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Список служб, загруженных в systemd, выводит команда:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>systemctl list-units --type=service\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>По умолчанию в нем только работающие службы, службы с ожидающими заданиями и сбойные. Чтобы увидеть и остановленные, добавьте \u003Ccode>--all\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>systemctl list-units --type=service --all\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Чтобы посмотреть все установленные файлы служб и состояние их автозапуска, используйте:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>systemctl list-unit-files --type=service\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Команда показывает все файлы служб, которые есть в системе, – в том числе тех, которые ни разу не запускались, – и их состояние: \u003Ccode>enabled\u003C/code>, \u003Ccode>disabled\u003C/code>, \u003Ccode>static\u003C/code> или \u003Ccode>masked\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Разница между командами: \u003Ccode>list-units\u003C/code> показывает юниты, загруженные в память systemd, и их текущее состояние, а \u003Ccode>list-unit-files\u003C/code> – файлы юнитов на диске и настройку их автозапуска.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-posmotret-logi-sluzhby-journalctl\">Как посмотреть логи службы: journalctl\u003C/h2>\n\n\n\n\u003Cp>Сообщения служб собирает системный журнал \u003Ccode>systemd-journald\u003C/code>. Журнал хранится в бинарном формате, поэтому для его просмотра используется утилита \u003Ccode>journalctl\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Посмотрите журнал конкретной службы с помощью флага \u003Ccode>-u\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo journalctl -u nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Записей может быть много. Чтобы сразу перейти к последним, добавьте \u003Ccode>-e\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo journalctl -u nginx -e\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Чтобы следить за новыми записями в реальном времени, используйте \u003Ccode>-f\u003C/code> – это аналог \u003Ccode>tail -f\u003C/code>. Для выхода нажмите \u003Ccode>Ctrl+C\u003C/code>:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo journalctl -u nginx -f\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Вывод можно ограничить по времени. Показать записи за сегодня, начиная с полуночи:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo journalctl -u nginx --since today\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Показать записи за последний час:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo journalctl -u nginx --since \"1 hour ago\"\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Если служба не запустилась, \u003Ccode>systemd\u003C/code> предлагает посмотреть журнал командой вида \u003Ccode>journalctl -xeu nginx.service\u003C/code>. В ней \u003Ccode>-u\u003C/code> выбирает юнит, \u003Ccode>-e\u003C/code> переходит к последним записям, а \u003Ccode>-x\u003C/code> добавляет к сообщениям пояснения из каталога сообщений \u003Ccode>systemd\u003C/code>, если они есть:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo journalctl -xeu nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Для диагностики удобно сочетать обе утилиты: \u003Ccode>systemctl status\u003C/code> показывает текущее состояние службы и несколько последних строк журнала, а \u003Ccode>journalctl\u003C/code> – всю историю с фильтрами по времени и в реальном времени.\u003C/p>\n\n\n\n\u003Cp>По журналу часто можно определить причину сбоя: ошибку в конфигурации, отсутствующий файл или занятый порт. Но в журнал попадает только то, что служба пишет в стандартный вывод или системный журнал. Многие серверные программы ведут собственные логи. Например, nginx записывает ошибки и запросы в \u003Ccode>/var/log/nginx/error.log\u003C/code> и \u003Ccode>/var/log/nginx/access.log\u003C/code>, поэтому в \u003Ccode>journalctl -u nginx\u003C/code> будут в основном сообщения о запуске и остановке, а также ошибки, возникшие при старте. Подробнее о логах – в статье “\u003Ca href=\"https://beget.com/ru/kb/how-to/vps/prosmotr-i-nastrojka-logov-linux-na-ubuntu-debian-i-centos?utm_source=kb&utm_medium=article&utm_campaign=systemctl&utm_content=kb_nastrojka_logov\">Просмотр и настройка логов Linux\u003C/a>”. Логи systemctl – один из способов проверить работу служб и найти ошибки.\u003C/p>\n\n\n\n\u003Ch2 id=\"kak-oformit-svoe-prilozhenie-kak-sluzhbu\">Как оформить свое приложение как службу\u003C/h2>\n\n\n\n\u003Cp>Программы, установленные из пакетов, получают готовые файлы юнитов. Чтобы запускать через \u003Ccode>systemd\u003C/code> собственное приложение, например, на Node.js, Python или Go, для него нужно создать отдельный юнит.\u003C/p>\n\n\n\n\u003Cp>Файлы юнитов хранятся в двух основных каталогах:\u003C/p>\n\n\n\n\u003Cul>\u003Cli>\u003Ccode>/usr/lib/systemd/system/\u003C/code> – юниты из пакетов. Не редактируйте их: при обновлении пакета изменения будут перезаписаны;\u003C/li>\u003Cli>\u003Ccode>/etc/systemd/system/\u003C/code> – юниты администратора. Если имена совпадают, юнит из этого каталога имеет приоритет над юнитом из пакета.\u003C/li>\u003C/ul>\n\n\n\n\u003Ch3 id=\"podgotovka\">Подготовка\u003C/h3>\n\n\n\n\u003Cp>Для примера создадим службу для приложения на Node.js, которое лежит в каталоге \u003Ccode>/home/myappuser/myapp\u003C/code>.\u003C/p>\n\n\n\n\u003Col>\u003Cli>Создайте отдельного пользователя, от имени которого будет работать приложение. Запускать приложения от \u003Ccode>root\u003C/code> небезопасно:\u003C/li>\u003C/ol>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo useradd --system --create-home --shell /usr/sbin/nologin myappuser\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Col start=\"2\">\u003Cli>Узнайте полный путь к интерпретатору Node.js:\u003C/li>\u003C/ol>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>command -v node\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Ch3 id=\"fayl-yunita\">Файл юнита\u003C/h3>\n\n\n\n\u003Cp>Создайте файл:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo nano /etc/systemd/system/myapp.service\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Добавьте в него:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>[Unit]\nDescription=My Node.js application\nAfter=network.target\n\n[Service]\nUser=myappuser\nWorkingDirectory=/home/myappuser/myapp\nExecStart=/usr/bin/node /home/myappuser/myapp/index.js\nEnvironment=NODE_ENV=production\nRestart=on-failure\nRestartSec=5\n\n[Install]\nWantedBy=multi-user.target\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Файл состоит из трех секций.\u003C/p>\n\n\n\n\u003Col>\u003Cli>\u003Cstrong>\u003Ccode>[Unit]\u003C/code>\u003C/strong> – общая информация о юните и его зависимостях. \u003Ccode>Description\u003C/code> – описание, которое отображается, например, в выводе \u003Ccode>systemctl status\u003C/code>. \u003Ccode>After=network.target\u003C/code> задает только порядок: если обе цели запускаются вместе, служба стартует после инициализации сети.\u003C/li>\u003Cli>\u003Ccode>\u003Cstrong>[Service]\u003C/strong>\u003C/code> – параметры запуска:\u003C/li>\u003C/ol>\n\n\n\n\u003Cul>\u003Cli>\u003Ccode>User\u003C/code> – пользователь, от имени которого работает процесс;\u003C/li>\u003Cli>\u003Ccode>WorkingDirectory\u003C/code> – рабочий каталог процесса;\u003C/li>\u003Cli>\u003Ccode>ExecStart\u003C/code> – команда запуска. Systemd не использует переменную \u003Ccode>PATH\u003C/code> вашей сессии: без полного пути он ищет программу только в стандартных каталогах (\u003Ccode>/usr/local/bin\u003C/code>, \u003Ccode>/usr/bin\u003C/code> и др.). Поэтому надежнее всегда указывать абсолютный путь. Относительные пути вроде \u003Ccode>./index.js\u003C/code> не допускаются;\u003C/li>\u003Cli>\u003Ccode>Environment\u003C/code> – переменные окружения;\u003C/li>\u003Cli>\u003Ccode>Restart=on-failure – systemd\u003C/code> перезапустит службу, если процесс завершится с ошибкой;\u003C/li>\u003Cli>\u003Ccode>RestartSec=5\u003C/code> – пауза перед перезапуском. По умолчанию она составляет всего 100 мс, и при постоянно падающем приложении systemd быстро исчерпает лимит попыток (см. ошибку \u003Ccode>Start request repeated too quickly\u003C/code>).\u003C/li>\u003C/ul>\n\n\n\n\u003Col start=\"3\">\u003Cli>\u003Cstrong>\u003Ccode>[Install]\u003C/code>\u003C/strong> – настройки автозапуска, \u003Ccode>wantedBy=multi-user.target\u003C/code> указывает, к какой цели привязать службу при выполнении \u003Ccode>systemctl enable\u003C/code>.\u003C/li>\u003C/ol>\n\n\n\n\u003Ch3 id=\"zapusk\">Запуск\u003C/h3>\n\n\n\n\u003Cp>Сообщите systemd о новом файле:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl daemon-reload\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Включите автозапуск и сразу запустите службу:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl enable --now myapp\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Проверьте, что служба работает:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>systemctl status myapp\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Теперь приложением можно управлять теми же командами, что и любой другой службой: \u003Ccode>start\u003C/code>, \u003Ccode>stop\u003C/code>, \u003Ccode>restart\u003C/code>, \u003Ccode>enable\u003C/code>, \u003Ccode>disable\u003C/code>. Команда \u003Ccode>systemctl reload\u003C/code> для этого юнита не сработает: в нем не задан параметр \u003Ccode>ExecReload=\u003C/code>.\u003C/p>\n\n\n\n\u003Ch2 id=\"chastye-oshibki\">Частые ошибки\u003C/h2>\n\n\n\n\u003Ch3 id=\"unit-not-found\">Unit not found\u003C/h3>\n\n\n\n\u003Cp>Пример ошибки при запуске: \u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>Failed to start myapp.service: Unit myapp.service not found.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>При \u003Ccode>systemctl status\u003C/code> сообщение выглядит так:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>Unit myapp.service could not be found.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>\u003Ccode>systemd\u003C/code> не нашел юнит с таким именем. Проверьте название службы и наличие файла:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>systemctl list-unit-files | grep -i myapp\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Если юнит создан вручную, убедитесь, что файл лежит в \u003Ccode>/etc/systemd/system/\u003C/code> и имеет суффикс \u003Ccode>.service\u003C/code>, и выполните \u003Ccode>sudo systemctl daemon-reload\u003C/code>.\u003C/p>\n\n\n\n\u003Ch3 id=\"pravka-fayla-yunita-ne-primenilas\">Правка файла юнита не применилась\u003C/h3>\n\n\n\n\u003Cp>\u003Ccode>systemctl\u003C/code> выводит предупреждение:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>Warning: The unit file, source configuration file or drop-ins of myapp.service changed on disk. Run 'systemctl daemon-reload' to reload units.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Перечитайте файлы юнитов и перезапустите службу\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl daemon-reload\nsudo systemctl restart myapp\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Ch3 id=\"neither-a-valid-executable-name-nor-an-absolute-path\">Neither a valid executable name nor an absolute path\u003C/h3>\n\n\n\n\u003Cp>При запуске или перезапуске службы появляется ошибка:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>Failed to restart myapp.service: Unit myapp.service has a bad unit file setting.\nSee system logs and 'systemctl status myapp.service' for details.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>В строке \u003Ccode>Loaded\u003C/code> вывода \u003Ccode>systemctl status\u003C/code> указано \u003Ccode>bad-setting\u003C/code>, а в журнале (\u003Ccode>sudo journalctl -u myapp\u003C/code>) – причина:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>/etc/systemd/system/myapp.service:8: Neither a valid executable name nor an absolute path: ./myapp\nmyapp.service: Unit configuration has fatal error, unit will not be started.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>В \u003Ccode>ExecStart\u003C/code> указан относительный путь. Укажите абсолютный, например, \u003Ccode>ExecStart=/home/myappuser/myapp/myapp\u003C/code>, проверьте, что у файла есть право на выполнение, и выполните \u003Ccode>sudo systemctl daemon-reload\u003C/code>.\u003C/p>\n\n\n\n\u003Cp>Если служба уже работала до правки, ее процесс продолжит работать со старыми настройками: \u003Ccode>systemd\u003C/code> не остановит его, но и не перезапустит, пока ошибка не исправлена.\u003C/p>\n\n\n\n\u003Ch3 id=\"unit-is-masked\">Unit is masked\u003C/h3>\n\n\n\n\u003Cp>Пример ошибки: \u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>Failed to start nginx.service: Unit nginx.service is masked.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Служба заблокирована командой \u003Ccode>systemctl mask\u003C/code>. Снимите блокировку и запустите службу:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl unmask nginx\nsudo systemctl start nginx\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Ch3 id=\"start-request-repeated-too-quickly\">Start request repeated too quickly\u003C/h3>\n\n\n\n\u003Cp>В выводе \u003Ccode>systemctl status\u003C/code> указано \u003Ccode>Active: failed\u003C/code>, а в журнале есть строки:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>myapp.service: Scheduled restart job, restart counter is at 5.\nmyapp.service: Start request repeated too quickly.\nmyapp.service: Failed with result 'exit-code'.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Служба запускалась слишком часто – по умолчанию больше 5 раз за 10 секунд, – и \u003Ccode>systemd\u003C/code> перестал ее запускать. Найдите причину в журнале (\u003Ccode>sudo journalctl -u myapp -e\u003C/code>) и устраните ее. Затем сбросьте счетчик попыток и запустите службу:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>sudo systemctl reset-failed myapp\nsudo systemctl start myapp\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Ch3 id=\"job-type-reload-is-not-applicable\">Job type reload is not applicable\u003C/h3>\n\n\n\n\u003Cp>Пример ошибки:\u003C/p>\n\n\n\n\u003Cdiv class=\"wp-block-beget-code code-block\">\u003Cpre data-options=\"{"mode":""}\">\u003Ccode>Failed to reload myapp.service: Job type reload is not applicable for unit myapp.service.\u003C/code>\u003C/pre>\u003C/div>\n\n\n\n\u003Cp>Служба не поддерживает \u003Ccode>systemctl reload\u003C/code>. Используйте \u003Ccode>sudo systemctl restart myapp\u003C/code> или \u003Ccode>sudo systemctl reload-or-restart myapp\u003C/code>.\u003C/p>\n\n\n\n\u003Ch2 id=\"zaklyuchenie\">Заключение\u003C/h2>\n\n\n\n\u003Cp>С помощью \u003Ccode>systemctl\u003C/code> можно запускать, останавливать и перезапускать службы, настраивать их автозапуск и блокировать нежелательные службы, а вместе с \u003Ccode>journalctl\u003C/code> – находить причины сбоев. Для собственного приложения начните с минимального юнита из этой статьи и добавляйте параметры по мере необходимости.\u003C/p>\n\n\n\n\u003Cp>Если возникнут вопросы, напишите нам, пожалуйста, тикет из панели управления аккаунта (раздел “\u003Ca href=\"https://cp.beget.com/support?utm_source=kb&utm_medium=article&utm_campaign=systemctl&utm_content=cp_support\">Помощь и поддержка\u003C/a>”), а если вы захотите обсудить, что делает команда Systemctl, или просто пообщаться с коллегами по цеху и сотрудниками Beget – ждем вас в нашем\u003Ca href=\"https://t.me/beget_chat\"> сообществе\u003C/a> в Telegram.\u003C/p>\n",12,"2026-09-25T18:57:40.000Z",{"count":15,"liked":16},0,false,{"route":18,"title":20,"tags":21,"breadcrumbs":54,"uuid":55,"parent_uuid":56,"default_page_path":25,"seo_metadata":57},{"language":6,"path":19},"/kb/how-to/vps","VPS",[22,26,30,34,38,42,46,50],{"id":23,"title":20,"seo_metadata":24},"vps",{"title":25,"description":25,"header":25,"keywords":25},"",{"id":27,"title":28,"seo_metadata":29},"apache","Apache",{"title":25,"description":25,"header":25,"keywords":25},{"id":31,"title":32,"seo_metadata":33},"lets-encrypt","Let's Encrypt",{"title":25,"description":25,"header":25,"keywords":25},{"id":35,"title":36,"seo_metadata":37},"nginx","Nginx",{"title":25,"description":25,"header":25,"keywords":25},{"id":39,"title":40,"seo_metadata":41},"ssl","SSL",{"title":25,"description":25,"header":25,"keywords":25},{"id":43,"title":44,"seo_metadata":45},"vestacp","VestaCP",{"title":25,"description":25,"header":25,"keywords":25},{"id":47,"title":48,"seo_metadata":49},"perenos-sajta","Перенос сайта",{"title":25,"description":25,"header":25,"keywords":25},{"id":51,"title":52,"seo_metadata":53},"terminal","Терминал",{"title":25,"description":25,"header":25,"keywords":25},[],"957abe7d-4a90-1475-bfb0-6439507ed391","fa9a1354-631a-4206-df34-291f0db8f42a",{"title":58,"description":59,"header":60,"keywords":61},"VPS. Полезные статьи – Beget","Полезные статьи о VPS на сайте Beget","VPS. Полезные статьи","vps, вопрос ответ",{"src":25,"text":25},{"title":64,"description":65,"keywords":66},"Systemctl: управление сервисами и юнитами","Рассказываем, как  управлять сервисами и юнитами при помощи Systemctl⚡Руководство по тому, как работать с командой systemctl","самостоятельное управление службами Systemd, инструмент для управления сервисами и юнитами",{"faq":68,"how_to":69,"product":69},[],null,{},[72,76,79,82,85,88,91,94,97,100,103,107,110,113,116,119,122,125,128,131,134,137,140,143,146,149],{"level":73,"name":74,"anchor":75},1,"Как устроен systemd","kak-ustroen-systemd",{"level":73,"name":77,"anchor":78},"Что делает systemctl","chto-delaet-systemctl",{"level":73,"name":80,"anchor":81},"Юниты: то, чем управляет systemd","yunity-to-chem-upravlyaet-systemd",{"level":73,"name":83,"anchor":84},"Как запустить и остановить службу","kak-zapustit-i-ostanovit-sluzhbu",{"level":73,"name":86,"anchor":87},"Как перезапустить службу","kak-perezapustit-sluzhbu",{"level":73,"name":89,"anchor":90},"Reload: перечитать конфигурацию без перезапуска","reload-perechitat-konfiguraciyu-bez-perezapuska",{"level":73,"name":92,"anchor":93},"Универсальная команда reload-or-restart","universalnaya-komanda-reload-or-restart",{"level":73,"name":95,"anchor":96},"Как включить и отключить автозапуск службы","kak-vklyuchit-i-otklyuchit-avtozapusk-sluzhby",{"level":73,"name":98,"anchor":99},"Как заблокировать и разблокировать службу: mask и unmask","kak-zablokirovat-i-razblokirovat-sluzhbu-mask-i-unmask",{"level":73,"name":101,"anchor":102},"Как узнать состояние службы","kak-uznat-sostoyanie-sluzhby",{"level":104,"name":105,"anchor":106},2,"Что показывает поле Active","chto-pokazyvaet-pole-active",{"level":104,"name":108,"anchor":109},"Короткие проверки","korotkie-proverki",{"level":73,"name":111,"anchor":112},"Как посмотреть список служб","kak-posmotret-spisok-sluzhb",{"level":73,"name":114,"anchor":115},"Как посмотреть логи службы: journalctl","kak-posmotret-logi-sluzhby-journalctl",{"level":73,"name":117,"anchor":118},"Как оформить свое приложение как службу","kak-oformit-svoe-prilozhenie-kak-sluzhbu",{"level":104,"name":120,"anchor":121},"Подготовка","podgotovka",{"level":104,"name":123,"anchor":124},"Файл юнита","fayl-yunita",{"level":104,"name":126,"anchor":127},"Запуск","zapusk",{"level":73,"name":129,"anchor":130},"Частые ошибки","chastye-oshibki",{"level":104,"name":132,"anchor":133},"Unit not found","unit-not-found",{"level":104,"name":135,"anchor":136},"Правка файла юнита не применилась","pravka-fayla-yunita-ne-primenilas",{"level":104,"name":138,"anchor":139},"Neither a valid executable name nor an absolute path","neither-a-valid-executable-name-nor-an-absolute-path",{"level":104,"name":141,"anchor":142},"Unit is masked","unit-is-masked",{"level":104,"name":144,"anchor":145},"Start request repeated too quickly","start-request-repeated-too-quickly",{"level":104,"name":147,"anchor":148},"Job type reload is not applicable","job-type-reload-is-not-applicable",{"level":73,"name":150,"anchor":151},"Заключение","zaklyuchenie",[],[154,158],{"route":155,"title":157},{"language":6,"path":156},"/kb/how-to","Полезные статьи",{"route":159,"title":20},{"language":6,"path":19},[],[],[163,172,181],{"route":164,"uuid":166,"title":167,"excerpt":25,"content":25,"view_count":15,"published_at":25,"modified_at":25,"like":69,"category":69,"hero_image":69,"seo_metadata":69,"schema_org_metadata":69,"open_graph_metadata":69,"sections":168,"tags":169,"breadcrumbs":170,"images":171},{"language":6,"path":165},"/kb/how-to/vps/podklyuchenie-cdn-joomla","aca59c89-9e37-b8d9-7cd9-9f621dc7caf7","Подключение CDN к Joomla в облаке Beget",[],[],[],[],{"route":173,"uuid":175,"title":176,"excerpt":25,"content":25,"view_count":15,"published_at":25,"modified_at":25,"like":69,"category":69,"hero_image":69,"seo_metadata":69,"schema_org_metadata":69,"open_graph_metadata":69,"sections":177,"tags":178,"breadcrumbs":179,"images":180},{"language":6,"path":174},"/kb/how-to/vps/prosmotr-i-nastrojka-logov-linux-na-ubuntu-debian-i-centos","67d3898b-2364-1fc7-4991-d7c3d9621310","Просмотр и настройка логов Linux на Ubuntu, Debian и CentOS",[],[],[],[],{"route":182,"uuid":184,"title":185,"excerpt":25,"content":25,"view_count":15,"published_at":25,"modified_at":25,"like":69,"category":69,"hero_image":69,"seo_metadata":69,"schema_org_metadata":69,"open_graph_metadata":69,"sections":186,"tags":187,"breadcrumbs":188,"images":189},{"language":6,"path":183},"/kb/how-to/vps/video-migraciya-bazy-dannyh-bitrix-v-oblako","331a423a-0ede-5105-b188-ebd560a3addd","Видео: Миграция базы данных Bitrix в облако",[],[],[],[],"popularity-desc"]