Как устроен Systemd Doctor

Что в базе

Сейчас опубликовано 280 записей об ошибках, 24 страниц служб и 100 терминов словаря. Парсер опирается на 708 шаблонов распознавания. Числа считаются из самой базы при сборке.

Запись появляется, только если за ней стоит отдельная проблема: код выхода, состояние, сообщение журнала, параметр unit или конкретный сценарий поломки. Разные формулировки одной и той же беды — bind() ... Address already in use, Failed to bind, «порт занят» — сведены в одну каноническую запись с набором сигнатур. Размножать почти одинаковые страницы ради поисковых запросов мы не будем: это делает базу хуже, а не больше.

Как проверяется содержимое

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

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

Как работает разбор

Парсер не обращается к языковым моделям. Он извлекает из вывода systemctl status имя unit, состояния Loaded и Active, Main PID, коды status=N/NAME, сигналы и строки процессов, а затем сопоставляет строки журнала с шаблонами базы. Одинаковый ввод всегда даёт одинаковый ответ, а разбор занимает миллисекунды — это важнее, чем красивые формулировки.

Находки выстраиваются так, чтобы причина стояла выше следствия. «Unit entered failed state» — следствие; 203/EXEC и «Permission denied» — причина. Если совпадений нет, сайт прямо говорит, что ошибка не распознана, показывает извлечённые признаки и общий порядок действий, а обезличенная сигнатура попадает в очередь на разбор.

Как база пополняется

Раз в неделю проверяются изменения в документации и новые версии systemd, разбираются нераспознанные сигнатуры и внутренние поисковые запросы, после чего формируется список кандидатов на новые записи. Кандидат не становится страницей автоматически: сначала проверка по первичному источнику, потом публикация. Все правки попадают в список обновлений, и каждая строка там соответствует изменённому содержимому.

Чего сайт не делает

• Не выполняет ваши команды и не запускает содержимое unit-файлов.
• Не сохраняет вставленные логи и не показывает их кому-либо ещё.
• Не выдаёт догадки за проверенные сведения: если поведение зависит от версии systemd, это сказано на странице.

Подробнее про данные — на странице о приватности, про источники — здесь.