Issue running installation for perl 5.34.0 Time::HiRes test fails on RHEL 8.5 #19321
Comments
Point of clarification: I think you may have the above versions backward. 1.9764 is the most recent CPAN release (Aug 10 2020): 1.9767 was bundled with perl-5.34.0: Also, note that any changes we would make to address your concerns would be initiated in Perl 5 blead, where we are currently up to 1.9769. |
|
@MaintainUplift, the problematic file, Would you be able to configure and build Thank you very much. |
jkeenan
changed the title
|
Here's what happened in the Configure and Build stages: full Configure and Build output[edited 2022-02-10 hvds to collapse long output] |
I should have been more specific. All we really need at this point is the output from: ... which can be issued from the top-level directory of your git checkout. |
|
Here are the results: Thanks extremely much for your kind assistance. [Edited 2022-02-10 hvds to fix formatting] |
|
@MaintainUplift, two updates: First, to facilitate debugging we have just updated Second, I've been trying to wrap my head around what The program goes through 5 cycles, in each of which it:
... further tests not relevant to this issue. P5P: Is this an accurate description of what However, when I start to add debugging code to ... and I now re-run the test program, I get: Note that the My investigation suggests that if I But I don't know whether this is related to the OP's problem or not. |
|
Ok, as instructed, I pulled a blead copy to local winbox then zipped it and sent it to the server. One note, before I could start I had to run Use of uninitialized value $check in hash element at ./regen/embed_lib.pl line 118, line 3. |
[snip] @MaintainUplift, I have to admit that I think you're introducing complications into this process. Your Subject line and initial post clearly indicate you're trying to diagnose a problem you experience on Linux. Why than are you introducing a Windows box to the diagnostic process? |
|
I am not actually "introducing" a windows box here. The ONLY way I can get the blead so that I can then load it to the linux system is via these means. I cannot pull it directly to the target system because it's firewalled all to heck (and git is not and will not be installed on it anyway). I did not touch any of the code, so I was QUITE surprised to find that I had to run dos2unix on it. All I did was pull it, zip, and sftp it to the box and unzip it. If there's some other Special Linux Only pull process, I am eager to learn it. Many thanks for your continued assistance. |
|
Update: Yep, I'm ignorant. But ignorant NO LONGER - and here's a tip for everyone else: I was not aware that using 7zip to zip a collection of texts would introduce DUMB THINGS like changing the line endings to something other than what it came with. SO: DO NOT USE 7zip TO ZIP ANYTHING YOU ARE SENDING TO A NIX ENVIRONMENT! By the way: Thanks to your extremely fine support efforts the issue has been resolved: Thanks once again. [Edited 2022-02-10 hvds to fix formatting] |
|
Hi Team, We're also facing same, could some one help on this towards resolutions. |
This ticket was closed once the original poster better understood the problem. If you are experiencing a problem, please open a new ticket per the guidelines specified under the green "New Issue" button at https://github.com/Perl/perl5/issues. |
|
It doesn't seem like anything was done to actually fix this issue, but that running the test enough times eventually resulted in a clean run. |
|
I was able to reproduce this issue when installing perl 5.34.1 on Ubuntu 18.04 using perlbrew. This was using an Azure Hyper-V VM. When running on a Hyper-V gen2 VM on Windows 10 I was not able to reproduce. I think this issue could be related to something Azure is doing with time and/or filesystem access. Filesystem is ext4 mounted with relatime in both situations. Some debug output has been collected here: https://gist.github.com/robinsmidsrod/8649c2e2056ce0e4440ee7e01b6667e2 |
The filesystem is probably mounted as |
@robinsmidsrod It looks like something is accessing the file between the calls to stat() and lstat(), updating the file's atime. I could see a virus scanner or backup tool doing this if it's monitoring the filesystem for changed, is that likely in your environment? |
|
@tonycoz It's quite likely that a scanner of some sort can modify the atime, as we use Prisma Cloud Defender on the Azure hosts to protect against malware and other intrusions. |
tonycoz
added a commit
to tonycoz/perl5
that referenced
this issue
Mar 7, 2023
On a system with some sort of filesystem monitor such as a virus scanner the atime of the file can be modified by that monitor causing the test to fail. Testers can set PERL_FILE_ATIME_CHANGES to a true value to avoid comparing atime between the stat() and lstat() calls. Fixes Perl#19321
tonycoz
added a commit
that referenced
this issue
Mar 7, 2023
On a system with some sort of filesystem monitor such as a virus scanner the atime of the file can be modified by that monitor causing the test to fail. Testers can set PERL_FILE_ATIME_CHANGES to a true value to avoid comparing atime between the stat() and lstat() calls. Fixes #19321
pjacklam
pushed a commit
to pjacklam/perl5
that referenced
this issue
May 20, 2023
On a system with some sort of filesystem monitor such as a virus scanner the atime of the file can be modified by that monitor causing the test to fail. Testers can set PERL_FILE_ATIME_CHANGES to a true value to avoid comparing atime between the stat() and lstat() calls. Fixes Perl#19321
pjacklam
pushed a commit
to pjacklam/perl5
that referenced
this issue
May 20, 2023
On a system with some sort of filesystem monitor such as a virus scanner the atime of the file can be modified by that monitor causing the test to fail. Testers can set PERL_FILE_ATIME_CHANGES to a true value to avoid comparing atime between the stat() and lstat() calls. Fixes Perl#19321
khwilliamson
pushed a commit
to khwilliamson/perl5
that referenced
this issue
Jul 10, 2023
On a system with some sort of filesystem monitor such as a virus scanner the atime of the file can be modified by that monitor causing the test to fail. Testers can set PERL_FILE_ATIME_CHANGES to a true value to avoid comparing atime between the stat() and lstat() calls. Fixes Perl#19321
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello. I am working with a team on RHEL 8.5 and, to avoid package updates breaking our application, we are compiling our own perl 5.34.0 from source. We keep running into an issue with the testing of the Time::HiRes module:
I am aware that this has been reported as an issue with utime.t and usleep.t as Bug #122819 (https://rt.cpan.org/Public/Bug/Display.html?id=122819), and apparently Bug #116127 (https://rt.cpan.org/Public/Bug/Display.html?id=116127), but I have not seen it reported as a failure with stat.t.
I am also aware from running perl -V on our system perl that this has apparently been addressed in Fedora Patch58:
Fedora Patch58: Fix unreliable Time-HiRes tests (CPAN RT#122819)However, since we are compiling from source and we are using the latest perl 5.34.0 directly from CPAN, AND we are still getting this bug, I have tried a number of things to fix it, and they have failed. It seems that there's a difference between the Time::HiRes packaged with perl 5.34.0 (1.9764) and the newest version on CPAN (1.9767), yet still this apparently does not address this Time::HiRes issue when compiling from src on RHEL 8.5.
Can someone kindly help me figure out how to get past this hurdle and patch the perl we are trying to install?
MANY THANKS!
The text was updated successfully, but these errors were encountered: