search for: start_ts

Unix.gettimeofday returns a finer resolution than seconds, which is what we need since deciseconds of timestamps are printed. --- mllib/common_utils.ml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mllib/common_utils.ml b/mllib/common_utils.ml index 32e908d..516cff3 100644 --- a/mllib/common_utils.ml +++ b/mllib/common_utils.ml @@ -282,11 +282,11 @@ let verbose () =

Wait up to 10 seconds for qemu-nbd to start up and respond to clients. Otherwise the conversion server may attempt to connect before qemu-nbd is ready to serve it. --- p2v/conversion.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ p2v/p2v.h | 1 + 2 files changed, 73 insertions(+) diff --git a/p2v/conversion.c b/p2v/conversion.c index cb2deed..1aefcc6 100644 ---

...useable field in R, date and time 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...

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

--- .gitignore | 1 + tests/c-api/Makefile.am | 21 ++++++- tests/c-api/test-threads.c | 133 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 153 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index bbd9284c6..5b936239c 100644 --- a/.gitignore +++ b/.gitignore @@ -562,6 +562,7 @@ Makefile.in /tests/c-api/test-pwd /tests/c-api/tests

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(+) > > +++

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

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

This is an updated and extended version of the original patch: https://www.redhat.com/archives/libguestfs/2010-August/msg00163.html This adds OCaml and Perl bindings (both tested), support for progress bars in virt-resize, and adds progress notifications to a number of the simpler commands. Still to do is to add progress messages to more commands. There are still a few commands which would be

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

On 10/12/19 9:21 AM, Richard W.M. Jones wrote: > This program allows you to turn a network block device source into a > FUSE filesystem containing a virtual file: > > $ nbdkit memory 128M > $ mkdir mp > $ nbdfuse mp/ramdisk nbd://localhost & > $ ls -l mp > total 0 > -rw-rw-rw-. 1 rjones rjones 134217728 Oct 12 15:09 ramdisk > $ dd

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 \

When the machine readable mode is enabled, print all the messages (progress, info, warning, and errors) also as JSON in the machine readable stream: this way, users can easily parse the status of the OCaml tool, and report that back. The formatting of the current date time into the RFC 3999 format is done in C, because of the lack of OCaml APIs for this. --- common/mltools/Makefile.am | 2

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.

This program allows you to turn a network block device source into a FUSE filesystem containing a virtual file: $ nbdkit memory 128M $ mkdir mp $ nbdfuse mp/ramdisk nbd://localhost & $ ls -l mp total 0 -rw-rw-rw-. 1 rjones rjones 134217728 Oct 12 15:09 ramdisk $ dd if=/dev/urandom bs=1M count=128 of=mp/ramdisk conv=notrunc,nocreat 128+0 records in 128+0 records out

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