У каждого журнала своя часть правды о сбое.
Хронологию собирают из записей, которые машина вела сама. Здесь их три вида, и каждый отвечает на свой вопрос:
| Источник | Что в нём | Команда |
|---|---|---|
| журнал sudo | что делали люди | sudo journalctl -t sudo |
| журнал службы | что делала программа | sudo journalctl -u lab-app |
| проверка сайта | что видели пользователи | sudo journalctl -t lab-sitecheck |
Начало и конец сбоя берут из третьего источника — из того, что видели пользователи; для сайта за nginx это ещё и коды ответов в его access.log. Правка может пролежать секунды или часы, прежде чем что-то сломается: новый app.py шесть секунд лежал на диске, а запросы обслуживал прежний процесс. Поэтому время правки — отдельная строка хронологии. От длительности сбоя потом считают влияние: сколько запросов остались без ответа и какую часть бюджета ошибок это съело.
Журнал машины за 15 минут — больше тысячи строк: загрузка, вход в консоль, службы. Метки -t оставляют из них людей и проверку сайта одним списком по времени, а журнал службы смотрят отдельным запросом с -u, как в уроке о ранбуке. Почему сайт не поднялся сам, знает как раз он: у lab-app в юните стоит Restart=on-failure.
Загляни в журнал службы
У lab-app в юните Restart=on-failure — упавшую службу systemd перезапускает сам. Посмотри, как служба настроена, и что её журнал за 15 минут говорит об ошибках и перезапусках.
Сначала предположи
Что systemd делал с новой версией, которая падала при запуске?
Теперь начни упражнение, выполни команду и сверь прогноз с выводом.