Y2038, glibc and wtmp on 64bit architectures

2 minutes
March 30, 2023

On January, 19th 2038 at 03:14:07 UTC the 32bit time_t counter will overflow. For more information about this I suggest to start with the wikipedia Year 2038 problem article. That problem is long known and several groups are working on a solution for 32bit systems, but many people don’t know that pure 64bit systems could be affected, too.

The general statement so far has always been that on 64bit systems with a 64bit time_t you are safe with respect to the Y2038 problem. But glibc uses for compatibility with 32bit userland applications 32bit time_t in some places even on 64bit systems. More information can be found in my previous blog Y2038, glibc and utmp/utmpx on 64bit architectures.

In this article I will present a generic solution for wtmp.

What is wtmp actually good for? From the manual page:

The  wtmp  file records all logins and logouts.

What are the problems?

There is one main problem with with with glibc on e.g. x86-64:

  1. A 32bit time_t field is used for the time, which will overflow in 2038

Who is really using wtmp today?

There are several applications writing wtmp entries, all are to login to a system:

  • gdm
  • login
  • sddm
  • sshd

Additional systemd writes reboot/shutdown entries to /var/log/wtmp.

Who is using (means reading) the wtmp entries?

  • last
  • last
  • last
  • lslogins

So in the end, there is more or less only one tool really consuming the wtmp entries.


The login and logout times will be stored in a sqlite3 database. There is a library libwtmpdb.so which provides a Y2038 secure API on all architectures (32bit and 64bit). Additional, there is a PAM module pam_wtmpdb.so and a binary wtmpdb.

The module allows to use this functionality in any PAM aware application. Today every application used for login and authentication uses PAM, so this should be no problem. The wtmpdb binary will replace last and some more features to e.g. to store boot and shutdown times.

Were other alternatives evaluated?

Yes, but in the end, sqlite was the most widespread, robust, well maintained database library available today. And hiding everything in a library is the only future proof solution, to be flexible in the future and to maintain the code only in one place.

wtmpdb implementation

Source code

The source code for the libwtmpdb library, PAM module and application can be found in the wtmpdb repository on github.

Further documentation