Логи и journalctl: первая причина отказа

Сервис не отвечает. В конце журнала написано «слишком частые запуски». Это уже объяснение причины или только последствие нескольких отказов?

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

Вход в расследование

Служба rp-notes сначала отвечала на http://127.0.0.1:8081/. Сейчас соединения нет. Программа, настройки и запись смены лежат в учебной песочнице. Начните с:

cat /root/README.md
systemctl status rp-notes --no-pager
curl -q --noproxy '*' --max-time 3 http://127.0.0.1:8081/

Здесь вы root внутри песочницы, но службу systemd запускает как notes, UID 1001. Это другой пользователь. Файл, который читает ваш терминал, может быть недоступен службе. Менять пользователя службы на root ради исчезновения ошибки нельзя.

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

Окно вместо последних пяти строк

В конце журнала часто оказываются повторы и сообщения systemd об остановке. Последняя строка не обязана объяснять первоначальную причину. Получите окно всей текущей попытки — граница записана до первого успешного запуска:

cat /run/rp-log-lab/started-at
journalctl -u rp-notes --since "$(cat /run/rp-log-lab/started-at)" --no-pager

Журнал настоящий: systemd запустил программу, она ответила, затем подготовка создала отказ. Вы увидите успех, сообщение программы, повторные попытки и их последствия. Дата, PID и точный вид служебных строк у разных запусков меняются.

Время «песочница готова» наступает после отказа. Если начать окно с него, нужная причина останется за границей. При сбросе создаётся новый сервер и новая граница; уже заработанный зачёт сохраняется.

Четыре способа сузить журнал

Что хотите узнать	Ключ	Пример
Записи конкретной службы	-u	journalctl -u rp-notes
Окно времени	--since, --until	--since "10 minutes ago"
Последние записи	-n	-n 30
Приоритет	-p	-p err

--no-pager выводит текст без постраничного просмотра. -o cat оставляет сообщения без привычного префикса времени и имени процесса; -o verbose показывает поля записи. Для расследования полезно сначала сохранить время и автора сообщения, а уже затем убирать оформление.

Сравните один и тот же диапазон:

journalctl -u rp-notes --since "$(cat /run/rp-log-lab/started-at)" --no-pager
journalctl -u rp-notes --since "$(cat /run/rp-log-lab/started-at)" -p err --no-pager

Важное для человека сообщение не обязательно имеет приоритет err. В первом варианте программа пишет причину обычным stderr без префикса приоритета: в этом образе запись получает info. Фильтр -p err её скрывает, а сообщение systemd об окончательном отказе может остаться. Во втором варианте программа явно задаёт приоритет ошибки. Не выбирайте фильтр только потому, что «мы ищем ошибку».

Кто сказал и что из этого следует

Разделите записи на три группы: успешная работа, первая причина отказа, дальнейшие повторы и последствия. Сообщение notes описывает то, что увидела программа. Сообщение systemd[1] рассказывает об управлении процессом.

Проверьте найденную причину отдельным наблюдением:

cat /etc/rp-notes/notes.conf
ls -l /etc/rp-notes/notes.conf
systemctl show -p User,Group rp-notes

Чтение от root не является проверкой доступа от notes. Если журнал говорит о чтении, сравните владельца, группу и права; если говорит о значении настройки, сначала проверьте именно её. Логи с другой попытки могут быть настоящими и при этом не отвечать на текущий вопрос.

Ремонт и проверка

Измените только подтверждённую причину. Согласованный порт — 8081. Программа /srv/notes/notes.py, запись /srv/notes/notes.txt и юнит должны сохраниться. Открывать настройки всем или выдавать запись группе не требуется.

После исправления причины службе нужен новый запуск. Если systemd ограничил попытки, reset-failed снимает этот лимит:

systemctl reset-failed rp-notes
systemctl start rp-notes
sleep 3
systemctl is-active rp-notes
curl -q --noproxy '*' --max-time 3 http://127.0.0.1:8081/

Ожидаются active и Привет из notes. Сам по себе reset-failed не исправляет настройку или доступ. Один успешный ответ отдельного процесса также не доказывает работу нужной службы: независимая проверка сверяет её PID, пользователя, команду, доступ к конфигурации и данные в ответе снаружи песочницы.

Нажмите «Проверить». Проверка не перезапускает службу за вас. Затем пройдите второй вариант: тот же симптом требует нового наблюдения. Повтор первой правки не является диагностикой.

Передать смену

Запишите 4–6 строк: симптом и окно времени, первая причина с подтверждением, изменение, результат после ожидания и оставшееся неизвестным. Гипотеза и записка — для вашей самопроверки; автоматический зачёт подтверждает состояние сервера.

Зачёт каждого варианта виден в программе курса и в другом браузере того же аккаунта. «Сбросить и начать заново» возвращает поломку и сохраняет уже полученный результат.

Разбор после своей попытки

В первом варианте PORT=80x1 не является числом. Исправьте на PORT=8081, снимите лимит попыток и запустите службу. Перезапуск без исправления вновь создаёт отказ.

Во втором значение верное, но файл root:root 600 не читается пользователем notes. Один допустимый ремонт — оставить владельца root, назначить группу notes и режим 640. Другая альтернатива — владелец notes и режим 600. Запуск от root скрывает исходный отказ и нарушает условие. После ремонта проверьте службу и ответ снова.

Продолжить можно в правах файлов и процессах и сервисах.

Источники: journalctl, systemd.exec: потоки и приоритеты.