Y2K38 Bug and Rocky Linux

Introduction

Multiple UNIX systems utilize the 32-bit time_t type, which is part of the Standard C Library (libc). Come January 2038, the time_t type will run out of bits and therefore be unable to show the current time, affecting countless applications.

This article will dive into what the Y2K38 bug means for Rocky Linux and also quell any fears that the bug will affect the popular operating system.

Problem

On January 2038, the time_t type will not have enough bits available to store the current time, therefore causing multiple 32-bit reliant systems to fail.

An example is an ext4 filesystem with an inode size of 128. Once January 2038 hits, this then causes file timestamps to not be correctly recorded.

Symptoms

32-bit clocks will start to overflow and come back with false values. Example real-world applications that would be impacted are financial forecasts and long-term mortgage interest calculations.

Resolution

Thankfully, steps have already been taken to mitigate the Y2K38 issue. These include:

• time_t improvements in the Kernel 5.6 onwards, notably replacing time_t with safer alternatives.

⚠️ WARNING Caveats do exist however, including ensuring that user space is compiled with the 64-bit version of time_t and other considerations.

• XFS inode timestamps were increased in Kernel 5.10 to support dates up till the year 2486.

All current versions of Rocky Linux including 8, 9 and 10 include the above-mentioned patches in their kernels.

• For ext4 users - if you're running with an inode size of 128 or less, you will need to move the data to a fresh ext4 partition that has been configured with a higher inode size. It is possible to check the inode size, using the tune2fs tool like in the below example:

tune2fs -l /dev/sdb1 | grep "Inode size"
# In this case, the inode size is at 256, so this ext4 partition is not affected by the Y2K38 bug
Inode size:              256

Summary

The Y2K38 bug does not affect the latest versions of Rocky Linux 8, 9 or 10 at this time.

References & related articles

Arnd Bergmann - [GIT PULL] y2038: core, driver and file system changes
Darrick J. Wong - [GIT PULL] xfs: new code for 5.10, part 1
François Marier - Upgrading an ext4 filesystem for the year 2038
The Register - Linux 5.10 to make Year 2038 problem the Year 2486 problem
The Register - Need 32-bit Linux to run past 2038?