После перезагрузки пропали логи: как хранится журнал systemd

Если после перезагрузки journalctl не показывает старые записи, сначала проверьте доступные загрузки, права и выбранный журнал. Затем установите действующий режим хранения и ограничения истории. Включение persistent помогает сохранять будущие записи, но не создаёт заново журнал, который уже утрачен.

Пропали записи или выбрана другая выборка

Начните с команды просмотра journalctl --list-boots. В руководстве journalctl она показывает имеющиеся загрузки, их идентификаторы и границы сообщений. Это перечень доступной истории, а не обещание, что на диске сохранена каждая перезагрузка машины.

Для дальнейшего разбора выберите нужный boot ID и только затем фильтр службы или времени. Команда journalctl -b -1 обращается к предыдущей загрузке из найденной последовательности. Если история неполна, не подменяйте этим сокращением проверку конкретного события.

Учитывайте права пользователя, источник файлов и namespace. Пустой результат узкой выборки не доказывает физическое исчезновение всех записей. Сохраните условия просмотра, чтобы другой администратор мог понять, какую именно историю вы искали.

Где journald хранит полученные сообщения

В journald.conf Storage управляет местом хранения. Volatile использует /run/log/journal, persistent предпочитает /var/log/journal с предусмотренным временным переходом на /run при ранней загрузке или недоступном для записи диске. Auto зависит от наличия каталога постоянного журнала.

Режим none отключает хранение полученных данных в журнале, но не обязательно их пересылку другим получателям. Поэтому отсутствие локального файла и отсутствие любых других копий — разные выводы. Уточните, какие места сбора действительно предусмотрены вашей эксплуатацией.

Проверяйте эффективные настройки своей версии и дистрибутива. Параметры из основной конфигурации могут дополняться другими файлами. Для отдельного namespace возможна своя конфигурация; одна открытая строка Storage не описывает автоматически всю машину.

Карта проверки сохранности

Предлагаемая таблица помогает отделить причины. Она не содержит результатов осмотра сервера и не предлагает удалять историю ради свободного места. Напротив каждого вывода нужны подтверждённые условия.

Начальный буфер и переход на постоянное хранение

В описании systemd-journald.service указан начальный volatile-режим и переход через flush при выполнении нужных условий. При загрузке это связано с systemd-journal-flush.service. Наличие постоянного каталога ещё стоит сопоставить с тем, что произошло фактически.

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

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

Сохранение на диске не означает бесконечную историю

Journald.conf отдельно задаёт ограничения объёма SystemMaxUse и RuntimeMaxUse, резерв свободного места и срок MaxRetentionSec. Разные ограничения решают разные задачи. Наличие persistent не отменяет ротацию и удаление старой истории по политике.

Определите, какой период реально нужен для разбора событий. Затем оцените обычный поток и всплески сообщений, оставляя ресурс соседним сервисам. Одинаковый бюджет диска может сохранять разную глубину истории при разных темпах записи.

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

Что ещё можно найти для завершившегося события

После подтверждённой утраты локальной истории проверьте предусмотренные независимые источники: централизованный сбор, архивы или отдельные журналы приложения. Их наличие сначала нужно установить. Не заявляйте, что они существуют, только потому, что такое решение обычно бывает удобным.

Ограничьте доступ и объём передаваемой диагностики. Для выяснения причины нехватки истории не требуется публиковать полный журнал с адресами пользователей и внутренними деталями. Зафиксируйте, что сохранилось и за какой период, а пробел обозначьте прямо.

Приёмка будущего хранения

1. Запишите нужное событие, boot ID и условия просмотра.
2. Подтвердите действующий режим, namespace и источники конфигурации.
3. Проверьте доступность места хранения и штатный переход после загрузки.
4. Согласуйте срок истории, размерный бюджет и запас диска.
5. Проверьте появление безопасной контрольной записи в собственной среде.
6. При плановом обслуживании подтвердите её сохранность между загрузками.
7. Проверьте чтение нужной службой поддержки и контроль заполнения хранилища.

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

Результат состоит из двух частей: честно установлен предел сохранившейся истории и проверен будущий порядок записи. Настройку для следующего события не стоит выдавать за восстановление сведений о предыдущем.