GNOME Bugzilla – Bug 746806
IO error on machine shutdown if connected through unix fd socket
Last modified: 2016-03-31 13:22:07 UTC
Start an EL7 VM Open its display Shut it down from within the guest (I used the GNOME Classic UI to do that) Boxes gets back to the collection view showing a "Connection to guest failed" I'd expect no error message in this situation. Wait some more -> a "Saving..." label appears below the VM.
This is related to commit fb04e17a7dac24ecb14b2b0d252f025841cef075 "libvirt-machine: Connect using FD if local". Reverting it makes this issue go away. Maybe this should be fixed in spice-gtk, but this is not a regression from https://bugs.freedesktop.org/show_bug.cgi?id=83692 as this seems to have always happened.
(In reply to Christophe Fergeau from comment #1) > This is related to commit fb04e17a7dac24ecb14b2b0d252f025841cef075 > "libvirt-machine: Connect using FD if local". Reverting it makes this issue > go away. Maybe this should be fixed in spice-gtk, Most likely, yes. The commit in question and its related parent commits do not change anything about disconnection code but only how we connect to spice display. Unless we need to also change disconnecion code for connection over unix socket, I'd look into spice-gtk first for issues.
(In reply to Zeeshan Ali (Khattak) from comment #2) > (In reply to Christophe Fergeau from comment #1) > > This is related to commit fb04e17a7dac24ecb14b2b0d252f025841cef075 > > "libvirt-machine: Connect using FD if local". Reverting it makes this issue > > go away. Maybe this should be fixed in spice-gtk, > > Most likely, yes. The commit in question and its related parent commits do > not change anything about disconnection code but only how we connect to > spice display. Unless we need to also change disconnecion code for > connection over unix socket, I'd look into spice-gtk first for issues. Also keep in mind that the error is shown because spice-gtk is send either of the following errors on the channel: case ChannelEvent.ERROR_CONNECT: case ChannelEvent.ERROR_TLS: case ChannelEvent.ERROR_LINK: case ChannelEvent.ERROR_IO:
https://bugs.freedesktop.org/show_bug.cgi?id=90016
I would suggest to ignore ERROR_IO and consider it has a "clean" CLOSE event, most likely do that without complains. See spice-gtk bug for more details on why you get that ERROR_IO on guest shutdown.
(In reply to Marc-Andre Lureau from comment #5) > I would suggest to ignore ERROR_IO and consider it has a "clean" CLOSE > event, most likely do that without complains. s/likely/clients
(In reply to Marc-Andre Lureau from comment #5) > I would suggest to ignore ERROR_IO and consider it has a "clean" CLOSE > event Did you mean to write that "ERROR_IO" should be considered a "clean" CLOSE event?
(In reply to Zeeshan Ali (Khattak) from comment #7) > (In reply to Marc-Andre Lureau from comment #5) > > I would suggest to ignore ERROR_IO and consider it has a "clean" CLOSE > > event > > Did you mean to write that "ERROR_IO" should be considered a "clean" CLOSE > event? yes, that's what most spice clients do.
(In reply to Marc-Andre Lureau from comment #8) > (In reply to Zeeshan Ali (Khattak) from comment #7) > > (In reply to Marc-Andre Lureau from comment #5) > > > I would suggest to ignore ERROR_IO and consider it has a "clean" CLOSE > > > event > > > > Did you mean to write that "ERROR_IO" should be considered a "clean" CLOSE > > event? > > yes, that's what most spice clients do. Ah ok. What about others here? + case ChannelEvent.ERROR_CONNECT: + case ChannelEvent.ERROR_TLS: + case ChannelEvent.ERROR_LINK: + case ChannelEvent.ERROR_IO: ? They were added in: https://bugzilla.gnome.org/show_bug.cgi?id=701753
(In reply to Zeeshan Ali (Khattak) from comment #9) > (In reply to Marc-Andre Lureau from comment #8) > > (In reply to Zeeshan Ali (Khattak) from comment #7) > > > (In reply to Marc-Andre Lureau from comment #5) > > > > I would suggest to ignore ERROR_IO and consider it has a "clean" CLOSE > > > > event > > > > > > Did you mean to write that "ERROR_IO" should be considered a "clean" CLOSE > > > event? > > > > yes, that's what most spice clients do. So you are sure that ERROR_IO can't mean any other errors that need to be handled? Since the shutdown is initiated from guest, I don't think we have an easy way to differentiate between real and non-real errors here so I think this really needs to be solved by spice.
(In reply to Zeeshan Ali (Khattak) from comment #10) > So you are sure that ERROR_IO can't mean any other errors that need to be > handled? Since the shutdown is initiated from guest, I don't think we have > an easy way to differentiate between real and non-real errors here so I > think this really needs to be solved by spice. ERROR_IO won't help the user much. It would be an abnormal termination, but there is nothing the user can do about it. I don't think it's necessary to notify the user of that, he already got an unexpected disconnection in this case. But with the upcoming spice-gtk release with the SIGHUP ignored, you won't get IO_ERROR on normal disconnection (on unix sockets), so you could also bump the spice-gtk dependency to get rid of this bug.
(In reply to Marc-Andre Lureau from comment #11) > (In reply to Zeeshan Ali (Khattak) from comment #10) > > So you are sure that ERROR_IO can't mean any other errors that need to be > > handled? Since the shutdown is initiated from guest, I don't think we have > > an easy way to differentiate between real and non-real errors here so I > > think this really needs to be solved by spice. > > ERROR_IO won't help the user much. It would be an abnormal termination, but > there is nothing the user can do about it. I don't think it's necessary to > notify the user of that, he already got an unexpected disconnection in this > case. So user is using the box and all of a sudden he is taken into collection view, without any indication of what the hell just happened? I don't think that makes for a good user experience at all. > But with the upcoming spice-gtk release with the SIGHUP ignored, you won't > get IO_ERROR on normal disconnection (on unix sockets), so you could also > bump the spice-gtk dependency to get rid of this bug. I don't think version bump is needed. The error message is annoying, yes but Boxes work just fine otherwise so no need to annoy packagers for it...
(In reply to Zeeshan Ali (Khattak) from comment #12) > > ERROR_IO won't help the user much. It would be an abnormal termination, but > > there is nothing the user can do about it. I don't think it's necessary to > > notify the user of that, he already got an unexpected disconnection in this > > case. > > So user is using the box and all of a sudden he is taken into collection > view, without any indication of what the hell just happened? I don't think > that makes for a good user experience at all. I don't think an error message that you can't do anything about is helpful either. But that's all your call. > > But with the upcoming spice-gtk release with the SIGHUP ignored, you won't > > get IO_ERROR on normal disconnection (on unix sockets), so you could also > > bump the spice-gtk dependency to get rid of this bug. > > I don't think version bump is needed. The error message is annoying, yes but > Boxes work just fine otherwise so no need to annoy packagers for it... Up to you
(In reply to Marc-Andre Lureau from comment #13) > (In reply to Zeeshan Ali (Khattak) from comment #12) > > > ERROR_IO won't help the user much. It would be an abnormal termination, but > > > there is nothing the user can do about it. I don't think it's necessary to > > > notify the user of that, he already got an unexpected disconnection in this > > > case. > > > > So user is using the box and all of a sudden he is taken into collection > > view, without any indication of what the hell just happened? I don't think > > that makes for a good user experience at all. > > I don't think an error message that you can't do anything about is helpful > either. But that's all your call. I don't think error messages are only for things users can actually do anything about. If you go out of cellular range, your phone tells of that even if you can't do anything about it. If I don't show any message, it'll appear as a bug in Boxes even though its likely some networking/connection issue or some problem on server. The *might* be able to get their network fixed if that caused the issue. Having said all that, in the local case, I/O error is most likely going to be caused by bugs like this one and bug#83692 so maybe in that case it does make sense to ignore it.