{"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 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
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