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

Re: [libvirt] PATCH: 1/5: Improved error reporting



On Wed, Aug 13, 2008 at 10:21:59AM -0400, Cole Robinson wrote:
> Daniel P. Berrange wrote:
> > There are several system calls in the virExec function for which we don't
> > or can't report errors. This patch does a couple of things to improve the
> > situation. It moves the code for setting non-block/close-exec to before the
> > fork() so we can report errors for it. It removes the 'dom' and 'net' params
> > from the ReportError function since we deprecated those long ago and all
> > callers simply pass in NULL. It resets the 'virErrorHandler' callback to
> > NULL in the child, so that errors raised will get reported to stderr 
> > instead of invoking a callback which is likely no longer valid in the child
> > process. It reports failures to exec the binary and dup  file descriptors.
> > All errors in the child will end up on stderr, so they will at least be
> > visible on the parent's console, or a logfile if one was setup for the 
> > child. Previously there would just be silent failure.
> > 
> > Daniel
> > 
> 
> Related question: is there any practical way to return error output
> from a virRun command in a libvirt error message?
>
> In testing some of the storage code I hit a few bugs where we improperly
> called out to another app, and the raised libvirt error had no output.
> I would have to manually run libvirtd and watch what output the commands
> dumped.

Yes, I think we'd want to have  virRun call virExec() setting up
a pair of pipes for stderr/out. virRun would then read data from
those pipes and stick into a string. The string could be returned
to the caller, or just included in a libvirt error raised upon
failure with non-zero exit status.

> I guess the other option would be to set up log files for the different
> storage operations similar to how qemu domain logfiles work, or maybe
> just a general libvirtd output log.

I think we need to either feed it back to the caller directly, or raise
an error.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


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