File system timestamps in future

Support
1

I had the same issue, and it turned out that an access time of those directories in the furure caused the issue.

stat /etc/fonts/conf.d and stat /usr/share/fontconfig/conf.avail showed for me

  File: /etc/fonts/conf.d
  Size: 2654      	Blocks: 0          IO Block: 4096   directory
Device: 0,28	Inode: 24637       Links: 1
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2056-11-02 11:15:47.176668228 +0100
Modify: 2024-04-11 15:55:18.533282486 +0200
Change: 2024-04-11 15:55:18.533282486 +0200
 Birth: 2023-07-30 10:06:07.089497279 +0200

and

  File: /usr/share/fontconfig/conf.avail
  Size: 3598      	Blocks: 0          IO Block: 4096   directory
Device: 0,28	Inode: 24661       Links: 1
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2056-11-02 11:15:47.183334895 +0100
Modify: 2024-04-11 15:55:18.533282486 +0200
Change: 2024-04-11 15:55:18.533282486 +0200
 Birth: 2023-07-30 10:06:07.102830613 +0200

, respectively.

It was fixed by doing touch /etc/fonts/conf.d and touch /usr/share/fontconfig/conf.avail.

The issue was discussed there on the Arch Linux bugtracker: https://bugs.archlinux.org/task/70305, where the cause and solution were posted.

What wonders me is where those future access time stamps come from?

It seems to be an even bigger issue, where a lot of more access time once got messed up: http://www.mckinleyxie.com/blog/touch/

Regards!

2

Welcome to a preview of the year 2038 problem.

I has something to do with calculating unix timestamps (seconds-since-1970-01-01) and the size of the number generated.

Precisely what causes it - I have no idea - but I do know that in 2038 we run out of seconds with the current memory size.

3

ā€¦ interesting failure mode - who even thinks of that? :slightly_smiling_face:

could be file system related
or the system time (ntp?) was set incorrectly at some point

or:

Kernel: Manually compiled from kernel.org with custom patches

(from your shared system info)

Who knows? - I donā€™t.

I wonder whether this could have happened to me as well - I mount my ext4 file systems with the ā€œnoatimeā€ option.

4

But it should never had made it into packages distributed by a distribution, or if so they had to include some ā€œfixupā€ later (e.g. via an .install script that checks and touches wrongly dated directories).

Regards!

5

Are you sure that it came from a package installation/upgrade?
I guess not.
All it takes is file access with the wrong system time.
As well as to correct it, all it takes is touching the file ā€¦

6

No.

It seems to be an issue not only involving me. My kernel is just vanilla kernel with a patch to optimise for my specific CPU and a patch to increase the maximum kernel command line length. When all software which was distributed was ā€œOKā€ at all times I think this should not have happened. I guess. I donā€™t know. Something seemed to have been wrong at some point.

7

obviously :sunglasses:

the bug report that was linked is from someone from 3 years ago
ā€¦ itā€™s not even close to be a common occurrence ā€¦

8

@linux-aarhus, since I neither find a button to send you a direct message, nor I find a button to flag a post for moderation (I know discourse already, and usually such a button is to be found below each post), I reply here with the wish that you as a moderator delete this post after noticing to keep the thread clean.

I have noticed that you split up the thread, so you seem to have moderation rights. In my post I wrote a message to the moderators to fix the links, since the forum did not allow me to post links. I see that you have done one moderation action but not the other, so I guess you just overlooked it and I want to draw your attention to it:

Regards!

9

You can fix the links yourself - go back and edit your post.
Newly registered users are not allowed live links.
But it is quite good enough to post links like this - anyone interested can easily follow them
when they are formatted as text like this:

https://bugs.archlinux.org/task/70305

ā€¦ like you (partially) did.

ā€¦ highlight text - right click for context menu - open link in new window/tab ā€¦

1 Like
10

Only on 32-bit. :wink:

4 Likes
11

Yes - that is partly correctā€¦ I didnā€™t include that info because it is not only 32-bit systems but the memory allocation for timestamps.

Because of the way time is represented in Linux, a signed 32-bit number canā€™t support times beyond January 19, 2038 after 3:14:07 UTC. This Year 2038 (Y2038 or Y2K38) problem is about the time data type representation. The solution is to use 64-bit timestamps.

ā€“ Solving the Year 2038 problem in the Linux kernel | Opensource.com

I make heavily use of timestamps instead of DateTime constructs and this specific code I created 10y ago and uses 64bit integer to represent the date and time

1 Like
12

The main problem with knowing these issues so many years in advance is that all of the best memeā€™s will already have come and gone by the time the issues become topically mainstreamā€¦

2 Likes