Какими командами journalctl посмотреть логи службы?

Используйте journalctl -u -b --no-pager для просмотра сообщений службы в текущей загрузке. Если известно время сбоя, добавьте --since и --until, чтобы отделить нужную попытку запуска. После перезагрузки можно проверить предыдущую загрузку командой journalctl -u -b -1 --no-pager, если журнал был сохранён.

Можно ли сразу перезапускать службу, если она не запускается?

Нет, сначала сохраните исходные данные: вывод systemctl status, свойства через systemctl show и сообщения journalctl. Повторный restart меняет состояние службы, создаёт новые попытки запуска и может добавить записи при Restart=, из-за чего сложнее отделить первоначальную причину сбоя от последующих событий.

Когда нужно выполнять systemctl daemon-reload?

Выполняйте systemctl daemon-reload после добавления, удаления или изменения unit-файла либо его drop-in-конфигурации. Команда заставляет systemd перечитать определения units, но не запускает службу, не применяет конфигурацию приложения и не исправляет ошибку в самом unit-файле. Если менялась только конфигурация приложения, она обычно не нужна.

Почему systemctl пишет Unit not found?

Обычно это означает неверное имя или суффикс unit, отсутствие пакета или удалённое определение. Также systemd мог ещё не перечитать новый unit-файл. Проверьте полное имя через systemctl list-unit-files, затем свойства LoadState, FragmentPath и UnitFileState; после изменения unit-файла выполните systemctl daemon-reload.

Почему служба active, а приложение всё равно недоступно?

Потому что ActiveState=active отражает состояние unit в systemd, а не полную работоспособность приложения для клиентов. Проверьте собственный журнал приложения, слушающие ресурсы и его функцию способом, указанным в документации поставщика. Одного статуса active недостаточно для подтверждения доступности сервиса.

Служба systemd не запускается: диагностика ошибок и восстановление

Q: Чем masked отличается от disabled у systemd-службы?

disabled означает, что unit не включён для автоматического запуска, но его можно запустить вручную. masked блокирует запуск unit, пока маска не будет снята осознанным действием. Перед снятием маски выясните причину её установки: это не универсальный способ восстановить работу службы.

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

Зависимость от версии

Набор полей в systemctl status и systemctl show, формулировки сообщений, доступность директив и поведение конкретной службы зависят от версии systemd, дистрибутива и определения unit. Имена unit, расположение их файлов и команды проверки конфигурации приложения также различаются. Сверяйте результат с руководствами установленной ОС, systemd (systemctl, systemd.unit, systemd.service) и документацией приложения.

Сначала зафиксируйте имя unit и исходный симптом

Имя пакета, исполняемого процесса и unit часто не совпадают. Например, пакет может устанавливать несколько units с суффиксами .service и .socket. Для диагностики используйте имя из сообщения об ошибке или из списка units и по возможности указывайте полный суффикс: <unit>.service, <unit>.socket, <unit>.timer. Не переносите имя ssh.service или sshd.service между дистрибутивами без проверки.

Показывает известные service-unit, включая неактивные. Найдите фактическое имя нужной службы; при необходимости измените `--type` на `socket`, `timer` или другой тип.

systemctl list-units --all --type=service

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

systemctl list-unit-files --type=service

Не начинайте с restart

systemctl restart <unit> меняет состояние службы, создаёт новые попытки запуска и при Restart= может добавить сообщения в журнал. Первичный текст ошибки обычно остаётся в журнале, но отделить исходный сбой от последующих попыток становится сложнее. Сначала сохраните статус, свойства и журнал.

Как читать LoadState, active, failed и Unit not found

Состояния относятся к разным сторонам unit и должны интерпретироваться вместе.

Поле или сообщение	Что означает	Чего не доказывает
`LoadState=loaded`	systemd загрузил определение unit.	Что служба запущена, конфигурация приложения корректна или запуск вообще был успешен.
`ActiveState=active`	Unit сейчас активен в смысле, заданном его типом.	Что приложение полностью работоспособно для клиентов.
`ActiveState=inactive`	Unit сейчас не активен.	Что это ошибка: служба могла быть штатно остановлена, одноразово выполнена или пропущена условием.
`ActiveState=failed`	Последняя операция запуска либо выполнения unit завершилась неуспешно, либо systemd отметил unit как сбойный.	Конкретную причину. Её ищут по `Result`, коду завершения и журналу.
`SubState`	Более детальное внутреннее состояние: например, состояние запуска, работы или завершения.	Единственную причину сбоя без контекста `Type=`, времени и сообщений.
`Result`	Итог последней операции запуска или завершения, например ошибка команды, тайм-аут либо ограничение запусков.	Какой именно файл, параметр или внешнее условие вызвали проблему.
`Unit <unit> not found`	systemd не нашёл unit с указанным именем среди доступных ему определений.	Поломку systemd или то, что ранее существовавшая служба обязательно удалена.

LoadState, ActiveState, SubState и Result отвечают на разные вопросы. У службы может быть LoadState=loaded и одновременно ActiveState=failed: определение найдено, но запуск не удался. Напротив, inactive не всегда означает ошибку. Для service-unit итог запуска сопоставляют с Type=, полями ExecMainCode и ExecMainStatus, а также сообщениями systemd и приложения.

Безопасная последовательность: status, show и журнал до перезапуска

Сбор данных о failed-службе без изменения состояния

Замените <unit> на точное имя, например example.service. Команды ниже только читают состояние и журнал.

1
Сохраните краткий статус
Выполните systemctl status <unit> --no-pager. Здесь обычно видны Loaded, Active, Main PID, последние строки журнала и фрагмент команды запуска. Скопируйте вывод вместе со временем ошибки.
2
Запишите свойства unit
Выполните systemctl show <unit> -p LoadState -p ActiveState -p SubState -p Result -p MainPID -p ExecMainCode -p ExecMainStatus -p ExecStart -p Type -p User -p WorkingDirectory -p FragmentPath -p UnitFileState. Если часть свойств отсутствует или пуста, это может быть нормой для версии systemd либо конкретного типа unit.
3
Просмотрите журнал текущей загрузки
Выполните journalctl -u <unit> -b --no-pager. Найдите сообщения около времени из systemctl status; они часто содержат ошибку ExecStart, отказ в доступе, проблему зависимости или текст самого приложения.
4
Ограничьте журнал временем сбоя
Если время известно, задайте интервал, охватывающий сбой, например journalctl -u <unit> --since '2026-09-26 14:00:00' --until '2026-09-26 14:10:00' --no-pager. Подставьте фактические начало и конец интервала. Это отделяет нужную попытку от старых и новых запусков.
5
Проверьте предыдущую загрузку при необходимости
После перезагрузки попробуйте journalctl -u <unit> -b -1 --no-pager. Данные будут доступны, только если журнал предыдущей загрузки сохранён конфигурацией systemd-journald. Постоянное хранение и расширенную работу с журналами разбирает статья «Журналы Linux: journalctl, rsyslog и logrotate».

diagnose-unit.sh

UNIT=example.service
START='2026-09-26 14:00:00'
END='2026-09-26 14:10:00'

systemctl status "$UNIT" --no-pager
systemctl show "$UNIT" \
  -p LoadState -p ActiveState -p SubState -p Result \
  -p MainPID -p ExecMainCode -p ExecMainStatus -p ExecStart \
  -p Type -p User -p WorkingDirectory -p FragmentPath -p UnitFileState
journalctl -u "$UNIT" -b --no-pager
journalctl -u "$UNIT" --since "$START" --until "$END" --no-pager

Ветка: systemctl сообщает Unit not found

Ошибка Unit <unit> not found обычно означает неверное имя или суффикс, отсутствие установленного пакета, удалённое определение либо то, что systemd ещё не перечитал новый unit-файл. Она не доказывает неисправность systemd. Изменение уже известного unit само по себе обычно не объясняет not found, но после добавления или изменения unit-файла нужно выполнить daemon-reload, чтобы systemd применил новое определение.

Проверка отсутствующего или замаскированного unit

1
Проверьте полное имя
Сверьте имя с документацией пакета или выводом systemctl list-unit-files. Если тип известен, используйте полный суффикс, например <unit>.service, а не имя бинарного файла.
2
Проверьте, известно ли определение
Выполните systemctl show <unit> -p LoadState -p FragmentPath -p UnitFileState. FragmentPath при наличии обычно указывает на загруженный фрагмент unit. Фактические каталоги поиска и их приоритеты зависят от выпуска ОС и конфигурации systemd; не считайте один путь универсальным.
3
Проверьте маскировку
Выполните systemctl is-enabled <unit> и systemctl show <unit> -p UnitFileState. Состояние masked означает, что запуск unit заблокирован маской; это отдельный случай от disabled и failed.
4
Перечитайте определения после изменения
Если unit-файл добавили, удалили или изменили, выполните systemctl daemon-reload, затем повторите проверку свойств. Команда не запускает службу и не исправляет ошибку в самом файле.

Masked — не то же самое, что disabled

disabled характеризует включение unit при загрузке или через зависимости и не запрещает ручной запуск. masked блокирует запуск unit, пока маска не будет снята осознанным действием. Перед снятием маски выясните, почему она была установлена; не используйте это как универсальное исправление.

Ветка: служба failed, inactive или сразу завершается

Поля ExecStart, Result, MainPID, SubState и коды завершения полезны только вместе. ExecStart показывает, какую команду systemd пытался выполнить, но не подтверждает, что программа успешно инициализировалась. MainPID — PID главного процесса, известный systemd; значение 0 может означать, что актуального отслеживаемого процесса нет, но не устанавливает этап сбоя. SubState зависит от Type=, а одинаковый ненулевой код процесса может иметь совершенно разные причины.

Не делайте вывод о причине по одному свойству.

Наблюдение	Что проверить	Допустимый следующий вывод
`ExecMainCode=exited` и ненулевой `ExecMainStatus`	Строки journal около запуска и журнал приложения; документацию его конфигурации.	Программа была запущена и завершилась с кодом ошибки. Причина — не обязательно в systemd.
Сообщение о невозможности выполнить файл или отсутствии файла	Путь в `ExecStart`, существование и тип файла, зависимости пакета.	systemd либо ОС не смогли начать указанную программу; исправляйте путь, пакет или определение unit по подтверждённым данным.
Ошибка рабочей директории	`WorkingDirectory`, существование каталога и возможность перейти в него от имени службы.	Подготовка запуска не завершилась; проверьте путь и права доступа.
`MainPID=0`	`Type=`, `SubState`, время запуска, `ExecMainCode`, `ExecMainStatus` и журнал.	Нет текущего главного PID в представлении systemd; одного этого факта недостаточно для причины.
Служба активна, но приложение недоступно	Документацию приложения, его собственный журнал, слушающие ресурсы и проверку функции.	`active` отражает состояние unit, а не обязательно готовность прикладной функции.

ExecStart, Type и немедленное завершение процесса

Для service-unit Type= определяет, в какой момент systemd считает запуск завершённым и как отслеживает процесс. Неверно выбранный тип может приводить к тайм-ауту, неожиданному завершению или некорректному отслеживанию, даже если команда существует. Сравните Type= и форму ExecStart= с документацией приложения и systemd для установленной версии, а не с unit чужого сервера. ExecStart= не является произвольной строкой командной оболочки: её интерпретация определяется правилами systemd.

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

Частный пример OpenSSH

Для sshd документация OpenSSH предусматривает проверку конфигурации командой sshd -t; запускать её следует с учётом пути и параметров, принятых в целевой ОС. Это пример только для OpenSSH: у других приложений команда проверки отличается либо отсутствует. Установка и специальная диагностика SSH описаны в статье «OpenSSH Server в Linux: установка, запуск и диагностика sshd».

Пользователь службы, рабочий каталог и доступ к файлам

Директива User= задаёт учётную запись пользователя, от которой выполняется процесс; WorkingDirectory= — каталог, в который systemd пытается перейти перед запуском. При Permission denied недостаточно смотреть только на владельца файла и обычные права доступа к файлам. Сопоставьте сообщение с путём, пользователем службы, правами всех каталогов в пути, настройками изоляции и защиты самого unit, а также обязательным контролем доступа, если он используется в ОС.

Проверьте в systemctl show значения User=, Group= при наличии и WorkingDirectory=.
Сверьте путь, названный в журнале, с конфигурацией приложения и документацией поставщика.
Убедитесь, что исполняемый файл и требуемые каталоги существуют, а служебная учётная запись может обращаться к ним в требуемом режиме.
Если журнал указывает на SELinux, AppArmor или ограничения sandboxing unit, не отключайте защиту ради запуска: передайте диагностику в профильный материал и документацию ОС.

Что не делать при отказе доступа

Не запускайте произвольные команды приложения от root для проверки, не применяйте рекурсивные chmod -R или chown -R и не отключайте механизмы защиты. Изменение пользователей, групп и обычных прав разбирает статья «Пользователи, группы, sudo и права файлов в Linux».

Ветка: зависимость, Condition, Assert или слишком частые запуски

Случай	Как распознать	Что исправлять
Сбой зависимости	В `systemctl status` и `journalctl` упомянут зависимый unit или невозможность начать задание из-за зависимости.	Диагностируйте указанный зависимый unit по той же последовательности. Порядок `After=` и требование запуска через `Requires=` или `Wants=` — разные отношения.
Невыполненный `Condition...`	Журнал сообщает о невыполненном условии; unit может быть пропущен и остаться неактивным без обычного failed-состояния.	Проверьте факт, который выражает условие: путь, каталог, архитектуру, виртуализацию или иной параметр из unit.
Неуспешный `Assert...`	Журнал указывает на провал утверждения; запуск рассматривается как ошибка и unit может перейти в failed.	Исправьте нарушение утверждения либо само определение unit, если оно неверно для данной системы.
Ограничение частоты запусков	В журнале встречается сообщение о слишком частых запусках; `Result` может отражать достижение лимита.	Сначала устраните исходный сбой процесса или конфигурации, затем очистите счётчики и повторите запуск.

Когда применять daemon-reload, reset-failed, reload и restart

Каждая команда решает ограниченную задачу.

Действие	Когда выполнять	Что делает	Чего не делает
`systemctl daemon-reload`	После добавления, удаления или изменения unit-файла и его drop-in-конфигурации.	Перечитывает определения units менеджером systemd.	Не запускает службу, не перечитывает конфигурацию приложения, не включает автозагрузку и не исправляет ошибку unit.
`systemctl reset-failed <unit>`	После фиксации диагностики и устранения подтверждённой причины, если unit остаётся failed или достиг лимита запусков.	Очищает failed-состояние unit и связанные с ним счётчики ограничения частоты запусков.	Не запускает службу и не исправляет конфигурацию, зависимости, права или приложение.
`systemctl reload <unit>`	После изменения конфигурации приложения, только если его документация и unit предусматривают перечитывание без нового процесса.	Запрашивает у службы документированный reload.	Не гарантирует поддержку reload, не заменяет проверку конфигурации и не применяет изменения unit-файла.
`systemctl restart <unit>`	После устранения причины, выполнения необходимых проверок и `daemon-reload`, если менялся unit.	Останавливает и запускает службу заново согласно её определению.	Не исправляет первопричину и может вызвать краткий простой либо новые сообщения об ошибке.

Повторный запуск после подтверждённого исправления

Переходите к этим действиям только после сохранения исходных данных и исправления конкретной причины.

1
Примените новое определение unit при необходимости
Если изменялся unit-файл или drop-in, выполните systemctl daemon-reload. Если менялась только конфигурация приложения, эта команда не нужна для самой конфигурации.
2
Очистите failed и лимит попыток при необходимости
Если журнал подтверждает ограничение повторных запусков или unit остаётся failed после исправления, выполните systemctl reset-failed <unit>. Не считайте успешный выход команды признаком исправления.
3
Выберите reload или restart
Используйте systemctl reload <unit> только при документированной поддержке перечитывания конфигурации. Если приложению нужен новый процесс или reload не поддержан, выполните systemctl restart <unit> с учётом возможного простоя.
4
Подтвердите результат
Повторите systemctl status <unit> --no-pager и journalctl -u <unit> -b -n 50 --no-pager. Затем проверьте именно функцию приложения способом из его документации; одного состояния active может быть недостаточно.

Перезапуск может прервать обслуживание

Перед restart оцените влияние на клиентов, фоновые задания и удалённый доступ. Если проблема возникла после обновления пакета или отсутствует исполняемый файл, сначала подтвердите состояние пакета штатным менеджером: APT в Ubuntu и Debian: установка, обновление, удаление и очистка пакетов или DNF и YUM: установка, обновление и удаление пакетов. Ошибки пакетных транзакций рассматриваются отдельно в статье «Не устанавливаются пакеты в Linux: блокировки, dpkg и зависимости».

Термины в статье

Владелец файла: Владелец файла — числовой UID, записанный в метаданных объекта и определяющий применение класса прав владельца.
Демон: Демон — обычно длительно работающий неинтерактивный процесс, который в фоне выполняет системную, сетевую или прикладную функцию.
Командная оболочка: Командная оболочка — программа-интерпретатор, принимающая команды и запускающая процессы; в отличие от терминала, она обрабатывает синтаксис и сценарии.
Пакетная транзакция: Пакетная транзакция — согласованный набор действий по установке, обновлению, удалению и настройке пакетов, формируемый менеджером пакетов в рамках одной команды или задания.
Права доступа к файлам: Права доступа к файлам — разрешения файловой системы на чтение, запись и выполнение объекта для его владельца, группы-владельца и остальных пользователей.
Процесс: Процесс — экземпляр выполняемой программы в Linux с PID, виртуальным адресным пространством, состоянием и связанными с ним ресурсами.
Системная служба: Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
Суперпользователь: Суперпользователь — учётная запись с UID 0 или процесс с эффективным UID 0, обладающий административными правами; его полномочия шире, чем у обычного пользователя.
Учётная запись пользователя: Учётная запись пользователя — запись в системе идентификации ОС, связывающая имя и UID с параметрами входа, домашним каталогом и членством в группах.
journalctl: journalctl — консольная утилита чтения и фильтрации журнала systemd, выводящая сообщения по времени, юниту, загрузке системы, приоритету и другим полям.
PID: PID — числовой идентификатор экземпляра процесса, назначаемый ядром Linux для его адресации; после завершения процесса номер может быть использован повторно.
SSH: SSH — криптографический сетевой протокол для удалённого доступа и передачи данных, аутентифицирующий стороны и защищающий сеанс от перехвата.
sshd: sshd — серверный демон OpenSSH, принимающий SSH-подключения, аутентифицирующий пользователей и запускающий разрешённые удалённые сеансы или команды.
systemctl: systemctl — командная утилита управления systemd, которая запускает и останавливает юниты, показывает их состояние и настраивает автоматическую активацию.
systemd: systemd — система инициализации и менеджер служб Linux, управляющий службами и другими ресурсами как объектами unit, обычно описанными unit-файлами.
Systemd unit: Systemd unit — именованный объект systemd, представляющий отслеживаемый или управляемый ресурс, службу, задачу либо состояние системы.
systemd-journald: systemd-journald — служба systemd для приёма, индексации и хранения структурированных журналов ядра, служб, процессов и системных сообщений.