Time::HiRes hell...

[Mark Seger]

I'd posted a note on HiRes earlier but things seem to be getting more
complicated. Here are the facts as I understand them:

- versions of HiRes older than 1.91 call setitimer with the entire time
interval as usecs even if > 1sec. This is clearly in violation of the
calling interface to setitimer, but with glibc versions <2.4 it still
works correctly as I've been successfully using this for over 5 years.
- with glibc 2.4, you get random results if the time >4 seconds
- with glibc 2.5, you get failures but is seems only during boot! I
know this sounds odd, but I tried running a test that did alarms > 1
second as an inet.d script and watched the console. I got errors while
the system was booting and once it finished, the error messages stopped.

If the answer were simply to install the right version of HiRes that
wouldn't be so bad but it looks like a lot of current distros still ship
an older version of HiRes and we are talking a lot of permutations. I
just submitted a bugzilla against rhel5.2 and they're going to try to
get it addresses in 5.3 but I have no idea where else this is a problem.

Now for my problem - I have an open source performance monitoring tool
called collectl if anyone cares - that uses HiRes. If HiRes is present
I use high resolution timers and if not there I just do sleeps.

I'm now starting to get bug reports against systems with glibc 2.5 on
them and what I plan to do with my next release if check the versions of
HiRes and glibc and if they're incompatible point the user to cpan and
tell them to install a newer version of HiRes. Seemed to work great
until I tried to install a new version of HiRes. When I did my 'make
install', it told me:

[root@cag-dl585-01 Time-HiRes-1.9715]# make install
Files found in blib/arch: installing files in blib/lib into architecture
dependent library tree
Writing
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes/.packlist
Appending installation info to
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/perllocal.pod

and I discovered I now have both the old and new version of HiRes
installed. But what really makes this awful when I try to use HiRes
perl loads the older one. Clearly it's a library search path issue but
given this can run on any distro I can't make any assumptions about
where the module actually gets installed.

I'm not sure what the best solution to this is. Is there an easy way to
remove the older version? Ultimately I want to be able to tell users of
my tool how to get HiRes properly installed and they may not even be
perl users or developers so the solution needs to be very simple.

any helpful suggestions will be greatly appreciated.

-mark

 

[Mark Seger]

and I discovered I now have both the old and new version of HiRes

installed. But what really makes this awful when I try to use HiRes
perl loads the older one. Clearly it's a library search path issue but
given this can run on any distro I can't make any assumptions about
where the module actually gets installed.

I'm not sure what the best solution to this is. Is there an easy way to
remove the older version? Ultimately I want to be able to tell users of
my tool how to get HiRes properly installed and they may not even be
perl users or developers so the solution needs to be very simple.

I did have a thought though I admit it's pretty brute force - how about
I just add a switch to collectl that removes all instances of HiRes so
the user doesn't have to figure out what to do? Then they can execute
the 'make install' and not care where in the tree it gets installed into?

It looks like I'd need to delete the directories and their contents that
match *linux-thread-multi/Time/HiRes.pm
match *linux-thread-multi/auto/Time/HiRes/

Would that work?
-mark

 

[Ben Morrow]

I'm now starting to get bug reports against systems with glibc 2.5 on
them and what I plan to do with my next release if check the versions of
HiRes and glibc and if they're incompatible point the user to cpan and
tell them to install a newer version of HiRes. Seemed to work great
until I tried to install a new version of HiRes. When I did my 'make
install', it told me:

[root@cag-dl585-01 Time-HiRes-1.9715]# make install
Files found in blib/arch: installing files in blib/lib into architecture
dependent library tree
Writing
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes/.packlist
Appending installation info to
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/perllocal.pod

and I discovered I now have both the old and new version of HiRes
installed.

Is the RHEL? RedHat are know to have messed up perl's @INC ordering in
many of their perl packages. Unfortunately there's not much you can do
to fix that...

But what really makes this awful when I try to use HiRes
perl loads the older one. Clearly it's a library search path issue but
given this can run on any distro I can't make any assumptions about
where the module actually gets installed.

Where is the old copy? Is it the version installed as part of 5.8.8, or
some other version installed by your package manager?

On my system I have

/usr/local/lib/perl5/5.8.8/mach/Time/HiRes.pm
/usr/local/lib/perl5/site_perl/5.8.8/mach/Time/HiRes.pm

but since my @INC is

/usr/local/lib/perl5/5.8.8/BSDPAN
/usr/local/lib/perl5/site_perl/5.8.8/mach
/usr/local/lib/perl5/site_perl/5.8.8
/usr/local/lib/perl5/site_perl
/usr/local/lib/perl5/5.8.8/mach
/usr/local/lib/perl5/5.8.8

 

[Mark Seger]

Where is the old copy? Is it the version installed as part of 5.8.8, or
some other version installed by your package manager?

[root@hadesn0 ~]# find /usr | grep HiRes
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes/HiRes.so
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Time/HiRes.pm

# make install UNINST=1

will remove any other versions it can find that might conflict. This
isn't the default because it could be dangerous on systems with multiple
versions of perl installed and a carefully-constructed @INC (or
networked filesystems serving machines with multiple versions of perl),
but on systems with only one perl it's safe. Of course the package
manager will probably complain that whichever package HiRes.pm belonged
to is now corrupt.

very cool! thanks...
-mark

 

[Mark Seger]

I'm not quite sure that's going to work though, the documentation isn't
clear on whether it will give up after rejecting the old version or
whether it will search on.

It looks like Ben's trick of installing with the make switch UNINST=1
did the trick

Alternatively, you could use plain old sleep. Inaccurate but reliable...

actually, you really don't want to get me started on this one
but there are so many broken monitoring utilities because they do sleeps
when they could/should be handling time much more accurately. there are
some very large clusters running collectl and all taking samples at
pretty tightly synchronized times, literally every 10 seconds day in and
day out, all using ntp of course, with virtually no drift. how else is
one to try and correlate data across hundreds of nodes if they're not
all synchronized? actually if you want to try it out for yourself it's
on sourceforge
-mark

 

[Ben Morrow]

On Tue, 01 Jul 2008 12:36:50 -0400, Mark Seger wrote:

You could try saying:

use Time::HiRes 1.91 qw/sleep gettimeofday/;

I'm not quite sure that's going to work though, the documentation isn't
clear on whether it will give up after rejecting the old version or
whether it will search on.

It will fail if the first copy found isn't the correct version. See also
only::latest on CPAN.

Ben

 

[Mark Seger]

just got another report from another user - according to him the
messages went away once the ntpd service started. any thoughts?
-mark