Bug 848440 - (gnome-boxes:9436): Boxes-WARNING **: app.vala:233: Unable to open qemu+unix:///session: no connection driver available for No connection for URI qemu:///session
(gnome-boxes:9436): Boxes-WARNING **: app.vala:233: Unable to open qemu+unix:...
Status: CLOSED DUPLICATE of bug 842068
Product: Fedora
Classification: Fedora
Component: gnome-boxes (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Christophe Fergeau
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-15 11:44 EDT by Martin
Modified: 2014-09-14 20:03 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-20 09:46:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gdb log (9.77 KB, application/octet-stream)
2012-08-15 11:44 EDT, Martin
no flags Details

  None (edit)
Description Martin 2012-08-15 11:44:59 EDT
Created attachment 604629 [details]
gdb log

Description of problem:
Gnome Boxes starts, but with frozen GUI.

(gnome-boxes:9436): Boxes-WARNING **: app.vala:233: Unable to open qemu+unix:///session: no connection driver available for No connection for URI qemu:///session

Version-Release number of selected component (if applicable):
gnome-boxes-3.5.5-1.fc18.x86_64
libvirt-0.10.0-0rc0.fc18.x86_64

How reproducible:
always

Steps to Reproduce:
1. Run gnome-boxes
  
Actual results:
Boxes is frozen after start.

Expected results:
Boxes should work.
Anyway Boxes should notify user in GUI about connection error.

Additional info:
ps aux|grep libvirt
root      1077  0.0  0.3 485460 13976 ?        Ssl  09:03   0:00 /usr/sbin/libvirtd
nobody    1215  0.0  0.0  13100   732 ?        S    09:03   0:00 /sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override
nobody    1256  0.0  0.0  13100   736 ?        S    09:03   0:00 /sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/virtbridge.pid --conf-file= --except-interface lo --listen-address 192.168.100.1 --dhcp-range 192.168.100.128,192.168.100.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/virtbridge.leases --dhcp-lease-max=127 --dhcp-no-override
mholec    9269  0.3  0.3 583692 12492 ?        Sl   11:33   0:00 /usr/sbin/libvirtd --timeout=30
root      9413  0.0  0.0 109188   996 pts/0    S+   11:35   0:00 grep --color=auto libvirt
Comment 1 Daniel Berrange 2012-08-15 12:14:07 EDT
The libvirt issue is fixed in libvirt-0.10.0-0rc0.2.fc18 (see bug 842068)
Comment 2 Christophe Fergeau 2012-08-16 04:19:10 EDT
Thanks Daniel for the pointer, this leaves "Anyway Boxes should notify user in GUI about connection error"
Comment 3 Martin 2012-08-16 09:24:46 EDT
Another error which should be handled in GUI:

(gnome-boxes:2670): Boxes-WARNING **: libvirt-machine.vala:533: Failed to start 'fedora17': Unable to start domain: cannot access file '/home/mholec/Stažené/Fedora-17-x86_64-DVD.iso': No such file or directory
Comment 4 Zeeshan Ali 2012-08-20 09:46:09 EDT
(In reply to comment #2)
> Thanks Daniel for the pointer, this leaves "Anyway Boxes should notify user
> in GUI about connection error"

As I have said before, broken installations are not something I'm interested in annoying the user with in the UI. As long as we dump enough information on the log to be able to figure out the issue (as was done on this bug), there is nothing else Boxes should be doing.

(In reply to comment #3)
> Another error which should be handled in GUI:
> 
> (gnome-boxes:2670): Boxes-WARNING **: libvirt-machine.vala:533: Failed to
> start 'fedora17': Unable to start domain: cannot access file
> '/home/mholec/Stažené/Fedora-17-x86_64-DVD.iso': No such file or directory

If this happens during installation, its very rare for user to delete the ISO immediately after choosing it in the wizard (and its very much user error). If this happened after installation, something must have gone wrong (libvirt events not getting it e.g) and VM was not marked as installed and the ISO was therefore not marked as optional.

Anyways, I don't think this error belong in the UI either and if you disagree, please open a different bug so we discuss it there as its unrelated to this bug.

*** This bug has been marked as a duplicate of bug 842068 ***
Comment 5 Martin 2012-08-21 10:29:50 EDT
(In reply to comment #4)
> (In reply to comment #2)
> > Thanks Daniel for the pointer, this leaves "Anyway Boxes should notify user
> > in GUI about connection error"
> 
> As I have said before, broken installations are not something I'm interested
> in annoying the user with in the UI. As long as we dump enough information
> on the log to be able to figure out the issue (as was done on this bug),
> there is nothing else Boxes should be doing.
Frozen Boxes when starting is lot more annoying for user then polite error notification in GUI. It is an exception and it should be handled properly instead of just freezing an application.
Comment 6 Zeeshan Ali 2012-08-22 11:07:38 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > Thanks Daniel for the pointer, this leaves "Anyway Boxes should notify user
> > > in GUI about connection error"
> > 
> > As I have said before, broken installations are not something I'm interested
> > in annoying the user with in the UI. As long as we dump enough information
> > on the log to be able to figure out the issue (as was done on this bug),
> > there is nothing else Boxes should be doing.
> Frozen Boxes when starting is lot more annoying for user then polite error
> notification in GUI. It is an exception and it should be handled properly
> instead of just freezing an application.

Boxes is broken in this case and its very unrecoverable system-level error that I don't expect end-users to be able to do anything about. There is no point in showing them an error. In either case, they'll simply decide not to use boxes (at least for a while) and turn to some alternatives. At best they might file a bug and thats where we'll need more debug on the console..

Things like these should not happen in the first place. Thats what we must focus on.
Comment 7 Christophe Fergeau 2012-08-27 05:34:48 EDT
(In reply to comment #6)

> Things like these should not happen in the first place. Thats what we must
> focus on.

We'll be doing our best to make sure libvirt/selinux/... never break, but so far breakages have unfortunately happened from time to time. So we can stick our heads in the sand, and keep saying 'these breakages should not happen'. Or we can accept that real world is far from being perfect, and fail gracefully when bad things happen (even if it means we display a fail-whale-like screen) instead of freezing/crashing/... which makes us look even worse to the user.
Comment 8 Zeeshan Ali 2012-08-27 12:48:05 EDT
(In reply to comment #7)
> (In reply to comment #6)
> 
> > Things like these should not happen in the first place. Thats what we must
> > focus on.
> 
> We'll be doing our best to make sure libvirt/selinux/... never break, but so
> far breakages have unfortunately happened from time to time.

When things break, we fix them! Thats it. We have argued about this a lot in the past and we both have failed to convince each other so we both should move on and let eachother decide the approach for projects are responsible for.
Comment 9 Christophe Fergeau 2012-08-27 16:27:24 EDT
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > 
> > > Things like these should not happen in the first place. Thats what we must
> > > focus on.
> > 
> > We'll be doing our best to make sure libvirt/selinux/... never break, but so
> > far breakages have unfortunately happened from time to time.
> 
> When things break, we fix them! Thats it. 

Of course we do want to fix them, but between the time the breakage is reported and the time the fix gets to users' machines, boxes looks bad... And honestly, all this discussion really feels like "should developers handle errors in their code?", which I still hope we can agree on...

Note You need to log in before you can comment on or make changes to this bug.