File system timestamps in future

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!

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.

… 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.

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!

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 …

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.

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 …

@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!

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

Only on 32-bit. :wink:

4 Likes

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

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