{"id":164053,"date":"2026-03-13T11:11:58","date_gmt":"2026-03-13T09:11:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/predlozhenie-po-perevodu-sistemnyh-logov-lastlog-btmp-utmp-i-wtmp-na-ispolzovanie-sqlite"},"modified":"2026-03-13T11:11:58","modified_gmt":"2026-03-13T09:11:58","slug":"predlozhenie-po-perevodu-sistemnyh-logov-lastlog-btmp-utmp-i-wtmp-na-ispolzovanie-sqlite","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/predlozhenie-po-perevodu-sistemnyh-logov-lastlog-btmp-utmp-i-wtmp-na-ispolzovanie-sqlite","title":{"rendered":"Proposal for converting system logs lastlog, btmp, utmp, and wtmp to use SQLite","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
The linux-api mailing list has proposed (RFC) to replace outdated binary formats of system logs lastlog, btmp, utmp, and wtmp with new shared libraries using SQLite as the backend. The initiative aims to address accumulated issues, including the overflow of 32-bit timestamps in 2038, lack of extensibility, low query performance, and the absence of atomicity in writes. <\/p>\n
Currently, the following binary files with a fixed structure are used in Linux for storing session data and authentication attempts: <\/p>\n
The data format of these files was developed several decades ago and has a number of fundamental limitations: <\/p>\n
\n
Le champ \u00ab tv_sec \u00bb dans la structure \u00ab utmpx \u00bb et le champ \u00ab ll_time \u00bb dans \u00ab lastlog \u00bb ont un type \u00ab int32_t \u00bb, avec une valeur de compte \u00e0 rebours qui d\u00e9bordera le 19 janvier 2038. En raison des exigences de compatibilit\u00e9 ABI, m\u00eame sur les syst\u00e8mes 64 bits, ces champs restent 32 bits, ce qui signifie que le probl\u00e8me affectera toutes les installations Linux.\n
The fixed size of records does not allow for adding new fields (for example, container ID, service name, IP address) without completely replacing the format and recompiling all utilities.\n
Les utilitaires last, lastb, who et lastlog doivent parcourir lin\u00e9airement le contenu des fichiers. En cas de journaux volumineux sans utilisation d'index permettant de filtrer efficacement les enregistrements, la charge sur le syst\u00e8me d'entr\u00e9e\/sortie et les d\u00e9lais d'ex\u00e9cution des requ\u00eates deviennent inacceptables.\n
L'\u00e9criture dans un fichier binaire n'est pas une op\u00e9ration atomique. En cas de d\u00e9faillance, l'\u00e9criture peut \u00eatre partiellement corrompue.\n
Pour \u00e9viter les conflits lors d'\u00e9critures simultan\u00e9es dans le journal par plusieurs processus (par exemple, sshd et login), des verrous flock sont utilis\u00e9s, qui ne garantissent pas l'atomicit\u00e9 et peuvent entra\u00eener des blocages mutuels. <\/ul>\n
L'auteur de la RFC propose d'abandonner compl\u00e8tement les formats binaires au profit de biblioth\u00e8ques partag\u00e9es sp\u00e9cialis\u00e9es utilisant SQLite. Pour chaque type de journal, une biblioth\u00e8que distincte avec une interface C uniforme est cr\u00e9\u00e9e : liblastlog2, libbtmp2, libutmp2 et libwtmp2. Toutes les biblioth\u00e8ques travaillent avec des bases de donn\u00e9es dont le sch\u00e9ma comprend des horodatages de 64 bits (type INTEGER) et des index par utilisateur et par temps. Il est possible d'ajouter de nouveaux champs sans compromettre la compatibilit\u00e9 (via ALTER TABLE). <\/p>\n
Parmi les arguments en faveur de l'utilisation de SQLite, on mentionne l'utilisation d'un type INTEGER 64 bits pour stocker le temps \u00e9pique, l'utilisation d'index pour r\u00e9duire l'entr\u00e9e\/sortie par l'acc\u00e8s s\u00e9lectif aux enregistrements au lieu d'un balayage complet, la possibilit\u00e9 d'ajouter de nouveaux champs sans modifier les enregistrements existants, le support des transactions ACID, le mode WAL (Write-Ahead Logging) pour l'acc\u00e8s concurrent sans blocages, et la fiabilit\u00e9 \u00e9prouv\u00e9e de SQLite. <\/p>\n
Pour assurer une transition en douceur, une strat\u00e9gie de \u00ab double \u00e9criture \u00bb (dual-write) est propos\u00e9e : <\/p>\n
\n
Les programmes qui \u00e9crivent dans des fichiers binaires (login, sshd, sudo, cron, etc.) sont modifi\u00e9s pour effectuer simultan\u00e9ment des \u00e9critures dans l'ancien fichier binaire et dans la nouvelle base de donn\u00e9es SQLite via la biblioth\u00e8que correspondante.\n
De nouvelles versions des utilitaires (last2, lastb2, who2, lastlog2) sont en cours de d\u00e9veloppement pour lire les donn\u00e9es des bases SQLite, utilisant des index pour un fonctionnement rapide. Les anciens utilitaires continuent de fonctionner avec les anciens fichiers.\n
Dans quelques ann\u00e9es, lorsque la grande majorit\u00e9 des syst\u00e8mes auront \u00e9t\u00e9 mis \u00e0 jour, le support de l'\u00e9criture dans d'anciens formats pourrait \u00eatre d\u00e9sactiv\u00e9, et les anciens outils pourraient \u00eatre d\u00e9clar\u00e9s obsol\u00e8tes. <\/ul>\n
Les questions soulev\u00e9es pour discussion suppl\u00e9mentaires : <\/p>\n
\n
La pertinence de diviser en biblioth\u00e8ques distinctes ou de regrouper en une seule (par exemple, libsession2).\n
Choix des noms pour les biblioth\u00e8ques et les utilitaires (maintenir les noms historiques ou passer \u00e0 des noms plus g\u00e9n\u00e9raux).\n
Emplacement des fichiers de bases de donn\u00e9es (\/var\/lib\/ comme pour l'\u00e9tat des applications ou \/var\/log\/ comme pour les journaux).\n
M\u00e9canisme de versioning du sch\u00e9ma et de migration.\n