{"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\/de\/blog\/novosti-interneta\/predlozhenie-po-perevodu-sistemnyh-logov-lastlog-btmp-utmp-i-wtmp-na-ispolzovanie-sqlite","title":{"rendered":"Vorschlag zur \u00dcbersetzung der Systemprotokolle lastlog, btmp, utmp und wtmp zur Verwendung von SQLite.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In der Mailingliste linux-api wird ein Vorschlag (RFC) zur Diskussion gestellt, die veralteten bin\u00e4ren Formate der Systemprotokolle lastlog, btmp, utmp und wtmp durch neue gemeinsam genutzte Bibliotheken zu ersetzen, die SQLite als Backend verwenden. Diese Initiative zielt darauf ab, vorhandene Probleme zu l\u00f6sen, darunter das \u00dcberlaufen von 32-Bit-Zeitstempeln im Jahr 2038, mangelnde Erweiterbarkeit, niedrige Abfragegeschwindigkeit und das Fehlen von Atomarit\u00e4t beim Schreiben. <\/p>\n
Derzeit werden in Linux die folgenden bin\u00e4ren Dateien mit fester Struktur zur Speicherung von Daten \u00fcber Sitzungen und Authentifizierungsversuche verwendet: <\/p>\n
Das Datenformat dieser Dateien wurde vor mehreren Jahrzehnten entwickelt und weist eine Reihe grundlegender Einschr\u00e4nkungen auf: <\/p>\n
\n
Das Feld \u201etv_sec\u201c in der Struktur \u201eutmpx\u201c und das Feld \u201ell_time\u201c in \u201elastlog\u201c haben den Typ \u201eint32_t\u201c, der Zeitstempel, dessen Z\u00e4hler am 19. Januar 2038 \u00fcberlaufen wird. Aufgrund der Anforderungen an die ABI-Kompatibilit\u00e4t bleiben diese Felder auch auf 64-Bit-Systemen 32-Bit, sodass das Problem alle Linux-Installationen betrifft.\n
Die feste Gr\u00f6\u00dfe der Eintr\u00e4ge erlaubt es nicht, neue Felder hinzuzuf\u00fcgen (wie z.B. Container-ID, Dienstname, IP-Adresse), ohne das Format vollst\u00e4ndig zu ersetzen und alle Utilities neu zu kompilieren.\n
Die Utilities last, lastb, who und lastlog m\u00fcssen den Inhalt der Dateien linear durchsuchen. Bei gro\u00dfen Logdateien ohne Indizes, die eine effiziente Filterung der Eintr\u00e4ge erm\u00f6glichen, wird die Belastung des Ein- und Ausgabesystems sowie die Verz\u00f6gerung bei Anfragen inakzeptabel.\n
Das Schreiben in eine Bin\u00e4rdatei ist keine atomare Operation. Bei einem Fehler kann der Schreibvorgang teilweise besch\u00e4digt sein.\n
Um Konflikte bei gleichzeitigen Schreibvorg\u00e4ngen in die Logs durch mehrere Prozesse (wie z.B. sshd und login) zu vermeiden, werden flock-Sperren verwendet, die jedoch keine Atomarit\u00e4t garantieren und zu gegenseitigen Blockierungen f\u00fchren k\u00f6nnen. <\/ul>\n
Der Autor des RFC schl\u00e4gt vor, vollst\u00e4ndig auf bin\u00e4re Formate zu verzichten und stattdessen spezialisierte gemeinsame Bibliotheken zu verwenden, die SQLite nutzen. F\u00fcr jeden Journaltoken wird eine separate Bibliothek mit einer einheitlichen C-Schnittstelle erstellt: liblastlog2, libbtmp2, libutmp2 und libwtmp2. Alle Bibliotheken arbeiten mit einer Datenbank, deren Schema 64-Bit-Zeitsstempel (INTEGER-Typ) und Indizes nach Benutzer und Zeit umfasst. Es besteht die M\u00f6glichkeit, neue Felder hinzuzuf\u00fcgen, ohne die Kompatibilit\u00e4t zu beeintr\u00e4chtigen (\u00fcber ALTER TABLE). <\/p>\n
Unter den Argumenten f\u00fcr die Verwendung von SQLite wird die Verwendung des 64-Bit INTEGER-Typs zur Speicherung epochaler Zeit erw\u00e4hnt, der Einsatz von Indizes zur Reduzierung der Ein-\/Ausgabe durch selektive Abfragen anstelle einer vollst\u00e4ndigen Durchsuchung sowie die M\u00f6glichkeit, neue Felder ohne \u00c4nderung der bestehenden Datens\u00e4tze hinzuzuf\u00fcgen. Dar\u00fcber hinaus werden ACID-Transaktionen unterst\u00fctzt, der WAL-Modus (Write-Ahead Logging) f\u00fcr gleichzeitigen Zugriff ohne Sperren und die nachgewiesene Zuverl\u00e4ssigkeit von SQLite. <\/p>\n
F\u00fcr einen reibungslosen \u00dcbergang wird die Strategie \u201eDual-Write\u201c vorgeschlagen: <\/p>\n
\n
Programme, die in Bin\u00e4rdateien schreiben (login, sshd, sudo, cron usw.), werden so modifiziert, dass sie gleichzeitig sowohl in die alte Bin\u00e4rdatei als auch in die neue SQLite-Datenbank \u00fcber die entsprechende Bibliothek schreiben.\n
Neue Versionen der Tools (last2, lastb2, who2, lastlog2) werden entwickelt, die Daten aus SQLite-Datenbanken lesen und Indizes f\u00fcr eine schnelle Verarbeitung verwenden. \u00c4ltere Tools arbeiten weiterhin mit den bisherigen Dateien.\n
In einigen Jahren, wenn der \u00fcberwiegende Teil der Systeme aktualisiert wurde, kann die Unterst\u00fctzung f\u00fcr das Schreiben in alte Formate deaktiviert und alte Tools als veraltet erkl\u00e4rt werden. <\/ul>\n
Fragen, die zur weiteren Diskussion gestellt werden: <\/p>\n
\n
Die Sinnhaftigkeit einer Trennung in separate Bibliotheken oder einer Zusammenf\u00fchrung zu einer einzigen (z. B. libsession2).\n
Die Auswahl der Namen f\u00fcr Bibliotheken und Tools (historische Bezeichnungen beibehalten oder zu allgemeineren \u00fcbergehen).\n
Der Speicherort der Datenbankdateien (\/var\/lib\/ wie f\u00fcr Anwendungszust\u00e4nde oder \/var\/log\/ wie f\u00fcr Protokolle).\n
Der Mechanismus zur Versionierung des Schemas und zur Migration.\n