Сколько места занимают журналы systemd: проверка без очистки
Две команды чтения помогают оценить объём журнала и найти источники его конфигурации в Ubuntu 24.04. Объясняем границы результата и различия постоянного и временного хранения.
В этой статье
Диск заполняется, и первой подозреваемой становится система журналирования. До очистки стоит узнать, сколько места действительно занимают её файлы и какие настройки хранения заданы. Иначе можно потерять историю сбоя, почти не освободив пространство.
Инструкция предназначена для Ubuntu 24.04 с systemd 255 и стандартным пространством имён журнала. Она содержит только чтение состояния и файлов конфигурации. Синтаксис утилит сверён 26 сентября 2026 года с официальными страницами руководства Ubuntu Noble. Указанные вызовы также выполнены в локальной среде Ubuntu 24.04.3, пакет systemd 255.4-1ubuntu8.17. В этой среде файлов журнала не было: проверен запуск команд и чтение конфигурации, но не поведение заполненного журнала и не ротация.
Для просмотра полного системного журнала нужен уже предоставленный доступ администратора либо соответствующие разрешения. У обычного пользователя могут быть видны не все данные. В контейнере журнал хоста обычно не становится доступен просто от наличия утилиты. Не меняйте права, группы и настройки ради выполнения этой инструкции.
Получите объём, не выводя все сообщения
Версию установленной утилиты можно посмотреть отдельно:
journalctl --version
Затем запросите занятое журналами место:
journalctl --disk-usage
Параметр --disk-usage показывает суммарный объём активных и архивных файлов журнала в доступной области чтения. Он не печатает весь текст событий и не удаляет записи. На большом хранилище просмотр сведений о файлах тоже требует работы с файловой системой, поэтому не стоит запускать его непрерывно в частом цикле.
В нашей проверке утилита завершилась успешно, показала 0B и отдельно сообщила No journal files were found. Это означает отсутствие найденных файлов в данной среде. Такой результат нельзя переносить на рабочий сервер или трактовать как доказательство, что там не было событий. Сначала нужно проверить место выполнения и доступ к системному журналу.
Условный пример для другой машины: результат показывает 800 МиБ, а файловая система занята на 60 ГиБ. Даже полное удаление этих 800 МиБ не объяснило бы остальные занятые гигабайты. Здесь полезнее продолжить диагностику других данных. Этот пример — арифметика, а не результат измерения конкретного сервера.
Посмотрите основной файл вместе с дополнениями
Настройки могут находиться не только в основном файле. Прочитайте конфигурацию с учётом дополнительных фрагментов:
systemd-analyze cat-config systemd/journald.conf
Утилита показывает найденные файлы конфигурации с их происхождением. Она не редактирует их и не перезапускает службу. Чтение файлов на диске не доказывает, что работающий процесс уже применил их последнюю редакцию. Это также не отчёт с вычисленным итоговым значением каждого параметра.
Обратите внимание на комментарии. Строка, начинающаяся с #, не является активным присваиванием. В поставляемом файле так часто показаны значения по умолчанию. В локальной проверке были видны основной файл и дополнительный фрагмент поставщика; чтение только первого файла дало бы неполную картину источников настройки.
Если один параметр встречается в нескольких активных строках, нужно учитывать порядок и правила приоритета конфигурации. Не выбирайте первое знакомое значение из вывода. Перед любыми изменениями администратор должен выяснить, какой файл задаёт нужное значение и нет ли более приоритетного дополнения. В этой инструкции файлы остаются неизменными.
Сравнивайте лимит с правильным местом хранения
Параметр Storage= определяет режим хранения. Для обычного пространства имён persistent предпочитает постоянное хранение в /var/log/journal, а volatile — временное в /run/log/journal. Режим auto использует наличие каталога постоянного журнала как условие выбора. Ранний этап загрузки и недоступность записи на постоянное хранилище могут менять фактическое место записи, поэтому одной строки настройки недостаточно для полного вывода о состоянии сервера.
Семейство SystemMaxUse= относится к постоянному журналу, а RuntimeMaxUse= — к временному. Ограничения SystemKeepFree= и RuntimeKeepFree= задают требования к свободному месту. Настройка максимального размера и требование оставить место учитываются совместно. Сравнивать объём временного журнала только с лимитом постоянного было бы ошибкой.
Не путайте текущий объём с обещанием немедленного уменьшения. В число занятых байтов входят активные файлы, а механизмы удаления старой истории имеют свои условия. Само обнаружение большого числа не является основанием запускать очистку. Сначала надо понять, сколько истории нужно для расследований и не записывает ли приложение необычно большой поток повторяющихся сообщений.
Что сохранить для дальнейшего решения
Зафиксируйте время измерения, среду выполнения, права чтения, результат --disk-usage и активные параметры хранения с именами файлов, откуда они взяты. Если объём заметно растёт, повторите тот же замер спустя разумный интервал и сопоставьте рост с работой приложений. Два числа показывают изменение объёма, но сами по себе не называют службу, которая создала события.
Для передачи специалисту достаточно относящихся к вопросу настроек и обезличенного результата. Полный архив событий может содержать токены, запросы и данные пользователей. Если выяснится, что необходимо менять срок хранения или освобождать место, это будет отдельная операция с сохранением нужной истории и планом проверки. До неё у вас уже будет ответ на исходный вопрос: сколько места занимает доступный журнал и какие источники конфигурации влияют на его хранение.
When the disk fills up, the logging system is the first suspect. Before cleaning, find out how much space its files actually occupy and what storage settings are configured. Otherwise, you risk losing crash history while freeing up almost no space.
This guide is intended for Ubuntu 24.04 with systemd 255 and the standard journal namespace. It includes only reading the current state and configuration files. The utility syntax was verified on September 26, 2026, against the official Ubuntu Noble documentation pages. The specified commands were also executed in a local Ubuntu 24.04.3 environment with the systemd package version 255.4-1ubuntu8.17. In this environment, no journal files existed: we verified command execution and configuration reading, but not the behavior of a full journal or log rotation.
To view the full system journal, you must already have administrator access or the appropriate permissions. A regular user may not see all data. In a container, the host journal typically does not become available simply by having the utility installed. Do not change permissions, groups, or settings to follow this instruction.
Get the volume without printing all messages
You can view the version of the installed utility separately:
journalctl --version
Then request the space occupied by the journals:
journalctl --disk-usage
The parameter --disk-usage shows the total size of active and archived journal files in the readable area. It does not print the full text of events nor does it delete records. On large storage, viewing file details also requires file system operations, so it should not be run continuously in a frequent loop.
In our test, the utility completed successfully, showing 0B and separately reporting No journal files were found.. This indicates no files were found in this environment. Such a result cannot be transferred to a production server or interpreted as proof that no events occurred there. First, you must verify the execution location and access to the system journal.
A conditional example for another machine: the result shows 800 MiB, while the file system is 60 GiB full. Even deleting all 800 MiB would not explain the remaining occupied gigabytes. It is more useful here to continue diagnosing other data. This example is arithmetic, not a measurement result from a specific server.
View the main file along with additions
Settings may not be located only in the main file. Read the configuration taking additional fragments into account:
systemd-analyze cat-config systemd/journald.conf
The utility displays found configuration files along with their origin. It does not edit them or restart the service. Reading files on disk does not prove that the running process has already applied their latest revision. This is also not a report with a computed final value for each parameter.
Pay attention to the comments. The line starting with # is not an active assignment. In the supplied file, default values are often shown this way. In the local test, both the main file and an additional provider fragment were visible; reading only the first file would have given an incomplete picture of the configuration sources.
If a parameter appears in multiple active lines, you must account for order and configuration priority rules. Do not select the first familiar value from the output. Before making any changes, the administrator must determine which file sets the required value and whether a higher-priority override exists. In this guide, the files remain unchanged.
Compare the limit with the correct storage location
The Storage= parameter defines the storage mode. For the standard namespace persistent, permanent storage in /var/log/journal is preferred, while volatile uses temporary storage in /run/log/journal. The auto mode uses the presence of a permanent journal directory as a selection condition. Early boot stages and the inability to write to permanent storage can alter the actual write location, so a single configuration line is insufficient to fully determine the server state.
The SystemMaxUse= family belongs to the permanent journal, while RuntimeMaxUse= belongs to the temporary one. The SystemKeepFree= and RuntimeKeepFree= constraints set requirements for free space. The maximum size setting and the requirement to reserve space are considered together. Comparing the temporary journal volume only to the permanent limit would be an error.
Do not confuse the current volume with a promise of immediate reduction. The count of occupied bytes includes active files, and mechanisms for deleting old history have their own conditions. Merely detecting a large number is not grounds to start cleanup. First, determine how much history is needed for investigations and whether the application is logging an unusually large stream of repeated messages.
What to save for further resolution
Record the measurement time, execution environment, read permissions, the result --disk-usage, and active storage parameters along with the filenames from which they were retrieved. If the volume grows noticeably, repeat the same measurement after a reasonable interval and correlate the growth with application activity. Two numbers show the change in volume, but by themselves do not identify the service that generated the events.
To pass the issue to a specialist, only relevant settings and an anonymized result are sufficient. A full event archive may contain tokens, requests, and user data. If it turns out that the retention period needs to be changed or space needs to be freed, that will be a separate operation involving preservation of the necessary history and a verification plan. Until then, you will already have an answer to the original question: how much space the accessible journal occupies and which configuration sources affect its storage.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.