After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760692 - Boxes forgot 'run in background' setting for VM
Boxes forgot 'run in background' setting for VM
Status: RESOLVED FIXED
Product: gnome-boxes
Classification: Applications
Component: properties
3.18.x
Other Linux
: Normal normal
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-01-15 22:29 UTC by Michael Catanzaro
Modified: 2016-09-20 08:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Catanzaro 2016-01-15 22:29:45 UTC
Yesterday I turned on the 'run in background' setting for two of my VMs, closed Boxes, and was happy to see they kept running in the background so I could SSH into them.

Today when I closed boxes, the VM got suspended. I discovered that the run in background setting I had toggled the day before had been unexpectedly forgotten, so I set it again. Now it seems to be working again... for now.
Comment 1 Michael Catanzaro 2016-01-15 22:31:23 UTC
(In reply to Michael Catanzaro from comment #0)
> I discovered that the run
> in background setting I had toggled the day before had been unexpectedly
> forgotten, so I set it again.

By the way, this setting was forgotten for BOTH of the VMs that I set it on.
Comment 2 Michael Catanzaro 2016-01-15 23:13:20 UTC
Half an hour later, I discovered my VM had been suspended even though the setting was enabled when I closed Boxes. The setting was, again, reset to off.

In each case, when I reopened Boxes, it had forgotten all my VMs due to Red Hat #1271183.
Comment 3 Michael Catanzaro 2016-01-15 23:55:46 UTC
(In reply to Michael Catanzaro from comment #2)
> Half an hour later, I discovered my VM had been suspended even though the
> setting was enabled when I closed Boxes. The setting was, again, reset to
> off.

Eh, half an hour later, I discovered my VM had been suspended even though Boxes was open (but minimized) and I had not changed the value of the setting. Weird....
Comment 4 Zeeshan Ali 2016-03-15 12:33:19 UTC
Hm.. I've been trying to reproduce here but no luck. Is it possible that it's a symptom of https://bugzilla.redhat.com/show_bug.cgi?id=1271183 ?

Or this could be another regression that moved configuration files to .cache at some point. Did you happen to clear your .cache around the time this happened?
Comment 5 Zeeshan Ali 2016-03-15 14:36:10 UTC
(In reply to Zeeshan Ali (Khattak) from comment #4)
> Or this could be another regression that moved configuration files to .cache
> at some point. Did you happen to clear your .cache around the time this
> happened?

If this was the case, I just pushed patches to fix this. Please try again with git master?
Comment 6 Michael Catanzaro 2016-03-15 18:28:52 UTC
(In reply to Zeeshan Ali (Khattak) from comment #4)
> Hm.. I've been trying to reproduce here but no luck. Is it possible that
> it's a symptom of https://bugzilla.redhat.com/show_bug.cgi?id=1271183 ?

Maybe? I'll put it on my to-do list to test this again once that bug gets fixed.

> Or this could be another regression that moved configuration files to .cache
> at some point. Did you happen to clear your .cache around the time this
> happened?

No, I would not have cleared my cache. g-s-d might have, but not on two consecutive days when I first noticed this issue.
Comment 7 Zeeshan Ali 2016-03-15 18:55:30 UTC
(In reply to Michael Catanzaro from comment #6)
> (In reply to Zeeshan Ali (Khattak) from comment #4)
> > Hm.. I've been trying to reproduce here but no luck. Is it possible that
> > it's a symptom of https://bugzilla.redhat.com/show_bug.cgi?id=1271183 ?
> 
> Maybe? I'll put it on my to-do list to test this again once that bug gets
> fixed.

I just checked by intentionally putting a bad URL in the configuration of default (libvirt) source and it had the effect of Boxes deleting the configuration for all the boxes. So I'm pretty sure now that this is a symptom of that libvirt bug.

I think Boxes should not be removing the configuration on failure to connect to the source so I'll try to fix that bit..
Comment 8 Zeeshan Ali 2016-03-15 19:36:02 UTC
I tested these patches to work but if you can test them too, that would be nice. If you can reproduce that libvirt issue,  you just need git master of Boxes.

---
commit: f7ba9bf55ca7e2f891c901bada7d33505fb35568
Date:   Tue Mar 15 19:24:54 2016 +0000

    app: Remove a now redundant null check
    
    We moved setup of default source into a separate function a while ago
    and it's called before setup_sources() so there is no need to check for
    default source being properly setup at this stage anymore.

commit: 7783fd209d013896393d68bd34f58f464b8e11ed
Date:   Tue Mar 15 19:27:13 2016 +0000

    broker: add_source() should be able to fail
    
commit: e57a9cd558224465cdcc5b9dc68a25470a9d5364
Date:   Tue Mar 15 19:27:36 2016 +0000

    libvirt-broker: Throw error on failure to connect
    
    We were happily adding the source even after failing to connect to it,
    which among other things, meant removal of configuration of all the
    domains on the source in question.
Comment 9 Michael Catanzaro 2016-03-26 16:07:16 UTC
(In reply to Zeeshan Ali (Khattak) from comment #8)
> I tested these patches to work but if you can test them too, that would be
> nice. If you can reproduce that libvirt issue,  you just need git master of
> Boxes.

Well, it seems the setting is now properly remembered, so that's good. But the VMs still get suspended when I close Boxes. Is this intentional? It's not what I would expect -- having enabled a run in background setting, I would expect the VM to keep running after closing Boxes until I explicitly power it off somehow.
Comment 10 Zeeshan Ali 2016-03-29 15:23:45 UTC
(In reply to Michael Catanzaro from comment #9)
> (In reply to Zeeshan Ali (Khattak) from comment #8)
> > I tested these patches to work but if you can test them too, that would be
> > nice. If you can reproduce that libvirt issue,  you just need git master of
> > Boxes.
> 
> Well, it seems the setting is now properly remembered, so that's good. But
> the VMs still get suspended when I close Boxes. Is this intentional? It's
> not what I would expect -- having enabled a run in background setting, I
> would expect the VM to keep running after closing Boxes until I explicitly
> power it off somehow.

Yes, that is exactly the intended behaviour and it works fine here. Maybe you're hitting some corner case. Was it just one VM or multiple that you have enabled this for? I'm hoping with more details, I can reproduce your issue here.