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>]

The following reply was made to PR misc/49342; it has been noted by GNATS.

From: NGie Cooper <yaneurabeya%gmail.com@localhost>
To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%netbsd.org@localhost>
Cc: "misc-bug-people%netbsd.org@localhost" <misc-bug-people%netbsd.org@localhost>, 
	"netbsd-bugs%netbsd.org@localhost" <netbsd-bugs%netbsd.org@localhost>, "gnats-admin%netbsd.org@localhost" <gnats-admin%netbsd.org@localhost>, dholland%netbsd.org@localhost
Subject: 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))
Date: Tue, 14 Apr 2015 17:16:22 -0700

 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!