search for: end_t

If you spend your time looking at libguestfs debugging output you'll see many messages from the daemon main loop like this: guestfsd: main_loop: new request, len 0x54 guestfsd: main_loop: proc 278 (mkfs) took 0.02 seconds I don't think these messages really bring much value. This commit removes them entirely. An alternative might be to change them to make them shorter and/or less

...ot;ignore-value.h" + +#include "guestfs.h" +#include "guestfs-internal-frontend.h" + +#define NR_WARMUP_PASSES 3 +#define NR_TEST_PASSES 5 +#define DEBUG 0 + +/* Per-pass data collected. */ +struct pass_data { + size_t pass; + struct timespec start_t; + struct timespec end_t; + int64_t elapsed_ns; + + /* Array of timestamped events. */ + size_t nr_events; + struct event *events; + + /* Was the previous appliance log message incomplete? If so, this + * contains the index of that incomplete message in the events + * array. + */ + ssize_t incomplete_log_messa...

...a data-frame. The developer says its the number of milliseconds since midnight, January 1, 1970. sample: *1232558018624* --------------------- How do I interpret the time stamp? Is there a date, i need a date and time. site_id,survey_id,version_id,survey_start_ts,survey_question_id,start_ts,end_ts,answer 2,registration,1,1232558018625,z1,*1232558018624*,*1232558266179*,4 Answer: The timestamp is a number representing the exact date and time. it is the number of milliseconds since midnight, January 1, 1970. Are you using it in the DB or R? I am not sure about R's conversion of numbe...

...2 seconds +# open FAILS +# retry and wait 4 seconds +# open succeeds +# pread FAILS +# retry and wait 8 seconds +# pread FAILS +# retry and wait 16 seconds +# pread succeeds + +# The minimum time for the test should be 2+4+8+16 = 30 seconds. +start_t=`stat -c '%Z' retry-reopen-fail-start` +end_t=`date +'%s'` +if [ $((end_t - start_t)) -lt 30 ]; then + echo "$0: test ran too quickly" + exit 1 +fi + +# Check the handle was opened 5 times. +retry_open_count=`cat retry-reopen-fail-open-count` +if [ $retry_open_count -ne 5 ]; then + echo "$0: retry-reopen-fail-op...

Same as v2, except: - Drop the RUN_OUTPUT_FILE functionality completely. It will be replaced with enhanced .trs files as discussed. - Rebase on head. Rich.

...ds > +# open succeeds > +# pread FAILS > +# retry and wait 8 seconds > +# pread FAILS > +# retry and wait 16 seconds > +# pread succeeds > + > +# The minimum time for the test should be 2+4+8+16 = 30 seconds. > +start_t=`stat -c '%Z' retry-reopen-fail-start` > +end_t=`date +'%s'` > +if [ $((end_t - start_t)) -lt 30 ]; then > + echo "$0: test ran too quickly" > + exit 1 > +fi Slows down 'make check'; is there any way we can scale it to be slightly faster, such as using a smaller retry interval than just 1 second as ou...

v4: - Lots more analysis of the /init script and other parts. - Display a list of the longest to shortest activities. - Rebase on top of current head. Rich.

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. I'm not sure I can explain that ... It should be possible to make the test more robust by increasing...

I pushed the (hopefully) completely non-controversial bits upstream: https://github.com/libguestfs/libguestfs/commit/8a72616bf7bc686ad4d033482541fcd73c148b53 https://github.com/libguestfs/libguestfs/commit/b20d36aa1bcabfe1e5eefcf47b727280a6474be8 This patch is what remains. Rich.

...024 ;; + *) exit 2 ;; +esac +EOF + +# In this test we should see 3 failures: +# extents FAILS +# retry and wait 1 seconds +# extents FAILS +# retry and wait 2 seconds +# extents FAILS +# retry and wait 4 seconds +# extents succeeds + +# The minimum time for the test should be 1+2+4 = 7 seconds. +end_t=$SECONDS +if [ $((end_t - start_t)) -lt 7 ]; then + echo "$0: test ran too quickly" + exit 1 +fi + +# Check the handle was opened 4 times (first open + one reopen for +# each retry). +read open_count < retry-extents-open-count +if [ $open_count -ne 4 ]; then + echo "$0: o...

...d wait 1 seconds +# neither fua nor fast_zero supported +# second zero FAILS fast due to missing fast_zero support +# third zero FAILS due to missing fua support +# retry and wait 1 seconds +# only fua supported +# third zero succeeds + +# The minimum time for the test should be 1+1+1 = 3 seconds. +end_t=$SECONDS +if [ $((end_t - start_t)) -lt 3 ]; then + echo "$0: test ran too quickly" + exit 1 +fi + +# Check the handle was opened 4 times (first open + one reopen for +# each retry). +read open_count < retry-zero-flags-open-count +if [ $open_count -ne 4 ]; then + echo "$0...

...ests in parallel, +# and the total time taken should not be much more than 10 seconds +# because all sleeps in the plugin should happen in parallel. +start_t = time.time() +for i in range (10): + buf = nbd.Buffer (512) + h.aio_pread (buf, 0) + +while h.aio_in_flight() > 0: + h.poll(-1) +end_t = time.time() + +t = end_t - start_t +print (t) + +# Since we launched 10 requests, if we serialized on them we +# would have waited at least 100 seconds. We would expect to +# wait around 10 seconds, but for flexibility on slow servers +# any test < 100 should be fine. +assert t <= 50 +'...

...20 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 she...

v2 was here: https://www.redhat.com/archives/libguestfs/2019-September/msg00221.html I think this is more like "the one". It handles reopen failing correctly, and there is a second test for that. I also ran my sshd tests locally and it worked in all scenarios I could think up (except of course sshd not being available at the start, but we want that to fail). Rich.

Includes a rework of the previously posted patch for --run improvements (mostly with improved comments and commit message; I decided that waiting for the captive nbdkit to exit was overkill), and four new patches. The tests are intentionally separate, to allow rearranging the order of the series to see the failures being fixed. Eric Blake (6): server: Propagate unexpected nbdkit failure with

In https://bugzilla.redhat.com/show_bug.cgi?id=1841820, it was pointed out that the retry filter not retrying .open means that an ssh connection (such as in a vmx+ssh v2v conversion) fails when the ssh connection itself cannot be retried. A year ago, this was an inherent limitation of our retry implementation; but in the meantime, my work to allow filters to open independent backends has made it

...t $st); exit $st' +trap "st=129; $do_exit" 1 +trap "st=130; $do_exit" 2 +trap "st=141; $do_exit" 13 +trap "st=143; $do_exit" 15 + +# Test script is run here. +start_t="$(date +'%s')" +"$@" >$log_file 2>&1 +estatus=$? +end_t="$(date +'%s')" + +if test $enable_hard_errors = no && test $estatus -eq 99; then + tweaked_estatus=1 +else + tweaked_estatus=$estatus +fi + +case $tweaked_estatus:$expect_failure in + 0:yes) col=$red res=XPASS recheck=yes gcopy=yes;; + 0:*) col=$grn res=PASS rechec...

Lots of changes since v2, too much to remember or summarize. Please ignore patch 11/11, it's just for my testing. Rich.

I think this is my last round of patches for issues I identified with the retry filter. With this in place, it should be safe to interject another filter in between retry and the plugin. Eric Blake (5): retry: Don't call into closed plugin tests: Refactor test-retry-reopen-fail.sh tests: Enhance retry test to cover failed reopen server: Move prepare/finalize/close recursion to

This is working for me now, although possibly only on Python 3.9. Dan suggested PyEval_InitThreads but that was deprecated in Python 3.7. Rich.