{"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\/pl\/blog\/news\/predlozhenie-po-perevodu-sistemnyh-logov-lastlog-btmp-utmp-i-wtmp-na-ispolzovanie-sqlite","title":{"rendered":"Propozycja przet\u0142umaczenia systemowych log\u00f3w lastlog, btmp, utmp i wtmp na u\u017cycie SQLite","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Na li\u015bcie dyskusyjnej linux-api om\u00f3wiono propozycj\u0119 (RFC) zast\u0105pienia przestarza\u0142ych binarnych format\u00f3w dziennik\u00f3w systemowych lastlog, btmp, utmp i wtmp nowymi, wsp\u00f3\u0142dzielonymi bibliotekami, kt\u00f3re wykorzystuj\u0105 SQLite jako backend. Inicjatywa ma na celu rozwi\u0105zanie kumuluj\u0105cych si\u0119 problem\u00f3w, w tym przepe\u0142nienia 32-bitowych licznik\u00f3w czasu w 2038 roku, braku elastyczno\u015bci, niskiej wydajno\u015bci zapyta\u0144 oraz braku atomowo\u015bci przy zapisie. <\/p>\n
Obecnie w systemie Linux do przechowywania danych o sesjach i pr\u00f3bach uwierzytelnienia u\u017cywane s\u0105 nast\u0119puj\u0105ce pliki binarne o sta\u0142ej strukturze: <\/p>\n
Format danych tych plik\u00f3w zosta\u0142 opracowany kilka dziesi\u0119cioleci temu i ma szereg fundamentalnych ogranicze\u0144: <\/p>\n
\n
Pole «tv_sec» w strukturze «utmpx» oraz pole «ll_time» w «lastlog» maj\u0105 typ «int32_t», a warto\u015b\u0107 licznik\u00f3w czasu, na podstawie kt\u00f3rej wyst\u0105pi przepe\u0142nienie, jest dat\u0105 19 stycznia 2038 roku. Z powodu wymaga\u0144 dotycz\u0105cych zgodno\u015bci ABI, nawet w systemach 64-bitowych, te pola pozostaj\u0105 32-bitowe, w zwi\u0105zku z czym problem dotknie wszystkich instalacji systemu Linux.\n
Sta\u0142y rozmiar wpis\u00f3w nie pozwala na dodawanie nowych p\u00f3l (na przyk\u0142ad identyfikator kontenera, nazwa us\u0142ugi, adres IP) bez ca\u0142kowitej wymiany formatu i rekompilacji wszystkich narz\u0119dzi.\n
Narz\u0119dzia last, lastb, who i lastlog musz\u0105 liniowo przeszukiwa\u0107 zawarto\u015b\u0107 plik\u00f3w. Przy du\u017cych rozmiarach dziennik\u00f3w, bez u\u017cycia indeks\u00f3w, kt\u00f3re umo\u017cliwiaj\u0105 efektywne filtrowanie wpis\u00f3w, obci\u0105\u017cenie systemu wej\u015bcia\/wyj\u015bcia oraz op\u00f3\u017anienia podczas wykonywania zapyta\u0144 staj\u0105 si\u0119 nieakceptowalne.\n
Zapis do pliku binarnego nie jest operacj\u0105 atomow\u0105. W przypadku awarii zapis mo\u017ce zosta\u0107 cz\u0119\u015bciowo uszkodzony.\n
Aby unikn\u0105\u0107 konflikt\u00f3w przy jednoczesnym zapisie do dziennik\u00f3w przez wiele proces\u00f3w (na przyk\u0142ad sshd i login), stosuje si\u0119 blokady flock, kt\u00f3re nie gwarantuj\u0105 atomowo\u015bci i mog\u0105 prowadzi\u0107 do zakleszcze\u0144. <\/ul>\n
Autor RFC proponuje ca\u0142kowite porzucenie binarnych format\u00f3w na rzecz wyspecjalizowanych bibliotek wsp\u00f3\u0142dzielonych, wykorzystuj\u0105cych SQLite. Dla ka\u017cdego typu dziennik\u00f3w tworzona jest osobna biblioteka z jednolitym interfejsem C: liblastlog2, libbtmp2, libutmp2 i libwtmp2. Wszystkie biblioteki pracuj\u0105 z baz\u0105 danych, kt\u00f3rej schemat zawiera 64-bitowe znaczniki czasowe (typ INTEGER) i indeksy wed\u0142ug u\u017cytkownika i czasu. Istnieje mo\u017cliwo\u015b\u0107 dodawania nowych p\u00f3l bez naruszania kompatybilno\u015bci (za pomoc\u0105 ALTER TABLE). <\/p>\n
W\u015br\u00f3d argument\u00f3w na rzecz u\u017cycia SQLite wspomina si\u0119 o wykorzystaniu 64-bitowego typu INTEGER do przechowywania czasu epokowego, zastosowaniu indeks\u00f3w w celu zmniejszenia I\/O dzi\u0119ki selektywnemu dost\u0119powi do rekord\u00f3w zamiast pe\u0142nego skanowania, mo\u017cliwo\u015bci dodawania nowych p\u00f3l bez zmiany istniej\u0105cych rekord\u00f3w, wsparciu dla transakcji ACID, trybie WAL (Write-Ahead Logging) dla r\u00f3wnoleg\u0142ego dost\u0119pu bez blokad oraz sprawdzonej niezawodno\u015bci dzia\u0142ania SQLite. <\/p>\n
Programy, kt\u00f3re zapisuj\u0105 do plik\u00f3w binarnych (login, sshd, sudo, cron itp.), zostan\u0105 zmodyfikowane w taki spos\u00f3b, aby jednocze\u015bnie zapisywa\u0142y dane zar\u00f3wno w starym pliku binarnym, jak i w nowej bazie danych SQLite za po\u015brednictwem odpowiedniej biblioteki.\n
Opracowywane s\u0105 nowe wersje narz\u0119dzi (last2, lastb2, who2, lastlog2), kt\u00f3re odczytuj\u0105 dane z baz SQLite, wykorzystuj\u0105c indeksy do szybkiej pracy. Stare narz\u0119dzia nadal dzia\u0142aj\u0105 z wcze\u015bniejszymi plikami.\n
Za kilka lat, gdy zdecydowana wi\u0119kszo\u015b\u0107 system\u00f3w zostanie zaktualizowana, wsparcie dla zapisu w starych formatach mo\u017ce zosta\u0107 wy\u0142\u0105czone, a stare narz\u0119dzia — og\u0142oszone przestarza\u0142ymi. <\/ul>\n
Pytania, kt\u00f3re nale\u017cy podda\u0107 dalszej dyskusji: <\/p>\n
\n
Celowo\u015b\u0107 podzia\u0142u na osobne biblioteki lub po\u0142\u0105czenia w jedn\u0105 (na przyk\u0142ad libsession2).\n
Wyb\u00f3r nazw dla bibliotek i narz\u0119dzi (zachowa\u0107 historyczne nazwy czy przej\u015b\u0107 do bardziej og\u00f3lnych).\n
Lokalizacja plik\u00f3w baz danych (\/var\/lib\/ jak dla stanu aplikacji lub \/var\/log\/ jak dla log\u00f3w).\n
Mechanizm wersjonowania schemat\u00f3w i migracji.\n