[PATCH v4] report error when virProcessGetStatInfo() is unable to parse data
Ani Sinha
ani at anisinha.ca
Wed Jan 12 13:49:08 UTC 2022
On Wed, Jan 12, 2022 at 6:49 PM Michal Prívozník <mprivozn at redhat.com>
wrote:
> On 1/11/22 19:13, Ani Sinha wrote:
> > Currently virProcessGetStatInfo() always returns success and only logs
> error
> > when it is unable to parse the data. Make this function actually report
> the
> > error and return a negative value in this error scenario.
> >
> > Fix the callers so that they do not override the error generated.
> > Also fix non-linux implementation of this function so as to report error.
> >
> > Signed-off-by: Ani Sinha <ani at anisinha.ca>
> > ---
> > src/ch/ch_driver.c | 2 --
> > src/qemu/qemu_driver.c | 7 +------
> > src/util/virprocess.c | 17 +++++++++++++----
> > 3 files changed, 14 insertions(+), 12 deletions(-)
> >
> > changelog:
> > v4: on freebsd error on the logs is a problem appaently. try to fix
> > that.
> > v3: fix non linux implementation
> > v2: fix callers
> >
> > diff --git a/src/ch/ch_driver.c b/src/ch/ch_driver.c
> > index 53e0872207..3cbc668489 100644
> > --- a/src/ch/ch_driver.c
> > +++ b/src/ch/ch_driver.c
> > @@ -1073,8 +1073,6 @@ chDomainHelperGetVcpus(virDomainObj *vm,
> > if (virProcessGetStatInfo(&vcpuinfo->cpuTime,
> > &vcpuinfo->cpu, NULL,
> > vm->pid, vcpupid) < 0) {
> > - virReportSystemError(errno, "%s",
> > - _("cannot get vCPU placement &
> pCPU time"));
> > return -1;
> > }
> > }
> > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> > index d3d76c003f..65ac5ef367 100644
> > --- a/src/qemu/qemu_driver.c
> > +++ b/src/qemu/qemu_driver.c
> > @@ -1359,8 +1359,6 @@ qemuDomainHelperGetVcpus(virDomainObj *vm,
> > if (virProcessGetStatInfo(&vcpuinfo->cpuTime,
> > &vcpuinfo->cpu, NULL,
> > vm->pid, vcpupid) < 0) {
> > - virReportSystemError(errno, "%s",
> > - _("cannot get vCPU placement &
> pCPU time"));
> > return -1;
> > }
> > }
> > @@ -2521,8 +2519,6 @@ qemuDomainGetInfo(virDomainPtr dom,
> > if (virDomainObjIsActive(vm)) {
> > if (virProcessGetStatInfo(&(info->cpuTime), NULL, NULL,
> > vm->pid, 0) < 0) {
> > - virReportError(VIR_ERR_OPERATION_FAILED, "%s",
> > - _("cannot read cputime for domain"));
> > goto cleanup;
> > }
> > }
> > @@ -10530,8 +10526,7 @@ qemuDomainMemoryStatsInternal(virQEMUDriver
> *driver,
> > }
> >
> > if (virProcessGetStatInfo(NULL, NULL, &rss, vm->pid, 0) < 0) {
> > - virReportError(VIR_ERR_OPERATION_FAILED, "%s",
> > - _("cannot get RSS for domain"));
> > + virResetLastError();
> > } else {
> > stats[ret].tag = VIR_DOMAIN_MEMORY_STAT_RSS;
> > stats[ret].val = rss;
> > diff --git a/src/util/virprocess.c b/src/util/virprocess.c
> > index b559a4257e..cbb31441cc 100644
> > --- a/src/util/virprocess.c
> > +++ b/src/util/virprocess.c
> > @@ -1779,12 +1779,20 @@ virProcessGetStatInfo(unsigned long long
> *cpuTime,
> > long rss = 0;
> > int cpu = 0;
> >
> > - if (!proc_stat ||
> > - virStrToLong_ullp(proc_stat[VIR_PROCESS_STAT_UTIME], NULL, 10,
> &usertime) < 0 ||
> > + if (!proc_stat) {
> > + VIR_WARN("Unable to get proc stats from the kernel");
> > + return 0;
> > + }
> > +
>
> I don't think I've objected to this part in v3, any reason for changing
> it? Because now it's actually worse. For instance in
> qemuDomainMemoryStatsInternal() there's the following:
>
> long rss;
>
> virProcessGetStatInfo(NULL, NULL, &rss, vm->pid, 0);
>
> Now, if virProcessGetStatInfo() returns 0 is @rss set? Depends whether
> @proc_stat was NULL or not. But the caller has no way of figuring that out.
>
> I believe all I wanted for you to do was to not change the semantics of
> qemuDomainMemoryStatsInternal(). I even suggested how to do that.
Yes I did that in v4.
}
if (virProcessGetStatInfo(NULL, NULL, &rss, vm->pid, 0) < 0) {
- virReportError(VIR_ERR_OPERATION_FAILED, "%s",
- _("cannot get RSS for domain"));
+ virResetLastError();
I was also trying to find a solution for the logging issue as well as a
part of v4 which clearly was incorrect.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20220112/95048437/attachment-0001.htm>
More information about the libvir-list
mailing list