os: TestChtimes failures

[gopherbot]

#!watchflakes
default <- pkg == "os" && test == "TestChtimes"

Issue created automatically to collect these failures.

Example (log):

=== RUN   TestChtimes
=== PAUSE TestChtimes
=== CONT  TestChtimes
    os_test.go:1539: AccessTime didn't go backwards; was=2024-07-31 20:45:53.390326147 +0000 UTC, after=2024-07-31 20:45:53.394326118 +0000 UTC
--- FAIL: TestChtimes (0.00s)

— watchflakes

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
default <- pkg == "os" && test == "TestChtimes"

2024-07-31 19:54 gotip-linux-arm go@ab7435ab os.TestChtimes (log)

=== RUN   TestChtimes
=== PAUSE TestChtimes
=== CONT  TestChtimes
    os_test.go:1539: AccessTime didn't go backwards; was=2024-07-31 20:45:53.390326147 +0000 UTC, after=2024-07-31 20:45:53.394326118 +0000 UTC
--- FAIL: TestChtimes (0.00s)

— watchflakes

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
default <- pkg == "os" && test == "TestChtimes"

2024-08-02 14:33 gotip-linux-arm go@e7619216 os.TestChtimes (log)

=== RUN   TestChtimes
=== PAUSE TestChtimes
=== CONT  TestChtimes
    os_test.go:1539: AccessTime didn't go backwards; was=2024-08-02 19:24:19.187745351 +0000 UTC, after=2024-08-02 19:24:19.191745319 +0000 UTC
--- FAIL: TestChtimes (0.00s)

— watchflakes

[kolyshkin]

This seems like the same issue as #68663, which started happening on ARM since 2024-07-30.

[gopherbot]

Change https://go.dev/cl/604155 mentions this issue: [DO NOT MERGE] test chtimes failures on gotip-linux-arm

[dmitshur]

The linux-arm builder had a change in its environment on 2024-07-29, which coincidences with the timing of this test becoming flaky on that builder. The host VM started running additional security software in the background. The intent was not not affect the signal the builder provides, but it is possible that this test becoming flaky is related to that environment change rather than a change in the Go tree itself.

[kolyshkin]

The linux-arm builder had a change in its environment on 2024-07-29, which coincidences with the timing of this test becoming flaky on that builder. The host VM started running additional security software in the background. The intent was not not affect the signal the builder provides, but it is possible that this test becoming flaky is related to that environment change rather than a change in the Go tree itself.

So basically someone else is reading the file, which changes its atime.

This can probably be mitigated by having an empty file. inode(7) says:

Last access timestamp (atime)
stat.st_atime; statx.stx_atime

This is the file's last access timestamp. It is changed by file accesses, for example, by
execve(2), mknod(2), pipe(2), utime(2), and read(2) (of more than zero bytes). Other interfaces,
such as mmap(2), may or may not update the atime timestamp

If we make a file of 0 bytes, no one can read more than 0 bytes from it,
and the problem will disappear. Let me try that.

The alternative is to use a different location which is guaranteed to not be touched by the above mentioned security software (although that could defeat the purpose of that software).

[gopherbot]

Change https://go.dev/cl/604315 mentions this issue: os: fix Chtimes test flakes

[gopherbot]

Change https://go.dev/cl/604196 mentions this issue: [release-branch.go1.23] os: fix Chtimes test flakes

[dmitshur]

@gopherbot Please backport to Go 1.23 and 1.22. This is a test-only fix that makes a test more resilient against other programs possibly reading files in the background. It's also needed to fix test flakiness on the linux/arm builder where this started happening after a builder environment change.

[gopherbot]

Backport issue(s) opened: #68811 (for 1.22), #68812 (for 1.23).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[gopherbot]

Change https://go.dev/cl/605375 mentions this issue: [release-branch.go1.22] os: fix Chtimes test flakes