[nbdkit PATCH] error: Tweak filter name for easier debugging
Grepping for the string 'error:' is complicated when the error filter reports its name in the same manner. We can keep the filter .so and file names the same, but tweak the filter .name field to change messages using nbdkit_debug() to instead produce "error-inject:", so that "error:" is reserved for uses of nbdkit_error(). --- I confused myself while trying to debug a new libnbd today, where injecting errors was intentional. And then I noticed that 'man nbdkit-error-filter' already tried to warn me. But we can do one step better, as in this patch... filters/error/nbdkit-error-filter.pod | 13 +++++++------ filters/error/error.c | 6 +++--- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/filters/error/nbdkit-error-filter.pod b/filters/error/nbdkit-error-filter.pod index 5fb93063..47fcd379 100644 --- a/filters/error/nbdkit-error-filter.pod +++ b/filters/error/nbdkit-error-filter.pod @@ -129,14 +129,15 @@ settings to NBD cache requests. =head2 Peculiar debug output If you are looking at the debugging output (using C<nbdkit -f -v>) -then you may see peculiar "errors" appearing when using this filter, -for example: +references to the name of this filter show up as C<"error-inject:">, +and such lines indicate that the filter is not altering output, for +example: - nbdkit: file.9: debug: error: pread count=1024 offset=0 flags=0x0 + nbdkit: file.9: debug: error-inject: pread count=1024 offset=0 flags=0x0 -In fact these are not errors, nbdkit core is simply printing the name -of the filter which happens to be C<"error">. When this filter -injects an error you will see something like: +Conversely, references to the string C<"error:"> occur when the +L<nbdkit_error(3)> API was used, including when this filter injects an +error, as in: nbdkit: file.4: error: injecting ENOSPC error into pwrite diff --git a/filters/error/error.c b/filters/error/error.c index 4b513a81..95eb5622 100644 --- a/filters/error/error.c +++ b/filters/error/error.c @@ -1,5 +1,5 @@ /* nbdkit - * Copyright (C) 2018-2020 Red Hat Inc. + * Copyright (C) 2018-2022 Red Hat Inc. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are @@ -374,8 +374,8 @@ error_cache (nbdkit_next *next, } static struct nbdkit_filter filter = { - .name = "error", - .longname = "nbdkit error filter", + .name = "error-inject", + .longname = "nbdkit error injection filter", .load = error_load, .unload = error_unload, .config = error_config, -- 2.34.1
On 02/03/22 22:29, Eric Blake wrote:
Grepping for the string 'error:' is complicated when the error filter reports its name in the same manner. We can keep the filter .so and file names the same, but tweak the filter .name field to change messages using nbdkit_debug() to instead produce "error-inject:", so that "error:" is reserved for uses of nbdkit_error(). ---
I confused myself while trying to debug a new libnbd today, where injecting errors was intentional. And then I noticed that 'man nbdkit-error-filter' already tried to warn me. But we can do one step better, as in this patch...
filters/error/nbdkit-error-filter.pod | 13 +++++++------ filters/error/error.c | 6 +++--- 2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/filters/error/nbdkit-error-filter.pod b/filters/error/nbdkit-error-filter.pod index 5fb93063..47fcd379 100644 --- a/filters/error/nbdkit-error-filter.pod +++ b/filters/error/nbdkit-error-filter.pod @@ -129,14 +129,15 @@ settings to NBD cache requests. =head2 Peculiar debug output
If you are looking at the debugging output (using C<nbdkit -f -v>) -then you may see peculiar "errors" appearing when using this filter, -for example: +references to the name of this filter show up as C<"error-inject:">, +and such lines indicate that the filter is not altering output, for +example:
- nbdkit: file.9: debug: error: pread count=1024 offset=0 flags=0x0 + nbdkit: file.9: debug: error-inject: pread count=1024 offset=0 flags=0x0
-In fact these are not errors, nbdkit core is simply printing the name -of the filter which happens to be C<"error">. When this filter -injects an error you will see something like: +Conversely, references to the string C<"error:"> occur when the +L<nbdkit_error(3)> API was used, including when this filter injects an +error, as in:
nbdkit: file.4: error: injecting ENOSPC error into pwrite
diff --git a/filters/error/error.c b/filters/error/error.c index 4b513a81..95eb5622 100644 --- a/filters/error/error.c +++ b/filters/error/error.c @@ -1,5 +1,5 @@ /* nbdkit - * Copyright (C) 2018-2020 Red Hat Inc. + * Copyright (C) 2018-2022 Red Hat Inc. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are @@ -374,8 +374,8 @@ error_cache (nbdkit_next *next, }
static struct nbdkit_filter filter = { - .name = "error", - .longname = "nbdkit error filter", + .name = "error-inject", + .longname = "nbdkit error injection filter", .load = error_load, .unload = error_unload, .config = error_config,
Very important patch, I'd say; log analysis is very common! Reviewed-by: Laszlo Ersek <lersek@redhat.com>
On Fri, Feb 04, 2022 at 09:32:54AM +0100, Laszlo Ersek wrote:
On 02/03/22 22:29, Eric Blake wrote:
Grepping for the string 'error:' is complicated when the error filter reports its name in the same manner. We can keep the filter .so and file names the same, but tweak the filter .name field to change messages using nbdkit_debug() to instead produce "error-inject:", so that "error:" is reserved for uses of nbdkit_error(). ---
I confused myself while trying to debug a new libnbd today, where injecting errors was intentional. And then I noticed that 'man nbdkit-error-filter' already tried to warn me. But we can do one step better, as in this patch...
Very important patch, I'd say; log analysis is very common!
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks, now in as commit 886fd408 (and right after I pushed, I remembered that I forgot to 'git am' my own patch to get the Message-id: tag in the commit message. Oh well) -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
participants (2)
-
Eric Blake -
Laszlo Ersek