В списке рассылки 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 может оказаться избыточным (например, встраиваемые устройства с жёсткими ограничениями по памяти).