Linux Sin Humo (Publicaciones sobre lastlog)

Una máquina de 64 bits no es inmune al 2038

sebelk — Sat, 25 Jul 2026 21:22:37 GMT

Las computadoras no guardan la fecha como la escribimos nosotros: guardan un número, y cada familia de sistemas eligió desde cuándo contarlo. En los sistemas Unix —Linux entre ellos— ese número es la cantidad de segundos transcurridos desde el 1 de enero de 1970. Ocupa un lugar de tamaño fijo, y cuando el lugar es chico, se llena. El lugar que se usó durante décadas se llena el 19 de enero de 2038. La mayoría de las máquinas de hoy ya no tienen ese límite; algunos archivos que esas mismas máquinas siguen escribiendo, sí.

Lo que sigue está medido, no citado: cada cifra sale de correr el programa en la máquina que se nombra —una Fedora 44 y las tres versiones de RHEL vigentes—. Una de esas mediciones muestra algo que la documentación no dice: en la familia RHEL, el número de versión de glibc no alcanza para saber en qué situación está un sistema, y aplicarlo como criterio da la respuesta equivocada en la versión más nueva.

Para lo principal —saber si tus máquinas están afectadas y por qué el número de versión no te lo contesta— alcanza con moverse en una terminal y leer la salida de un comando; eso está en Dónde está parada tu máquina y en el cierre. Los tramos con código en C y aritmética de enteros explican el mecanismo: dan el fundamento, no la conclusión, y quien no los recorra llega igual al final.

Ese número se guarda en un tipo de dato llamado time_t, y de cuántos bits tenga depende hasta qué fecha puede seguir contando. Un time_t de 32 bits con signo llega hasta enero de 2038 y ahí se le termina la cuenta. Ese es el problema del año 2038.

Que una máquina sea "de 64 bits" es una etiqueta que se repite bastante más de lo que se explica. Lo que mide 64 bits son los registros del procesador —los casilleros internos donde hace sus cuentas— y las direcciones con las que ubica cada byte de la memoria: es el tamaño del número que puede manejar de un saque. En Linux sobre esas máquinas, los tipos de dato que representan direcciones, tamaños y tiempos pasaron a medir 64 bits, y time_t es uno de ellos.

Por eso en un servidor x86-64 —cualquiera con procesador Intel o AMD de las últimas dos décadas— time_t mide 8 bytes, o sea 64 bits, y con ese ancho la cuenta no se agota en ningún plazo que nos importe. De ahí se deduce que la máquina está a salvo.

Pero ese ancho es una propiedad del procesador y de los programas que se compilan para él. Un archivo que ya está escrito no participa de eso. La deducción vale para lo que el sistema calcula mientras corre, y no vale para lo que queda guardado en disco. Un archivo no guarda un time_t: guarda una cantidad fija de bytes, en un orden fijo, que se decidió cuando se diseñó ese formato. Compilar el sistema para 64 bits no cambia esa decisión, porque agrandar un campo volvería ilegible todo lo que ya está escrito. Y /var/log/lastlog, donde queda registrado el último inicio de sesión de cada usuario, es uno de esos formatos.

Si compilás esto en cualquier Fedora o RHEL:

#include <lastlog.h>
#include <stdio.h>

int main(void) {
    struct lastlog ll;
    ll.ll_time = -1;
    printf("registro: %zu bytes | ll_time: %zu bytes, %s\n",
           sizeof ll, sizeof ll.ll_time,
           (ll.ll_time < 0) ? "con signo" : "sin signo");
    return 0;
}

No abre /var/log/lastlog ni necesita privilegios: lo único que hace es preguntarle al compilador qué forma tiene la estructura en esa máquina. sizeof se resuelve al compilar, así que las dos primeras cifras son el tamaño del registro y el del campo de la hora. La tercera sale de una prueba sencilla: se le asigna -1 al campo y se pregunta si quedó negativo. Si el campo tiene signo, -1 sigue valiendo -1; si no lo tiene, ese mismo patrón de bits se lee como 4.294.967.295 y la comparación da falso.

En una Fedora 44 con glibc 2.43 imprime:

registro: 292 bytes | ll_time: 4 bytes, sin signo

Tres datos en una sola línea. El registro mide 292 bytes: es el tamaño fijo del casillero que le corresponde a cada usuario dentro del archivo. De esos 292, solamente cuatro guardan la fecha del último acceso — cuatro bytes, en una máquina donde el sistema cuenta el tiempo con ocho. Y esos cuatro se están leyendo como un número que no admite valores negativos, que es el detalle que decide si la cuenta se agota en 2038 o llega hasta 2106.

Por qué el campo quedó en 32 bits

struct lastlog la define glibc, no shadow —el paquete de las herramientas de cuentas de usuario, useradd, chage, passwd, y del que en RHEL sale también el comando lastlog—. glibc es la biblioteca estándar de C del sistema: además de proveer las funciones con las que los programas le hablan al kernel, define las estructuras de datos que esos programas comparten entre sí. Por eso puede fijar el formato de un archivo que ella misma no escribe.

Su declaración actual tiene una condición:

#if __WORDSIZE_TIME64_COMPAT32
    __uint32_t ll_time;
#else
    __time_t ll_time;
#endif

__WORDSIZE_TIME64_COMPAT32 vale 1 en x86-64 y 0 en aarch64. Lo que expresa esa macro es que en x86-64 conviven programas de 64 bits con programas compilados para 32, y que unos y otros leen los mismos archivos del sistema. Si struct lastlog tuviera un ll_time de 8 bytes al compilarse a 64 bits y de 4 al compilarse a 32, cada uno vería una grilla distinta sobre el mismo /var/log/lastlog: donde el programa de 64 bits guardó la fecha, el de 32 leería la mitad de esa fecha, y a continuación tomaría la otra mitad como si fuera el principio del nombre de la terminal. glibc evita esa contradicción fijando el campo en 32 bits para las arquitecturas que arrastran esa compatibilidad, aunque el time_t de la plataforma sea de 64.

Es una decisión sobre el formato en disco, no sobre la aritmética del sistema. Por eso ser de 64 bits no alcanza. En aarch64, que nunca tuvo esa restricción, el mismo campo mide 8 bytes y el registro mide 296 en vez de 292 — con las consecuencias de portabilidad que ya vimos en las particularidades de lastlog.

El problema, tal como era

Hasta hace poco ese campo de 4 bytes era con signo, y de ahí sale la fecha famosa.

Con 32 bits se pueden anotar 4.294.967.296 valores distintos. Poder representar números negativos cuesta la mitad de ese total: se va en las fechas anteriores a 1970, y el valor positivo más grande que entra pasa a ser 2.147.483.647. Ese número no es una abstracción, son segundos, y 2.147.483.647 segundos son unos 68 años. Contados desde el 1 de enero de 1970, la cuenta llega hasta:

2038-01-19T03:14:07+00:00

Un segundo después desborda al valor negativo más chico. Y la ruta de lectura de shadow hace exactamente esto:

time_t ll_time;
...
ll_time = ll.ll_time;

Cuando ese valor de 32 bits pasa a una variable de 64, el compilador se ocupa de que siga significando lo mismo: si era negativo, rellena los bits nuevos de manera que siga siendo el mismo número negativo. Se llama extensión de signo, y acá tiene una consecuencia visible. El registro de un login ocurrido en 2038 no se mostraría como una fecha rara del futuro: se mostraría como

1901-12-13T20:45:52+00:00

La escritura tiene la falla simétrica, y llega por dos caminos. En el propio comando, cuando lastlog -S fija una entrada a mano, es una sola línea: ll.ll_time = NOW;, donde NOW es time((time_t *) 0). En cada inicio de sesión el que escribe es el módulo pam_lastlog, que hace lo mismo en dos pasos: time(&ll_time) sobre un time_t de 64 bits y last_login.ll_time = ll_time; sobre el campo de 32. En ambos casos el valor se trunca al guardarse.

Ese es el problema del 2038 en su forma concreta: no una abstracción sobre "sistemas viejos", sino un campo de un registro de 292 bytes que un RHEL 8 o un RHEL 9 escriben hoy en cada inicio de sesión.

Lo que hizo glibc

En la versión 2.40, publicada el 22 de julio de 2024, glibc cambió el tipo de ese campo. De las notas de la versión:

Architectures which use a 32-bit seconds-since-epoch field in struct lastlog, struct utmp, struct utmpx (such as i386, powerpc64le, rv32, rv64, x86-64) switched from a signed to an unsigned type for that field. This allows these fields to store timestamps beyond the year 2038, until the year 2106. Please note that applications are still expected to migrate off the interfaces declared in <utmp.h> and <utmpx.h> (except for login_tty) due to locking and session management problems.

Los mismos cuatro bytes, si ya no tienen que reservar la mitad de su capacidad para las fechas anteriores a 1970, llegan al doble: 4.294.967.295 segundos, otros 68 años. La cuenta se agota recién el:

2106-02-07T06:28:15+00:00

Y la extensión ahora es de ceros, no de signo: ll_time = ll.ll_time; sobre un __uint32_t produce un time_t positivo. El login de 2038 se lee como 2038.

Es la razón por la que el programa del principio imprime sin signo. Donde el campo siga declarado como int32_t imprimirá con signo, y eso —y no el número de versión de glibc, por los motivos que veremos al final— es lo que hay que medir antes de afirmar en qué situación está una máquina concreta.

Lo que ese cambio gana, y lo que no

El cambio se lee de dos maneras equivocadas: "el problema está resuelto" o "fue un parche inútil". No es ninguna de las dos.

Gana 68 años sin tocar el formato. El registro sigue midiendo 292 bytes, los offsets siguen siendo UID × 292, y un archivo escrito antes del cambio se sigue leyendo igual. De los 32 bits, hay uno —el de más peso— que en la lectura con signo es el que indica si el número es negativo. Todas las marcas anteriores a 2038 lo tienen en cero, así que esos mismos bytes significan lo mismo con o sin signo. Precisamente por eso el cambio era viable: no rompe nada de lo que ya está escrito.

No ensancha nada. El campo sigue teniendo 32 bits. La pared se corrió, no desapareció.

No es una maniobra exclusiva de glibc. MariaDB llegó a la misma pared y salió por la misma puerta: desde su versión 11.5, el tipo TIMESTAMP pasó de 2038 a 2106 reinterpretando como sin signo el mismo campo de cuatro bytes, sin tocar el formato en disco —"storage of timestamp is not affected by the change", dice el reporte— y solo en plataformas de 64 bits. Dos proyectos sin relación entre sí, con la misma restricción y la misma salida, hasta la misma fecha.

Cambia el significado de un valor sin que el archivo lo declare. Un registro con ese bit en uno significaba 1901 antes del cambio y significa 2038 o más después. En la práctica es inocuo, porque nadie tiene logins anteriores a 1970. Pero el archivo no tiene número de versión ni campo de tipo: nada adentro dice bajo qué interpretación fue escrito. Lo que decide es la glibc del binario que lo lee.

Por qué no bastaba con agrandar el campo

Si el campo pasara de 4 a 8 bytes, sizeof(struct lastlog) pasaría de 292 a 296. Pero el archivo no guarda el nombre del usuario: la identidad de cada registro es su posición, calculada como UID × sizeof(struct lastlog). Cambiar el tamaño del registro cambia todos los offsets a la vez. El archivo entero deja de ser legible, y no hay ningún campo adentro que permita detectar con qué tamaño fue escrito.

Un formato que indexa por posición no puede evolucionar su registro. Esa rigidez es el precio de poder saltar directo al registro de un usuario sin recorrer el archivo, y es lo que convierte al ensanchamiento del campo en un callejón sin salida. Pasar a unsigned fue la única maniobra posible sin romper compatibilidad, y funciona porque no cambia ni un byte del formato.

El arreglo de verdad: lastlog2

lastlog2 es un proyecto de Thorsten Kukuk integrado en util-linux 2.40. Abandona el archivo indexado por posición y guarda los datos en una base SQLite3 en /var/lib/lastlog/lastlog2.db, con una tabla cuya clave es el nombre de usuario:

CREATE TABLE Lastlog2(
    Name       TEXT PRIMARY KEY,
    Time       INTEGER,
    TTY        TEXT,
    RemoteHost TEXT,
    Service    TEXT
);

Escribir un login es un REPLACE INTO por nombre; leer es un SELECT por nombre. La marca de tiempo es un entero de 64 bits, y el tamaño de la base depende de la cantidad de usuarios con registro, no del UID más alto. Los datos los recolecta un módulo PAM, pam_lastlog2, que reemplaza a pam_lastlog.

Cada diferencia cierra uno de los problemas de la trilogía: la clave por nombre elimina las colisiones de UID; la base densa elimina el archivo disperso y su tamaño aparente descomunal; el entero de 64 bits elimina la fecha límite. Y como la identidad ya no es la posición, el esquema puede crecer: el campo Service no existía en struct lastlog y no podría haberse agregado.

Una aclaración cronológica: la justificación que da el propio proyecto —"the standard /var/log/lastlog implementation using lastlog.h from glibc uses a 32bit time_t"— se escribió cuando el campo todavía era con signo. El cambio de glibc corrió la fecha, no eliminó el motivo.

Fedora migró a lastlog2 como default del sistema en su versión 43. En una Fedora 44 el binario lastlog ya no existe, /var/log/lastlog queda como un archivo vacío, y rpm -ql shadow-utils | grep -i lastlog no devuelve nada. glibc, en cambio, sigue instalando <lastlog.h>: la estructura sobrevive al programa.

utmp y wtmp corren la misma suerte

El cambio de glibc 2.40 alcanzó también a struct utmp y struct utmpx, que sostienen /run/utmp, /var/log/wtmp y /var/log/btmp. Se verifica con el mismo programa, cambiando <lastlog.h> por <utmp.h>, la estructura por struct utmp y el campo por ut_tv.tv_sec:

sizeof(struct utmp) = 384 | ut_tv.tv_sec = 4 bytes, sin signo

La diferencia es que ahí no hay un lastlog2 esperando. La dirección de upstream, sostenida por el mismo autor, es dejar de escribir utmp y consultar a systemd-logind a través de las funciones sd_*() de libsystemd. Es un reemplazo más ambicioso que cambiar un backend de almacenamiento, y por eso avanza más despacio.

Dónde está parada tu máquina

Tres comprobaciones, ninguna destructiva.

La primera es el programa del principio, que lee la estructura tal como la ve el compilador de esa máquina. Si no hay compilador a mano, la declaración se puede mirar directamente en el archivo donde glibc la define, que viene en el paquete glibc-devel:

grep -A6 'struct lastlog' /usr/include/bits/utmp.h

La primera rama es la que se compila en x86-64 y en las demás arquitecturas que arrastran compatibilidad con programas de 32 bits: int32_t significa 2038, __uint32_t significa 2106. La segunda rama, __time_t, es la de aarch64, donde el campo mide 8 bytes y el problema no existe.

La segunda:

ls -l /var/lib/lastlog/lastlog2.db

Si existe, el sistema ya está en el esquema SQLite y el problema no aplica.

La tercera:

ls -ls /var/log/lastlog

Si informa un tamaño aparente grande y una ocupación mínima, el archivo indexado por UID sigue vivo, y con él tanto la fecha límite de su campo de 32 bits como todo lo que ya sabemos sobre no rotarlo y no meterlo en un backup a nivel de archivo.

Lo que conviene no hacer es deducirlo del número de versión. rpm -q glibc parece suficiente, porque el cambio es de 2.40, pero las distribuciones retroportan. En la familia de RHEL el número de versión no alcanza para deducir la respuesta:

Sistema	glibc	Campo	Límite
RHEL 8.10	2.28	`int32_t`	2038
RHEL 9.8	2.34	`int32_t`	2038
RHEL 10.2	2.39	`__uint32_t`	2106

RHEL 10 tiene el arreglo sin haber llegado a 2.40: Red Hat lo retroportó a su glibc 2.39 en mayo de 2024, en la entrada 2.39-12 del changelog del paquete. Quien aplique el criterio de la versión sobre RHEL 10 va a concluir que está expuesto a 2038, y no lo está. Las tres filas salen de correr el programa dentro de ubi8, ubi9 y ubi10, que llevan la glibc de cada RHEL.

Lo mismo en una máquina de 32 bits

Nada de esto es propio de RHEL. En una Debian 12 sobre i386 el mismo grep devuelve int32_t. Y ahí el campo de cuatro bytes no está solo: en una máquina de 32 bits todos los programas guardan el tiempo en cuatro bytes, no únicamente los que tocan lastlog. Con el reloj puesto más allá de 2038, esa máquina ni siquiera termina de arrancar: el programa que le entrega el control al sistema definitivo pide los datos de un directorio, la fecha no entra en el campo, y el arranque se queda en el shell de emergencia.

El disco está sano y el kernel también: el propio arranque informa que el sistema de archivos está limpio, con sus 37.655 archivos en su lugar. Lo único que pasó es que una fecha dejó de entrar en un campo de cuatro bytes.

Y esa máquina va a seguir así: cuando Debian pasó sus arquitecturas de 32 bits a tiempos de 64 bits, en la versión 13, dejó a i386 deliberadamente afuera. La razón es que i386 se mantiene para correr binarios viejos, y cambiar el tamaño de los tipos rompería justamente esa compatibilidad. De todos modos, la diferencia con lastlog se sostiene: este es un problema que se arregla recompilando los programas —Debian lo hizo para el resto de sus arquitecturas de 32 bits— y el de lastlog no, porque recompilar no cambia lo que ya está escrito en disco.

ls -l /var/lib/lastlog/lastlog2.db

Si existe, el sistema ya está en el esquema SQLite y el problema no aplica.

ls -ls /var/log/lastlog

Para qué se corrió la pared

Los 68 años que agregó el cambio no son para llegar a 2106. Nadie va a estar leyendo /var/log/lastlog en 2106: el reemplazo ya existe, ya es el default en Fedora, y no hay un tercer truco disponible. Cuatro bytes sin signo llegan a 4.294.967.295 y ahí se termina — no queda nada que reinterpretar. Correr la época (epoch), empezar a contar desde 2038 en vez de desde 1970, tampoco sirve: a diferencia del cambio de signo, haría que cada valor ya escrito significara otra cosa, y el archivo no tiene adentro ningún campo que diga bajo qué época fue guardado.

Los 68 años son para las máquinas que ya están andando. Una RHEL 8 instalada este año va a seguir en producción bien entrados los 2030, con su campo con signo y su fecha límite en 2038 — que está a doce años, no a ochenta. RHEL 9 está en la misma situación. Para esas máquinas el problema no es lejano: es la vida útil del servidor que alguien está montando ahora.

Eso es lo que hace el cambio de glibc. No arregla el formato, que sigue sin poder crecer. Le da al reemplazo el tiempo de propagarse al ritmo al que se reemplazan los servidores, en lugar del ritmo de una urgencia.

Fuentes y más recursos

glibc 2.40 — anuncio de la versión — el párrafo que documenta el cambio de signed a unsigned en el campo de época de struct lastlog, utmp y utmpx, y el corrimiento del límite a 2106.
Y2038, glibc and utmp/utmpx on 64bit architectures — Thorsten Kukuk explica por qué una máquina de 64 bits no es inmune: el time_t de 32 bits que sobrevive en los formatos de utmp y lastlog.
glibc.spec de CentOS Stream 10 — el changelog del paquete, donde consta el retroporte del cambio a la glibc 2.39 de RHEL 10: "Use unsigned types in <utmp.h>/<utmpx.h>".
MDEV-32188 — make TIMESTAMP use whole 32-bit unsigned range — el mismo movimiento en MariaDB: de 32 bits con signo a 32 bits sin signo, de 2038 a 2106, sin cambiar el formato de almacenamiento. Corregido en 11.5.1.
Proyecto lastlog2 — el reemplazo Y2038-safe con backend SQLite3: liblastlog2, la CLI y pam_lastlog2.
util-linux 2.40 — Release Notes — la integración de lastlog2 y pam_lastlog2 en util-linux.
Fedora Change: Migrate to lastlog2 — la adopción de lastlog2 como default del sistema, desde Fedora 43.

La serie

Parte	Post	De qué trata
1	Archivos sparse en Linux	Los agujeros: cómo un archivo declara un tamaño y ocupa otro
2	Particularidades de lastlog	El UID como posición dentro del archivo, y todo lo que se desprende de esa decisión
3	Una máquina de 64 bits no es inmune al 2038 (estás acá)	El campo de fecha de 32 bits, lo que hizo glibc y el reemplazo

Particularidades de lastlog

sebelk — Fri, 17 Jul 2026 10:00:00 GMT

En un RHEL 8 recién instalado, /var/log/lastlog no llama la atención. En el mismo RHEL 8 unido a un dominio por SSSD, después de que un solo usuario del dominio inicie sesión, ls -l puede informar un archivo de cientos de gigabytes. du -h sobre ese mismo archivo devuelve unos pocos kilobytes.

El archivo es sparse, y eso explica la diferencia entre los dos números. Lo que explica por qué es sparse es una sola línea de código.

El UID es la dirección

/var/log/lastlog guarda el último inicio de sesión de cada usuario. No tiene índice, ni cabecera, ni claves, ni base de datos. La posición del registro dentro del archivo es el UID. En shadow-utils el cálculo aparece idéntico en la ruta de lectura y en la de escritura:

offset = (off_t) pw->pw_uid * sizeof (ll);

El archivo se trata como un arreglo en disco cuyo índice es el UID, exactamente igual que array[i] vive en base + i * sizeof(elemento). Para leer el último login de cualquier usuario se hace un fseeko a ese offset y se lee un registro. Acceso directo, sin parsear nada, sin mantener una estructura auxiliar.

El (off_t) merece atención. La conversión está antes de la multiplicación, y no es un detalle cosmético: fuerza a que la operación se haga en 64 bits. Si se multiplicara primero en 32 bits, un UID grande desbordaría antes de convertir. Un UID de 20 000 000 por 292 bytes da unos 5840 millones, que no entra en 32 bits. El offset resultante apuntaría a cualquier parte.

El registro, y por qué mide lo que mide

La struct lastlog no la define shadow: viene de glibc —se declara en <bits/utmp.h>, que un programa obtiene incluyendo <lastlog.h>—. Son tres campos:

Offset	Campo	Tamaño	Contenido
0	`ll_time`	4 bytes	segundos desde epoch del último login
4	`ll_line`	32 bytes	terminal: `pts/0`, `tty1`
36	`ll_host`	256 bytes	host remoto
	total	292 bytes

Ese 292 no es universal, y ahí hay una particularidad que se pasa por alto. El campo ll_time está definido bajo una condición:

#if __WORDSIZE_TIME64_COMPAT32
    __uint32_t ll_time;
#else
    __time_t ll_time;
#endif

En x86-64 esa macro vale 1, ll_time ocupa 4 bytes y el registro mide 292. En aarch64 vale 0, ll_time pasa a ser un __time_t de 8 bytes, y el registro mide 296. Mismo archivo, mismo programa, distinta grilla.

La consecuencia práctica es que /var/log/lastlog no es portable entre arquitecturas. Copiado de un x86-64 a un aarch64, cada registro se lee corrido, y no hay número de versión ni campo de tipo que permita detectarlo. Es un volcado binario de una estructura de C, con la endianness y el padding de la máquina que lo escribió. Ese ll_time condicional además arrastra el problema del año 2038.

El nombre del usuario no está guardado

Mirá de nuevo la tabla: hay tiempo, terminal y host. No hay nombre. La identidad del usuario no está en el registro, está en la posición del registro. Si el offset es UID × 292, entonces UID = offset / 292, y eso es todo lo que el archivo sabe sobre quién es quién.

De ahí sale un comportamiento que sorprende cuando aparece. Si dos entradas de /etc/passwd comparten UID:

alice:x:1000:1000::/home/alice:/bin/bash
bob:x:1000:1000::/home/bob:/bin/bash

las dos cuentas comparten físicamente el mismo registro. lastlog recorre /etc/passwd con getpwent() y procesa cada entrada por separado, así que imprime dos filas, con nombres distintos y exactamente la misma fecha, la misma terminal y el mismo host. Si entró alice, la salida muestra a bob con esa fecha.

En escritura es peor de razonar. lastlog -S -u bob hace getpwnam("bob") para obtener el UID, y desde ahí todo el trabajo se hace por UID. Lo que se actualiza es el registro del UID 1000, indistinguible del de alice.

No es un defecto de lastlog. Es lo que significa tratar el UID como identidad, que es exactamente lo que hace el kernel: los permisos, la propiedad de los archivos y las credenciales de proceso van por UID. Los nombres son etiquetas en /etc/passwd. Dos nombres con el mismo UID son el mismo usuario a todos los efectos, y lastlog hereda esa ambigüedad en lugar de inventarse una propia.

Un corolario del mismo diseño: como lastlog recorre passwd en vez de recorrer el archivo, los registros de usuarios ya borrados siguen físicamente en disco pero no se listan. Y si nsswitch está respaldado por SSSD contra un directorio de decenas de miles de usuarios, ese getpwent() enumera toda la base remota. El cuello de botella pasa a ser NSS, no el archivo.

Leer es seguro; escribir es lo que infla

Hay una asimetría en el código que determina cuándo el archivo crece.

En lectura, antes de posicionarse se comprueba que el registro entre dentro del archivo:

if (offset + sizeof (ll) <= statbuf.st_size)

Si el UID cae más allá del final, no se lee nada: la estructura se llena de ceros con memzero y se imprime **Never logged in**. Consultar el lastlog de un usuario con UID enorme no agranda el archivo. Y como un agujero también se lee como ceros, el código trata igual al "usuario dentro de un agujero" y al "usuario fuera del archivo". Ambos son lo mismo: nadie inició sesión.

En escritura no hay ninguna comprobación de límites: se hace fseeko al offset y se escribe. Un solo login —o un solo lastlog -S -u <usuario>— con un UID alto extiende el archivo hasta ese offset y crea el agujero intermedio.

Por eso el tamaño aparente del archivo no depende de cuántos usuarios tenés, sino del UID más alto que alguna vez haya escrito un registro.

Los números con un directorio corporativo

Con cuentas locales, los UID rondan el millar y el archivo es irrelevante. Con Active Directory o LDAP vía SSSD y mapeo algorítmico de SID a POSIX ID, el panorama cambia. Los defaults de SSSD ubican el rango de UID mapeados entre ldap_idmap_range_min = 200000 y ldap_idmap_range_max = 2000200000, repartido en slices de 200000, y el slice que le toca a cada dominio se elige por hash de su SID. Es decir: el UID de un usuario de dominio puede caer en cualquier punto de ese rango.

A 292 bytes por registro:

UID que inició sesión	Tamaño aparente
1 000	285 KiB
1 000 000	278 MiB
100 000 000	27,2 GiB
145 000 000	39,4 GiB
2 000 199 999 (tope del rango)	543,9 GiB

El archivo visto como un arreglo en disco: cada login escribe su registro en offset = UID × 292, y los agujeros entre los UID reales no ocupan disco. La frontera administrativa entre cuentas de sistema y de persona (UID 999/1000) cae dentro de un mismo bloque; un solo login de dominio salta a diez millones de bloques de distancia y fija el tamaño aparente.

El espacio real en disco sigue siendo proporcional a la cantidad de registros escritos. El disco no se llena. Lo que se rompe es todo lo que lea el archivo secuencialmente.

El manual lo dice sin vueltas:

The lastlog file is a database which contains info on the last login of each user. You should not rotate it. It is a sparse file, so its size on the disk is usually much smaller than the one shown by "ls -l" (which can indicate a really big file if you have in passwd users with a high UID). You can display its real size with "ls -s".

Rotar el archivo con logrotate usando copy o copytruncate implica leerlo y reescribirlo. Los 543,9 GiB aparentes se convierten en 543,9 GiB reales.

La misma advertencia aplica al backup a nivel de archivo. La receta es excluir /var/log/lastlog del job, y si hace falta conservar el dato de auditoría, volcarlo a un archivo normal:

lastlog > /var/backups/lastlog.txt

Ese archivo pesa lo que corresponde al padrón real de usuarios. El mismo criterio aplica a /var/log/faillog, que no comparte el formato del registro pero sí el esquema: su código calcula offset = (off_t) uid * sizeof (fl); y produce un archivo disperso por la misma razón.

Por qué `wtmp` no tiene este problema

lastlog y wtmp suelen mencionarse juntos, y son modelos opuestos.

lastlog es una tabla de estado: un slot por usuario, indexado por UID, que se sobrescribe en cada login. Responde "¿cuándo entró por última vez cada usuario?" con acceso directo, y no guarda historia.

wtmp es un libro de contabilidad: registros struct utmp que se agregan al final, en orden cronológico. Cada login, logout, arranque o cambio de runlevel suma un registro. Responde "¿qué pasó en este sistema y en qué orden?".

	`lastlog`	`wtmp`
Modelo	arreglo indexado por UID	log secuencial, append-only
Escritura	sobrescribe el slot del UID	agrega un registro al final
¿Guarda el nombre?	no, es la posición	sí, en `ut_user`
Historial	solo el último login	todos los eventos
Tamaño	∝ UID máximo (con agujeros)	∝ cantidad de eventos (denso)
¿Sparse?	sí	no
¿Rotar?	no	sí, con `logrotate`

struct utmp mide 384 bytes y sí incluye el nombre (ut_user) y un campo ut_type que clasifica el evento. Por eso last puede reconstruir sesiones completas y mostrar reinicios, algo que lastlog no puede hacer ni en principio. Crece linealmente con los eventos, así que hay que rotarlo; no tiene agujeros, así que se puede.

Visto desde arriba, lastlog es un índice materializado del "último USER_PROCESS por usuario" que podría derivarse recorriendo wtmp. La ganancia de ese índice es el acceso O(1). El precio es el archivo disperso.

Dónde está esto hoy

En la familia Enterprise Linux el esquema sigue siendo el clásico. RHEL 8, 9 y 10 —y sus derivados Rocky, Alma y Oracle Linux— empaquetan el binario lastlog en shadow-utils (4.6, 4.9 y 4.15 respectivamente) y mantienen pam_lastlog en la pila de PAM. El archivo indexado por UID es lo que hay, y lo que hay que recordar excluir del backup y de la rotación.

RHEL 10 tiene una particularidad que conviene no dar por sentada. Trae util-linux 2.40, que es la versión donde upstream incorporó liblastlog2, pero el paquete se compila con --disable-liblastlog2: no hay binario lastlog2 ni módulo pam_lastlog2 en los repositorios. Tener la versión no implica tener la funcionalidad.

Lo que sí cambió en RHEL 10 es el anuncio. Red Hat declaró deprecadas las interfaces utmp y utmpx de glibc y avisó que se eliminan en RHEL 11. El motivo que da es el desbordamiento de su contador en 2106; el de lastlog, con su ll_time de 32 bits con signo, vence bastante antes.

Fedora ya hizo el cambio. Desde Fedora 43 el default del sistema es lastlog2, con pam_lastlog2 en la pila de PAM. En una Fedora 44 al día, el paquete shadow-utils ya no provee un binario lastlog; el que hay es lastlog2, y viene de util-linux. Los datos están en /var/lib/lastlog/lastlog2.db, una base SQLite indexada por nombre de usuario, y /var/log/lastlog queda como un archivo vacío de 0 bytes.

El esquema de esa base dice, en una línea, todo lo que cambió:

Name TEXT PRIMARY KEY: el nombre del usuario está guardado y es la clave. La identidad dejó de ser la posición, que es justamente lo que hacía sparse al archivo viejo y lo que provocaba las colisiones de UID. Sin índice posicional no hay agujeros que llenar ni tamaño aparente que explicar. Time INTEGER es un entero de 64 bits, sin la condicional por arquitectura ni el tope de 2038. Y aparece un campo que la struct no tenía: Service, el servicio PAM que originó la sesión.

En cualquiera de los dos casos, qué esquema tenés a mano se comprueba con un comando:

rpm -ql shadow-utils | grep -i lastlog

Fuentes y más recursos

lastlog(8) — la fuente de la advertencia "You should not rotate it" y de la nota sobre el archivo sparse y ls -s.
utmp(5) — define struct utmp, sus campos ut_type y ut_user, y la diferencia entre /run/utmp (sesiones activas) y /var/log/wtmp (historial).
man 5 sssd-ldap — sección ID MAPPING: los defaults ldap_idmap_range_min, ldap_idmap_range_max y ldap_idmap_range_size que ubican los UID de dominio en el rango alto.
Fedora Change: Migrate to lastlog2 — la migración a lastlog2 como default del sistema, desde Fedora 43.
RHEL 10 — Deprecated functionality — la deprecación de las interfaces utmp y utmpx de glibc, con la eliminación anunciada para RHEL 11.
util-linux.spec de CentOS Stream 10 — el --disable-liblastlog2 que deja a RHEL 10 sin lastlog2 pese a tener util-linux 2.40.
pam_lastlog2(8) — el módulo PAM que reemplaza a pam_lastlog: Y2038-safe y con backend SQLite3, en util-linux desde 2.40.

La serie

Parte	Post	De qué trata
1	Archivos sparse en Linux	Los agujeros: cómo un archivo declara un tamaño y ocupa otro
2	Particularidades de lastlog (estás acá)	El UID como posición dentro del archivo, y todo lo que se desprende de esa decisión
3	Una máquina de 64 bits no es inmune al 2038	El campo de fecha de 32 bits, lo que hizo glibc y el reemplazo

Linux Sin Humo (Publicaciones sobre lastlog)

Una máquina de 64 bits no es inmune al 2038

Por qué el campo quedó en 32 bits

El problema, tal como era

Lo que hizo glibc

Lo que ese cambio gana, y lo que no

Por qué no bastaba con agrandar el campo

El arreglo de verdad: lastlog2

utmp y wtmp corren la misma suerte

Dónde está parada tu máquina

Lo mismo en una máquina de 32 bits

Para qué se corrió la pared

Fuentes y más recursos

La serie

Particularidades de lastlog

El UID es la dirección

El registro, y por qué mide lo que mide

El nombre del usuario no está guardado

Leer es seguro; escribir es lo que infla

Los números con un directorio corporativo

Por qué wtmp no tiene este problema

Dónde está esto hoy

Fuentes y más recursos

La serie

Por qué `wtmp` no tiene este problema