Re: trying to understand what's going on with timers and boot process

[Mark Seger <Mark dot Seger at hp dot com>]

I hear what you're saying but I'm not sure it explains everything I'm 
seeing.
Starting from the beginning, here's the call I'm making in perl:

Time::HiRes::ualarm(2000000, 0);

which should set an alarm for 2 seconds in the future.  On a rhel4 
system with an older time module (prior to 1.91 which fixes the problem) 
as well as older glibc (2.3) and kernel (2.6.9)0, here's what strace shows:

setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 2000000}}, 
{it_interval={0, 0}, it_value={0, 0}}) = 0

and you can clearly see the 2M being passed in the usec field which is 
wrong, but it still works just fine.  I'm not saying it should continue 
to be, I'm just pointing out the older behavior.  with a version of 
glibc 2.4 (I'm pretty sure I saw this on a sles 10.1 system but 
unfortunately don't have one on which I can show you the behavior), I 
thought the usecs were being turned into nano-seconds and then stuffed 
unchecked into a 32 bit integer because the behavior was any time 
greater than 2**32-1 nanoseconds, got truncated to 32 bits and the sleep 
duration was random, based on the lower 32 bits of the number.  sleeps < 
4.2 seconds worked just fine being passed as usecs to setitimer.

now onto rhel5 which has glibc 2.5 and a newer kernel.  when I call an 
older HiRes I still see the old type format of the setitimer call, but 
it doesn't generate any errors and in fact seems to work just fine:

setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 2000000}}, 
{it_interval={0, 0}, it_value={0, 0}}) = 0

This is the piece that has me stumped since I thought you said these 
were trapped.  Apparently they're not, at least not with this kernel - 
2.6.18-53.el5

In any event, the part that still has me puzzled it that although this 
sleep also works just fine, after the system boots, it seems there's a 
gray area between right before ntp kicks in that the setitimer calls 
fail and are logged to dmesg.

does any of this make any sense?  The bottom line is any version of 
Time::HiRes prior to 1.91 call setitimer with a single value of usecs no 
matter how big the number is and this wrong.  it would seem based on the 
combination of your glibc and kernel you may get away with it but you're 
really living on borrowed time 8-) if you continue to do so.  any newer 
versions of Time::HiRes seem to work just fine.

I did log a bugzilla with RedHat and I suppose other distros should 
watch out for this too...

-mark

Carlos O'Donell wrote:
> On Tue, Jul 1, 2008 at 10:42 AM, Mark Seger <Mark.Seger@hp.com> wrote:
>   
> > Does that help?
> >     
>
> The setitimer call in glibc is an assembly wrapper to the kernel
> syscall. On x86 there is no logic in userspace, it's handled
> completely by the kernel.
>
> The glibc wrapper might have some argument setup code, but nothing
> more. Disassemble setitimer from a debug version of libc.so.6 to see
> the wrapper.
>
> A recent kernel implementation of sys_setitimer calls do_setitimer
> which uses the following check (((unsigned long) (t)->tv_usec) <
> USEC_PER_SEC) to invalidate large usec values and return EINVAL.
>
> In summary, it would appear that if a user upgrades their kernel, the
> buggy Time:HiRes perl module must surely break.
>
> Does that help? :-)
>
> In the future *please* produce a test-case that shows the problem,
> even if it is a buggy call to a libc routine.
>
> 1. Expected behaviour
> 2. Observed behaviour
> 3. Reproducible test-case.
>
> e.g.
> Expected behaviour:
> - Call to setitimer fails.
>
> Observed behaviour:
> - Invalid call to setitimer works in glibc 2.3 and 2.5, but sometimes
> fails in 2.5.
>
> Test-case
> .... Code showing invalid call to setitimer.
>
> Cheers,
> Calros.
>