Отладка: логи, список fail-fast и учения

Обзор

6.1 Введение

Сервер без интерфейса управления обязан вырастить отладочные возможности в другом месте. Выбор XServer: сделать диагностику детерминированными событиями — одна и та же конфигурация и состояние всегда дают одни и те же строки лога в том же порядке; ошибки конфигурации всегда называют конкретное поле при старте и завершают процесс, никогда не «работая с дефектом». Детерминизм = сопоставимость: у каждой аномальной строки, которую вы видите, есть близнец в тест-кейсах исходников.

Три секции покрывают три домена отказов: период старта (порядок лога + список fail-fast), период остановки (последовательность корректной остановки) и период работы (тестовые и ученийные базлайны).

6.2 Система логирования

Словарь последовательности старта

Глава 2 разбирала нормальную последовательность построчно; здесь добавляем аномальные ветви — что значит, если строка «не появилась» или «выглядит иначе»:

Последовательность остановки

Пять фаз после Ctrl+C / SIGTERM (тестовый базлайн содержит утверждения на последние две строки):

[xs] stopping
(прекратить приём и утилизировать скрипты → дождаться терминальных состояний сети → утилизировать custom → вычистить очередь деструкций)
[xs] engine stopped
[xs] bye

Откуда берутся логи приложения

Строки с префиксом вроде [demo] — это ваш собственный printf: логирование скриптов XServer — стандартный вывод. Хотите структуру — берите семейство logger из xrt (76 API: уровни, форматирование, несколько приёмников), см. блок «Что дальше».

6.3 Список ошибок fail-fast

У валидации xs.json 21 тест-кейс (A-матрица func_test), все с утверждением «exit=1 и ошибка называет конкретное поле». Частые выдержки:

Проектная позиция: лучше отказать в старте, чем молча деградировать — вы никогда не встретите самый опасный тихий отказ «настроили TLS, а фактически работает открытый текст».

6.4 Остановка и учения

«Не только ли у меня сломано?» — встроенные в репозиторий базлайны и есть контрольная группа для ответа:

Отладка на уровне памяти (падения, выход за границы, утечки) использует систему отладки памяти xrt: канарейки спереди и сзади, очереди изоляции UAF, кольцевой журнал событий аллокации, отчёты TEXT/JSON — включается в конфигурации сборки хоста; см. главу 6 учебника xrt по ссылке в конце.

6.5 Контракт

• Детерминизм: одинаковый вход всегда даёт одинаковую последовательность лога — любая «мистика» указывает на конфигурацию или среду.
• Fail-fast: ошибки старта все называют поле и завершают процесс; устойчивые ошибки времени работы проявляются кодами состояния на уровне соединения / разрывами и не роняют процесс.
• Порядок отладки: сначала лог (найти фазу) → затем список fail-fast (сопоставить сообщение) → в конце базлайны (изолировать факторы среды).

Частые ошибки

/* правим xs.json и просто ждём */
vim xs.json   # порт не сменился?

/* скрипты/сертификаты: подать reload (том 4)
 * структурные изменения: рестарт процесса */

#include <config.h>
/* куда попало: includes/config.h
 * или другой config.h из CWD? */

/* уникальные имена вместо общих */
#include <myapp_config.h>

/* «дедлок!» → сразу kill -9
 * теряем и место отладки, и семантику корректности */

/* посмотреть, на какой фазе лог;
 * дать приложению /shutdown для завершения соединений;
 * внешний тайм-аут — от сервис-менеджера (глава 37) */

Упражнения