Re: [PATCH 2/6] iscsi: Add exit status checking for virISCSIGetSession

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 13, 2016 at 17:29:22 -0400, John Ferlan wrote:
> Utilize the exit status parameter for virCommandRunRegex in order to
> check the return error from the 'iscsiadm --mode session' command.
> Without this enabled, if there are no sessions running then virCommandRun
> would have displayed an error such as:
> 
>     2016-05-13 15:17:15.165+0000: 10920: error : virCommandWait:2553 :
>                internal error: Child process (iscsiadm --mode session)
>                unexpected exit status 21: iscsiadm: No active sessions.

                                 ^^^^^^^^^^[1]

> 
> It is possible that for certain paths (when probe is true) we only care
> whether it's running or not to make certain decisions.  Spitting out
> the error for those paths is unnecessary.
> 
> If we do have a situation where probe = false and there's an error,
> then display the error from iscsiadm if it's there; otherwise, default
> to the non descript error.
> 
> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
> ---
>  src/util/viriscsi.c | 28 +++++++++++++++++++++++-----
>  1 file changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/src/util/viriscsi.c b/src/util/viriscsi.c
> index 846ea68..be296d7 100644
> --- a/src/util/viriscsi.c
> +++ b/src/util/viriscsi.c



> @@ -79,21 +80,38 @@ virISCSIGetSession(const char *devpath,
>          .session = NULL,
>          .devpath = devpath,
>      };
> +    char *error;
> +    int exitstatus = 0;
>  
> -    virCommandPtr cmd = virCommandNewArgList(ISCSIADM, "--mode", "session", NULL);
> +    virCommandPtr cmd = virCommandNewArgList(ISCSIADM, "--mode",
> +                                             "session", NULL);
> +    virCommandSetErrorBuffer(cmd, &error);
>  
>      if (virCommandRunRegex(cmd,
>                             1,
>                             regexes,
>                             vars,
>                             virISCSIExtractSession,
> -                           &cbdata, NULL, NULL) < 0)
> +                           &cbdata, NULL, &exitstatus) < 0)
>          goto cleanup;
>  
>      if (cbdata.session == NULL && !probe) {
> -        virReportError(VIR_ERR_INTERNAL_ERROR,
> -                       "%s", _("cannot find session"));
> -        goto cleanup;
> +        /* If the command failed, let's give some information as to why */
> +        if (exitstatus != 0) {
> +            char *str = virCommandToString(cmd);
> +            char *st = virProcessTranslateStatus(exitstatus);
> +
> +            virReportError(VIR_ERR_INTERNAL_ERROR,
> +                           _("'%s --mode session' unexpected %s%s%s"),
> +                           ISCSIADM, NULLSTR(st),
> +                           error ? ": " : "",
> +                           error ? error : "");

The original code where this was copied from uses 'str' to be part of
the error message. Here it's unused.

Is it necessary to report the error as virCommandWait() would report?
Isn't it enough just to notify the user that the command failed.
Especially since error code 21 [1] is not really an unexpected error
code in this code path (it's even documented in the man page for
iscsiadm). In such case the error message in the "else" section is
better than the raw output.

Also is INTERNAL_ERROR really necessary in case where the session
wasn't found. [2].




> +            VIR_FREE(str);
> +            VIR_FREE(st);
> +        } else {
> +            virReportError(VIR_ERR_INTERNAL_ERROR,

[2]. Ah that's pre-existing.

> +                           "%s", _("cannot find session"));
> +        }
>      }
>  
>   cleanup:

Buffer for 'error' is leaked.

Peter

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]