Re: misc/49342 ([test] lib/libc/gen/t_time.c is non-deterministic; compares set time vs current time (and can vary by a second under rare circumstances))

[NGie Cooper <yaneurabeya%gmail.com@localhost>]

On Tue, Apr 14, 2015 at 5:16 PM, NGie Cooper <yaneurabeya%gmail.com@localhost> wrote:
> On Tue, Nov 11, 2014 at 12:45 AM,  <dholland%netbsd.org@localhost> wrote:
>> Synopsis: [test] lib/libc/gen/t_time.c is non-deterministic; compares set time vs current time (and can vary by a second under rare circumstances)
>>
>> State-Changed-From-To: open->closed
>> State-Changed-By: dholland%NetBSD.org@localhost
>> State-Changed-When: Tue, 11 Nov 2014 08:45:37 +0000
>> State-Changed-Why:
>> fixed last week
>
> This fix works better, but unfortunately in FreeBSD's case, adjkerntz
> -a plays around with the system time via crond, and the testcase
> failed again (it took 7 seconds to adjust the time), because things
> happened at the right moment and were slow enough to catch a time jump
> because of the debugging features we have enabled in our kernel.
>
> From /var/log/cron on the VM where the failure occurred:
>
> # grep -r 02:01 /var/log/
> /var/log/cron:2015-04-14T02:01:00-07:00 <9.6> VBOX6672-1(id1)
> /usr/sbin/cron[44778]: (root) CMD (adjkerntz -a)
> # grep -r adjkerntz /etc/crontab
> # See adjkerntz(8) for details.
> 1,31    0-5    *    *    *    root    adjkerntz -a
>
> The Time derived from the kyua logs was as follows:
>
> 1428829260 vs. 1428829261
>
> % python -c 'import time; print time.ctime(1428829260)'
> Sun Apr 12 02:01:00 2015
>
> So, as you can see, the time that the test ran was at the tail end of
> the adjkerntz -a call according to crond(8) :/...

I meant to say "at the start", not "tail end".