I’ve seen this several times. You select “shutdown” for a qube, watch it shut down, then immediately you get a notification that the qube is starting again.
It seems to be when qrexec has something queued up
For example something was wrong with sys-gui-vnc, and typing: qvm-run --pass-io sys-gui-vnc ls
just hangs (because i forgot the --no-gui parameter). In a attempt to fix it, I tried selecting the shutdown option from “qubes domains” gui widget and shut sys-gui-vnc down. it started right back up. I tried shutting it down, and it came back up 6 times in a row. I’m assuming that trying it a 7th or 8th time wont help anything, and that i’ll need to shut down the whole system (I.E. dom0)
My guess is that the qvm-run --pass-io sys-gui-vnc ls command didn’t work the previous time, then it realizes that the qube is stopped, so it starts the qube as if i had just issued the command. Then after sys-gui-vnc is started, it tries it again and the same problem of it not responding to qrexec is happening,
Anyone have any ideas if that’s what’s actually going on?
I think you’re right about your assumptions. You can see the qvm-run commands queued in dom0, e.g. via `ps-aux|grep qvm-run’.
Probably qvm-run should have a timeout after which it stops waiting for a VM to start.
Or, alternatively, it should consider the command “done” once the qube has started once.
I do recall seeing qubes restart unexpectedly lately, particularly when I “kill” them after they hang for whatever reason, and that may be this same issue.
I’m getting the same. Been playing with gpg split. Now ‘gpg’ gets autostarted and is immortal. its clone isn’t. But if I clone it back, it’s immortal again. Also if I create any new qube called ‘gpg’ that becomes immortal regardless of template (eg even a standalone with FreeBSD boot)
But running ps - aux | grep qvm-run in dom0 returns nothing. May just give up and call it gpg2 but I’d still like to know why it keeps restarting and, perhaps more importantly, how to diagnose such issues.
The issue I was having was a scripting issue. I would qvm-run things on every qube that was running every 5 min, and it would take longer then 5 min for the qube to shut down, meaning it would be queued to come back up the instant it was shut down.
I would recommend looking into if anything is sending gpg requests to the gpg qube, and if so, shut those qubes making the requests down. Or alternatively, shut all qubes down except gpg (and probably sys-usb), and see if you can shut gpg down then. If so, you know that one of the qubes you shut down is your culprit.