[Libguestfs] [nbdkit] Failure in test-retry-size.sh

Eric Blake eblake at redhat.com
Mon Aug 3 14:45:50 UTC 2020


On 8/3/20 4:46 AM, Richard W.M. Jones wrote:
> On Sun, Aug 02, 2020 at 10:13:05AM +0100, Richard W.M. Jones wrote:
>> This happened on s390 in Koji, once.  The key lines from the
>> log are:
>>
>> + start_t=0
>> nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying
>> nbdkit: sh[1]: debug: retry 1: waiting 1 seconds before retrying
>> + end_t=1
>>
>> Somehow nbdkit did wait 2 seconds (or at least, nbdkit_nanosleep (1, 0)
>> was called twice by the retry filter).  But in the bash script, time
>> (as measured by $SECONDS) advanced from 0 to 1.
> 
> FWIW $SECONDS is calculated by bash in the obvious way.  It saves
> time(2) when the shell starts, and then when you ask for $SECONDS it
> returns the current time(2) - the saved time.

Yes, there have been complaints on the bash list that $SECONDS is rather 
imprecise:

https://lists.gnu.org/archive/html/help-bash/2020-06/msg00033.html

> 
> If the time difference was 1.999 then it would return 1, but we expect
> after the two calls to nbdkit_nanosleep that the elapsed time must be > 2.

And while each of our nbdkit_nanosleep(1,0) calls advanced by at least 
one second according to one clock, it could entirely be the case that 
bash is going by another clock that is undergoing slight adjustments 
from NTP or whatever where it indeed appears like 1.99 (rounded to 1) 
instead of 2.0 seconds of elapsed time.  I'm not sure what the best fix 
is; bash has $EPOCHREALTIME which offers finer granularity but becomes a 
bit more awkward to manipulate using only shell math.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




More information about the Libguestfs mailing list