11:53 a.m.
Hi all,
I think it's a bug, when call virDomainGetState after "service libvirtd
stop", I receive signal SIGPIPE.
I want to know how to avoid this problem? And Other interfaces will also encounter this
problem？
Below the bt information:
Below some information about my hypervisor:
root@ubuntu-05:/datapool/zhuohf# virsh -v
3.4.0
root@ubuntu-05:/datapool/zhuohf# qemu-x86_64 -version
qemu-x86_64 version 2.9.0
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
7:18 a.m.
On Wed, Aug 09, 2017 at 11:53:54AM +0800, netsurfed wrote:
Hi all,
I think it's a bug, when call virDomainGetState after "service libvirtd
stop"
, I receive signal SIGPIPE.
For the QEMU driver, the libvirt library just talks to libvirtd over an
RPC layer. You killed libvirtd, so the libvirt library gets SIGPIPE.
I want to know how to avoid this problem? And Other interfaces will
also
If you want libvirt to work, don't stop libvirtd
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
8:59 a.m.
The error message could however give a hint what is going on. It should sax
that it is impossible to talk to libvirtd and that it might be stopped.
On 9 Aug 2017 2:19 p.m., "Daniel P. Berrange" <berrange(a)redhat.com>
wrote:
On Wed, Aug 09, 2017 at 11:53:54AM +0800, netsurfed wrote:
> Hi all,
> I think it's a bug, when call virDomainGetState after "service libvirtd
stop"
> , I receive signal SIGPIPE.
For the QEMU driver, the libvirt library just talks to libvirtd over an
RPC layer. You killed libvirtd, so the libvirt library gets SIGPIPE.
> I want to know how to avoid this problem? And Other interfaces will also
If you want libvirt to work, don't stop libvirtd
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/
dberrange :|
|: https://libvirt.org -o-
https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/
dberrange :|
_______________________________________________
libvirt-users mailing list
libvirt-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
1:21 a.m.
On 08/09/2017 03:59 PM, Dominik Psenner wrote:
The error message could however give a hint what is going on. It
should sax
that it is impossible to talk to libvirtd and that it might be stopped.
[Please don't top post on technical lists]
Yes and no. There can be a lot of reasons why client can't talk to
daemon. They all don't demonstrate in local connection, but imagine
talking to a daemon on distant host. And suddenly somebody cuts the
cable, or inserts incorrect firewall rules, etc. Suggesting that daemon
is not running would be wrong in this case. Also, we tend to report
system errors and leave mgmt application figure out how to deal with it.
For instance:
http://libvirt.org/git/?p=libvirt.git;a=blob;f=tools/virsh.c;h=94bb7ff6c9...
Michal
3:45 a.m.
2017-08-10 8:21 GMT+02:00 Michal Privoznik <mprivozn(a)redhat.com>:
On 08/09/2017 03:59 PM, Dominik Psenner wrote:
> The error message could however give a hint what is going on. It should
sax
> that it is impossible to talk to libvirtd and that it might be stopped.
[Please don't top post on technical lists]
Yes and no. There can be a lot of reasons why client can't talk
to
daemon. They all don't demonstrate in local connection, but imagine
talking to a daemon on distant host.
And suddenly somebody cuts the
cable, or inserts incorrect firewall rules, etc. Suggesting that
daemon
is not running would be wrong in this case.
Actually, it would most probably be true in this case and still the most
probable cause if the communication went over a wire. Yes, it could be a
firewall issue but still it is more likely that the host or the service is
not up.
Also, we tend to report
system errors and leave mgmt application figure out how to deal with it.
For instance:
http://libvirt.org/git/?p=libvirt.git;a=blob;f=tools/virsh.c;h=
94bb7ff6c93afa46d31d085eaa5e504f1cca7593;hb=HEAD#l90
Are you indicating that a user should have to read the sourcecode of
libvirt and libvirtd to understand their error messages? Please bear in
mind that we are humans that use a software and as such the software should
be written to be used by humans. I know very well that good error handling
is a tough task to achieve, but it is still worth the effort. I suggest
that the error message:
libvirt: XML-RPC error : Cannot write data: Broken pipe
should read as:
libvirt: Could not connect to the libvirtd service : Cannot write data:
Broken pipe
The first indicates that there's an XML-RPC error going on. To a user this
sounds like a bad problem that he cannot solve by himself. Maybe it is an
incompatible API or the connection broke while transferring data or the
connection crashed, maybe trying to send something that shouldn't be sent
with XML-RPC. Anyway it doesn't give a clue to a user that does not know
how libvirt and libvirtd work internally. The latter is much clearer in
explaining that there's a connectivity issue and that it could not even
open the connection to the service. On top of that it includes the actual
cause, namely a broken pipe.
Cheers
--
Dominik Psenner
4:50 a.m.
On 08/10/2017 10:45 AM, Dominik Psenner wrote:
2017-08-10 8:21 GMT+02:00 Michal Privoznik
<mprivozn(a)redhat.com>:
> On 08/09/2017 03:59 PM, Dominik Psenner wrote:
>> The error message could however give a hint what is going on. It should
> sax
>> that it is impossible to talk to libvirtd and that it might be stopped.
>
> [Please don't top post on technical lists]
> Yes and no. There can be a lot of reasons why client can't talk to
> daemon. They all don't demonstrate in local connection, but imagine
> talking to a daemon on distant host.
And suddenly somebody cuts the
> cable, or inserts incorrect firewall rules, etc. Suggesting that daemon
> is not running would be wrong in this case.
Actually, it would most probably be true in this case and still the most
probable cause if the communication went over a wire. Yes, it could be a
firewall issue but still it is more likely that the host or the service is
not up.
> Also, we tend to report
> system errors and leave mgmt application figure out how to deal with it.
> For instance:
>
> http://libvirt.org/git/?p=libvirt.git;a=blob;f=tools/virsh.c;h=
> 94bb7ff6c93afa46d31d085eaa5e504f1cca7593;hb=HEAD#l90
Are you indicating that a user should have to read the sourcecode of
libvirt and libvirtd to understand their error messages?
No, I'm indicating that you should read the documentation. What I gave
you was a usage example.
Please bear in
mind that we are humans that use a software and as such the software should
be written to be used by humans. I know very well that good error handling
is a tough task to achieve, but it is still worth the effort. I suggest
that the error message:
libvirt: XML-RPC error : Cannot write data: Broken pipe
Again, after reading corresponding documentation you'll find that:
XML-RPC error stands for error.domain = VIR_FROM_RPC,
and to change "XML-RPC" to something else we would need yet another
domain. It would be wrong anyway - the domain of the error is RPC code
after all.
should read as:
libvirt: Could not connect to the libvirtd service : Cannot write data:
Broken pipe
This is untrue. You are connected at this point, otherwise you wouldn't
be able to get the domain object you are passing to the API in the first
place. Only by writing to the connection socket you learn (well, the
code) that the daemon is gone. That's why we have keep alive, connection
close callbacks and all these fancy features that help you to learn this
fact sooner, without having to call any APIs. Moreover, they can take
actions once the connection gets disconnected. But I'm not going to link
any more code to not discourage you.
Michal
4:52 a.m.
On Thu, Aug 10, 2017 at 10:45:49AM +0200, Dominik Psenner wrote:
2017-08-10 8:21 GMT+02:00 Michal Privoznik
<mprivozn(a)redhat.com>:
> On 08/09/2017 03:59 PM, Dominik Psenner wrote:
> > The error message could however give a hint what is going on. It should
> sax
> > that it is impossible to talk to libvirtd and that it might be stopped.
>
> [Please don't top post on technical lists]
> Yes and no. There can be a lot of reasons why client can't talk to
> daemon. They all don't demonstrate in local connection, but imagine
> talking to a daemon on distant host.
And suddenly somebody cuts the
> cable, or inserts incorrect firewall rules, etc. Suggesting that daemon
> is not running would be wrong in this case.
Actually, it would most probably be true in this case and still the most
probable cause if the communication went over a wire. Yes, it could be a
firewall issue but still it is more likely that the host or the service is
not up.
> Also, we tend to report
> system errors and leave mgmt application figure out how to deal with it.
> For instance:
>
> http://libvirt.org/git/?p=libvirt.git;a=blob;f=tools/virsh.c;h=
> 94bb7ff6c93afa46d31d085eaa5e504f1cca7593;hb=HEAD#l90
Are you indicating that a user should have to read the sourcecode of
libvirt and libvirtd to understand their error messages? Please bear in
mind that we are humans that use a software and as such the software should
be written to be used by humans. I know very well that good error handling
is a tough task to achieve, but it is still worth the effort. I suggest
that the error message:
libvirt: XML-RPC error : Cannot write data: Broken pipe
should read as:
libvirt: Could not connect to the libvirtd service : Cannot write data:
Broken pipe
The code in question is used to communicate with *faaar* more than
just libvirtd, so such a change would be pretty misleading in
general.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
2695
days inactive
2696
days old
6 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Dominik Psenner -
Michal Privoznik -
netsurfed