Year 2038 Issue in Rocky Linux Due to Power Outage
Introduction
The Year 2038 Problem (Y2K38) is a known issue affecting systems that rely on a 32-bit time_t value. On January 19, 2038, this value will overflow, causing time calculations to break on affected systems. While this might seem like a distant issue, some systems already exhibit symptoms, particularly when incorrect timestamps are recorded due to system clock inconsistencies. If files have access or modification timestamps set in the future, beyond a system’s expected date range, licensing mechanisms and other time-sensitive applications may fail. This article provides a resolution for this issue by identifying and correcting future-dated files, ensuring proper time synchronization, and preventing recurrence.
Problem
System files with modification, access, or creation timestamps set in the future, could cause issues. Such examples include licensing mechanisms to detect system clock discrepancy, leading to errors.
Symptoms
Running stat <file> shows files with the Access timestamp set in the future.
stat /etc/fstab
File: /etc/fstab
Size: 2295 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 67428642 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: system_u:object_r:etc_t:s0
Access: 2038-01-18 21:14:07.000000000 -0600 # <-- date in 2038
Modify: 2024-08-05 09:53:08.492859120 -0500
Change: 2024-08-05 09:53:08.493859164 -0500
Birth: 2024-08-05 09:53:08.492859120 -0500
Applications may fail to start due to a timestamp validation. We have seen problems while hosting a licensed application, observing the error System clock has been set back.
Resolution
Follow these steps to correct the timestamps:
1. Identify Files with Future Dates
To locate files with timestamps set in the future, run the following command:
# Replace YYYY-MM-DD with a realistic cut-off date for your server
find / -newermt "YYYY-MM-DD" -ls
Ensure that you review the list before proceeding.
2. Update Timestamps on Affected Files
Once you identify the files, you can update their timestamps using the touch command to reset the Access and Modify times to the current dates.
find / -newermt "YYYY-MM-DD" -exec touch {} \;
Alternatively, to set a specific date (e.g., 2023-11-04), use:
find / -newermt "YYYY-MM-DD" -exec touch -t 202311040000 {} \;
Handling Symbolic Links
By default, the touch command may not update timestamps of symbolic links. To ensure timestamps of symlinks are also modified, use:
find / -type l -newermt "YYYY-MM-DD" -exec touch -h {} \;
According to the touch man page:
`-h, --no-dereference` affects each symbolic link instead of any referenced file (useful only on systems that can change the timestamps of a symlink).
3. Verify Timestamps
After applying the changes, verify that timestamps have been corrected:
find / -ls
4. Restart the Affected Application
Once timestamps are corrected, restart the application:
sudo systemctl restart <your_application_service>
Root Cause
This issue is often caused by an incorrect system clock setting or a failing CMOS battery, which can lead to timestamps being improperly set.
To prevent recurrence:
- Check and replace the CMOS battery if needed.
- Ensure the system clock is correctly set.