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, 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) :/...

Are there any thoughts on fixing this further (should the threshold be
increased? should things be left alone? etc)?

Thanks!