search for: end_ts

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

--- .gitignore | 1 + tests/qemu/Makefile.am | 22 +- tests/qemu/boot-analysis.c | 1098 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1118 insertions(+), 3 deletions(-) create mode 100644 tests/qemu/boot-analysis.c diff --git a/.gitignore b/.gitignore index 1493011..9306a19 100644 --- a/.gitignore +++ b/.gitignore @@ -510,6 +510,7 @@ Makefile.in

...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 number...

We use a custom sh plugin to test retries are working. --- tests/Makefile.am | 8 +++ tests/test-retry-reopen-fail.sh | 108 ++++++++++++++++++++++++++++++++ tests/test-retry.sh | 97 ++++++++++++++++++++++++++++ 3 files changed, 213 insertions(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index 1b1e05b..af9b9d9 100644 --- a/tests/Makefile.am +++

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.

On 9/19/19 10:26 AM, Richard W.M. Jones wrote: > We use a custom sh plugin to test retries are working. > --- > tests/Makefile.am | 8 +++ > tests/test-retry-reopen-fail.sh | 108 ++++++++++++++++++++++++++++++++ > tests/test-retry.sh | 97 ++++++++++++++++++++++++++++ > 3 files changed, 213 insertions(+) > > +++

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

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.

Add coverage for the previous patch. Each retry of .extents must be into a fresh extents object, to avoid mismatch between provided and expected offsets. Signed-off-by: Eric Blake <eblake at redhat.com> --- tests/Makefile.am | 2 + tests/test-retry-extents.sh | 114 ++++++++++++++++++++++++++++++++++++ 2 files changed, 116 insertions(+) create mode 100755

Add coverage for the previous patch. Although most plugins don't change can_fua or can_fast_zero on the fly, the code should still not abort when calling .zero with a flag that was permitted by the previous open but not permitted by the current open. Signed-off-by: Eric Blake <eblake@redhat.com> --- tests/Makefile.am | 2 + tests/test-retry-zero-flags.sh | 126

--- tests/Makefile.am | 3 + tests/test-python-thread-model.sh | 91 +++++++++++++++++++++++++++++++ tests/python-thread-model.py | 50 +++++++++++++++++ 3 files changed, 144 insertions(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index 79be5639..2aa9e14c 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -1020,15 +1020,18 @@ TESTS += \ test-python.sh \

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,

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

Use a custom test driver for running the tests: based on the test-driver provided by automake, it adds the running time of the test in each .trs file. --- configure.ac | 1 + guestfs-test-driver | 151 ++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/Makefile.am | 2 + 3 files changed, 154 insertions(+) create mode 100755 guestfs-test-driver diff --git a/configure.ac

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.