Client times out on first login if VMs are not running (Qubes only)

[eloquence]

Due to the relatively short timeout period, and the fact that it takes several seconds to launch a Whonix VM and connect to Tor, the first login attempt with the client is likely to fail with the error message "The connection to the SecureDrop server timed out".

[kushaldas]

We should add some sort of default call to the whonix vm (the proxy) to start when client vm starts up.

[conorsch]

Resolved by freedomofpress/securedrop-workstation#255

[eloquence]

I saw this again in Qubes with a freshly provisioned build (make clean && make all), I believe because the sd-whonix VM wasn't running yet. Will try to repro but reopening for now.

[sssoleileraaa]

here's what i did when trying to repro:

1. shutdown sd-proxy and sd-whonix vms
2. log into the client if you are logged out

Expected

sd-whonix and sd-proxy start (takes about 30 seconds or so), sd-whonix shows that it's connecting to Tor, then my user account is authenticated and login is successful

Actual

sd-whonix and sd-proxy start (takes about 30 seconds or so), sd-whnoix shows that it's connecting to Tor, then I see "There was a problem signing in"

[redshiftzero]

hmm so both sd-proxy and sd-whonix (since the NetVM is started when sd-proxy starts) start on boot for me (as I would expect since freedomofpress/securedrop-workstation#255) - can you confirm if this is also the case for you?

[eloquence]

I am 99% sure I didn't reboot after running make all. If possible, I think we should still have a smarter check on login to ensure the VMs are running, rather than just failing. I've retitled the issue accordingly and moved it off the beta milestone for now.

[eloquence]

Can confirm that this now works in local testing, though beating the TOTP clock if VMs aren't running yet appears to be luck of the draw.

[sssoleileraaa]

could you make a separate issue for checking if certain VMs are running from the client?