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
_______________________________________________
Libguestfs mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libguestfs
