Предложение по переводу системных логов lastlog, btmp, utmp и wtmp на использование SQLite

Пт мар 13, 2026 8:11 am

В списке рассылки linux-api выставлено на обсуждение предложение (RFC) заменить устаревшие бинарные форматы системных журналов lastlog, btmp, utmp и wtmp на новые разделяемые библиотеки, использующие SQLite в качестве бэкенда. Инициатива направлена на решение накопившихся проблем, среди которых переполнение 32-разрядных счётчиков времени в 2038 году, отсутствие расширяемости, низкая производительность запросов и отсутствие атомарности при записи. В настоящее время для хранения данных о сеансах и попытках аутентификации в Linux используются следующие бинарные файлы, имеющие фиксированную структуру:

/var/log/lastlog - время последнего входа (структура "struct lastlog" с полем "ll_time" 32-разрядного типа time_t); /var/log/btmp - неудачные попытки входа; /var/run/utmp - текущие сеансы; /var/log/wtmp - история входов и выходов.

Формат данных файлов был разработан несколько десятилетий назад и имеет ряд фундаментальных ограничений:

Поле "tv_sec" в структуре "utmpx" и поле "ll_time" в "lastlog" имеют тип "int32_t", значение счётчиков времени на основе которого переполнится 19 января 2038 года. Из-за требований ABI‑совместимости даже на 64-разрядных системах эти поля остаются 32-разрядными, поэтому проблема затронет все установки Linux. Фиксированный размер записей не позволяет добавлять новые поля (например, идентификатор контейнера, имя сервиса, IP-адрес) без полной замены формата и перекомпиляции всех утилит. Утилиты last, lastb, who и lastlog вынуждены линейно перебирать содержимое файлов. При большом размере журналов без использования индексов, позволяющих эффективно фильтровать записи, нагрузка на систему ввода/вывода и задержки при выполнении запросов становятся неприемлемыми. Запись в бинарный файл не является атомарной операцией. При сбое запись может быть частично повреждена. Для исключения конфликтов при одновременной записи в журтал несколькими процессами (например, sshd и login) используются flock-блокировки, которые не гарантируют атомарность и могут приводить к взаимным блокировкам.

Автор RFC предлагает полностью отказаться от бинарных форматов в пользу специализированных разделяемых библиотек, использующих SQLite. Для каждого типа журналов создаётся отдельная библиотека с единообразным C-интерфейсом: liblastlog2, libbtmp2, libutmp2 и libwtmp2. Все библиотеки работают с БД, схема которых включает 64-разрядные временные метки (тип INTEGER) и индексы по пользователю и времени. Имеется возможность добавления новых полей без нарушения совместимости (через ALTER TABLE). Среди доводов в пользу использования SQLite упоминается использование 64-разрядного типа INTEGER для хранения эпохального времени, задействование индексов для снижения ввода/вывода за счёт выборочного обращения к записями вместо полного сканирования, возможность добавления новых полей без изменения существующих записей, поддержка ACID-транзакций, режим WAL (Write-Ahead Logging) для конкурентного доступа без блокировок, проверенная надёжность работы SQLite. Для обеспечения плавного перехода предлагается стратегия "двойной записи" (dual-write):

Программы, которые пишут в бинарные файлы (login, sshd, sudo, cron и др.), модифицируются так, чтобы одновременно выполнять запись и в старый бинарный файл, и в новую SQLite-базу через соответствующую библиотеку. Разрабатываются новые версии утилит (last2, lastb2, who2, lastlog2), которые читают данные из SQLite-баз, используя индексы для быстрой работы. Старые утилиты продолжают работать с прежними файлами. Через несколько лет, когда подавляющее большинство систем обновятся, поддержка записи в старые форматы может быть отключена, а старые утилиты - объявлены устаревшими.

Вопросы, выставленные для дополнительного обсуждения:

Целесообразность разделения на отдельные библиотеки или объединения в одну (например, libsession2). Выбор имён для библиотек и утилит (сохранить исторические названия или перейти к более общим). Расположение файлов баз данных (/var/lib/ как для состояния приложений или /var/log/ как для логов). Механизм версионирования схемы и миграции. Параметры производительности SQLite для различных сценариев (серверы, встраиваемые системы). Предоставление fallback-бэкенда, хранящего журналы в упрощённом бинарном формате, для систем, на которых SQLite может оказаться избыточным (например, встраиваемые устройства с жёсткими ограничениями по памяти).

Источник: https://www.opennet.ru/opennews/art.shtml?num=64981