Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

timeout during server version negotiating #2717

Open
shanebp opened this issue Jun 21, 2024 · 35 comments
Open

timeout during server version negotiating #2717

shanebp opened this issue Jun 21, 2024 · 35 comments
Labels
type:bug

Comments

@shanebp
Copy link

shanebp commented Jun 21, 2024 •
edited
Loading

Are you using the latest stable or develop branch version of VVV?

Yes (stable)

Is it a new VVV, or an existing VVV that used to work?

Existing, worked but now broken

Did you use a CustomFile?

No (default)

Whats the problem?

Using Windows 10.

Everything was working properly until today. Tried to vagrant up but get this error: timeout during server version negotiating. The vagrant machine is running.

I can open the vvv dashboard in a browser, but none of the sites will connect.

Output:
c:\vvv-local>vagrant up

\ V\ V\ V / v3.12 Ruby:3.1.4, Path:"c:/vvv-local"
_/_/_/ git::stable(aee9a69)

Platform: mingw32 windows missingWinAdminPriv vagrant-goodhosts monochrome-terminal shared_db_folder_disabled
Vagrant: v2.4.1, virtualbox: v7.0.18

Docs: https://varyingvagrantvagrants.org/
Contribute: https://github.com/varying-vagrant-vagrants/vvv
Dashboard: http://vvv.test

Bringing machine 'default' up with 'virtualbox' provider...
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] Checking for host entries
==> default: [vagrant-goodhosts] Finished processing
==> default: Machine already provisioned. Run vagrant provision or use the --provision
==> default: flag to force provisioning. Provisioners marked to run always will still run.
==> default: Running action triggers after up ...
==> default: Running trigger: VVV Post-Up...
==> default: Trigger run failed
==> default: An error occurred in the underlying SSH library that Vagrant uses.
==> default: The error message is shown below. In many cases, errors from this
==> default: library are caused by ssh-agent issues. Try disabling your SSH
==> default: agent or removing some keys and try again.
==> default:
==> default: If the problem persists, please report a bug to the net-ssh project.
==> default:
==> default: timeout during server version negotiating

How do we reproduce it?

No response

What is the output of vagrant status

c:\vvv-local>vagrant status
__ __ __ __
\ V\ V\ V / v3.12 Ruby:3.1.4, Path:"c:/vvv-local"
 \_/\_/\_/  git::stable(aee9a695)

Platform: mingw32 windows  missingWinAdminPriv  vagrant-goodhosts monochrome-terminal shared_db_folder_disabled
Vagrant: v2.4.1, virtualbox: v7.0.18

Docs:       https://varyingvagrantvagrants.org/
Contribute: https://github.com/varying-vagrant-vagrants/vvv
Dashboard:  http://vvv.test

Current machine states:

default                   running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.

Which Operating System are you using?

Microsoft Windows

Which provider are you using?

VirtualBox 7
@tomjn
Copy link
Member

tomjn commented Jun 21, 2024 via email

@tomjn
Copy link
Member

tomjn commented Jun 21, 2024 via email

@shanebp
Copy link
Author

shanebp commented Jun 21, 2024 •
edited by unfurl-links bot
Loading

I did a reboot. And then vagrant destroy followed by vagrant up.
Here is the output: https://gist.github.com/shanebp/86217d6010ed38c931da20c14fadb826

Not sure how to use develop branch.

Gist
vagrant up . GitHub Gist: instantly share code, notes, and snippets.

@tomjn
Copy link
Member

tomjn commented Jun 21, 2024 via email

@tomjn
Copy link
Member

tomjn commented Jun 21, 2024 via email

@shanebp
Copy link
Author

shanebp commented Jun 21, 2024

Switched to develop branch and everything is working now.

@tomjn
Copy link
Member

tomjn commented Jun 21, 2024 via email

@shanebp
Copy link
Author

shanebp commented Jun 21, 2024

3.14.0

@tomjn
Copy link
Member

tomjn commented Aug 14, 2024

If this happens again feel free to reopen, closing as there's been no disussion since june

@tomjn tomjn closed this as completed Aug 14, 2024
@shanebp
Copy link
Author

shanebp commented Aug 28, 2024 •
edited by tomjn
Loading

Getting the same error again on vagrant up: timeout during server version negotiating

Tried:

  • rebooting
  • switching to stable branch
  • updating VirtualBox to 7.0.20

No luck...

c:\vvv-local>vagrant up
__ __ __ __
\ V\ V\ V / v3.13.2 Ruby:3.1.4, Path:"c:/vvv-local"
 \_/\_/\_/  git::stable(e0dad5de)

Platform: mingw32 windows  HasWinAdminPriv  vagrant-goodhosts monochrome-terminal shared_db_folder_disabled
Vagrant: v2.4.1, virtualbox: v7.0.20

Docs:       https://varyingvagrantvagrants.org/
Contribute: https://github.com/varying-vagrant-vagrants/vvv
Dashboard:  http://vvv.test

Bringing machine 'default' up with 'virtualbox' provider...
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddypress.test
==> default: [vagrant-goodhosts] Checking for host entries
==> default: [vagrant-goodhosts] Finished processing
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.
==> default: Running action triggers after up ...
==> default: Running trigger: VVV Post-Up...
==> default: Trigger run failed
==> default: An error occurred in the underlying SSH library that Vagrant uses.
==> default: The error message is shown below. In many cases, errors from this
==> default: library are caused by ssh-agent issues. Try disabling your SSH
==> default: agent or removing some keys and try again.
==> default:
==> default: If the problem persists, please report a bug to the net-ssh project.
==> default:
==> default: timeout during server version negotiating

@tomjn
Copy link
Member

tomjn commented Aug 28, 2024

Can you open the virtualbox management software and force the VM to switch off? Then try again.

Likewise have you changed the program you use for your terminal recently or anything related to git CLI? Windows doesn't have a native sockets implementation and there are multiple competing solutions to work around this. Vagrant implements cygwin and the msysgit but not others. This is why some terminals on Windows generate timeouts, and why we suggest installing git in the software requirements for Windows users

@shanebp
Copy link
Author

shanebp commented Aug 28, 2024

Yes, I tried forcing the VM off and then restarted - no luck.

This worked, but destroyed the existing data...
$ vagrant destroy --force
$ vagrant up --debug

Any way to do that and preserve the database? Or install a backup of the database?

@tomjn
Copy link
Member

tomjn commented Aug 28, 2024

Any way to do that and preserve the database? Or install a backup of the database?

You can take a backup manually if it isn't auto-backing up ( we turned off auto-backup a while ago ). The only way for the database to be preserved by a destroy without a backup/restore is to enable the shared DB folder, but this is highly unstable and may result in weirdness and unreliability of basic things.

Overall it's highly unlikely that a destroy will fix that issue, and if it was a problem with the VM the biggest change is the destruction of useful debugging data.

@tomjn
Copy link
Member

tomjn commented Aug 28, 2024

If you didn't have a backup when you destroyed the VM then that data is gone forever. destroy is the thermonuclear option.

It's much more likely that there's something that has changed recently on your system in one of the pieces of software that's used, e.g. updating virtualbox, the terminal or prompt used ( they really do matter, e.g. powershell is not the same as windows terminal which is not the same as cmd.exe etc, even though they all look and behave the same, even if you use what you had always used but had installed an alternative and decided not to bother with it )

@tomjn
Copy link
Member

tomjn commented Aug 28, 2024

A good check of the software setup is to create a second VVV in a second folder, if that fails to provision with the same issues then you can rule out the VM being the problem

@tomjn
Copy link
Member

tomjn commented Aug 28, 2024 •
edited
Loading

This issue may be a useful read: #2505 specifically #2505 (comment)

@tomjn
Copy link
Member

tomjn commented Aug 28, 2024 •
edited by unfurl-links bot
Loading

A new Windows page underneath troubleshooting has been created! https://varyingvagrantvagrants.org/docs/en-US/troubleshooting/windows/

VVV
Windows issues.

@shanebp
Copy link
Author

shanebp commented Aug 28, 2024

Ok, thanks for all the info.

@shanebp
Copy link
Author

shanebp commented Sep 6, 2024 •
edited
Loading

Still failing to connect to database, every couple of days.
Having to destroy the box each time is not feasible.

It seems that ssh is working:

sam3d@DESKTOP-OU7IM78 MINGW64 /c/vvv-local
$ eval "$(ssh-agent -s)"
Agent pid 920

sam3d@DESKTOP-OU7IM78 MINGW64 /c/vvv-local (develop)
$ vagrant halt
==> default: Running action triggers before halt ...
==> default: Running trigger: VVV Pre-Halt...
==> default: Trigger run failed
==> default: An error occurred in the underlying SSH library that Vagrant uses.
==> default: The error message is shown below. In many cases, errors from this
==> default: library are caused by ssh-agent issues. Try disabling your SSH
==> default: agent or removing some keys and try again.
==> default:
==> default: If the problem persists, please report a bug to the net-ssh project.
==> default:
==> default: timeout during server version negotiating
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 scotthom.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddypress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 scotthom.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddypress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 scotthom.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddypress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 scotthom.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddypress.test
==> default: [vagrant-goodhosts] Removing hosts
==> default: [vagrant-goodhosts] Finished processing
==> default: Attempting graceful shutdown of VM...
    default: Guest communication could not be established! This is usually because
    default: SSH is not running, the authentication information was changed,
    default: or some other networking issue. Vagrant will force halt, if
    default: capable.
==> default: Forcing shutdown of VM...


sam3d@DESKTOP-OU7IM78 MINGW64 /c/vvv-local (develop)
$ vagrant up
__ __ __ __
\ V\ V\ V / v3.14 Ruby:3.1.4, Path:"C:/vvv-local"
 \_/\_/\_/  git::develop(a65ffe1e)

Platform: mingw32 windows  missingWinAdminPriv  vagrant-goodhosts monochrome-terminal shared_db_folder_disabled
Vagrant: v2.4.1, virtualbox: v7.0.20

Docs:       https://varyingvagrantvagrants.org/
Contribute: https://github.com/varying-vagrant-vagrants/vvv
Dashboard:  http://vvv.test

Bringing machine 'default' up with 'virtualbox' provider...
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 scotthom.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddypress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 scotthom.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddypress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 scotthom.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddypress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 vvv.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 wordpress.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddyboss.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 scotthom.test
==> default: [vagrant-goodhosts] - found entry for: 192.168.56.4 buddypress.test
==> default: [vagrant-goodhosts] Checking for host entries
==> default: [vagrant-goodhosts] Finished processing
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.
==> default: Running action triggers after up ...
==> default: Running trigger: VVV Post-Up...
==> default: Trigger run failed
==> default: An error occurred in the underlying SSH library that Vagrant uses.
==> default: The error message is shown below. In many cases, errors from this
==> default: library are caused by ssh-agent issues. Try disabling your SSH
==> default: agent or removing some keys and try again.
==> default:
==> default: If the problem persists, please report a bug to the net-ssh project.
==> default:
==> default: timeout during server version negotiating

sam3d@DESKTOP-OU7IM78 MINGW64 /c/vvv-local (develop)
$ eval "$(ssh-agent -s)"
Agent pid 988

Is the change in Agent pid a clue?

@tomjn
Copy link
Member

tomjn commented Sep 6, 2024

Is the change in Agent pid a clue?

It shouldn't matter what the pid is, have you ran that before the vagrant commands?

@tomjn
Copy link
Member

tomjn commented Sep 6, 2024 •
edited by unfurl-links bot
Loading

This might be useful:

https://docs.github.com/en/authentication/connecting-to-github-with-ssh/working-with-ssh-key-passphrases#auto-launching-ssh-agent-on-git-for-windows

The SSH Agent is supposed to start automatically but in some instances it doesn't, or needs setting up again.

Can you confirm in the virtualbox software that the VM does start? Even if vagrant commands give SSH timeouts? Do you happen to have Putty/Peagant installed?

GitHub Docs
You can secure your SSH keys and configure an authentication agent so that you won't have to reenter your passphrase every time you use your SSH keys.

@tomjn tomjn reopened this Sep 6, 2024
@tomjn
Copy link
Member

tomjn commented Sep 6, 2024 •
edited by unfurl-links bot
Loading

This stackoverflow answer links to that too but adds more context/detail https://stackoverflow.com/a/18404557/57482

Of note it seems if you have multiple git bash sessions and close the first, the ssh agent goes with it and the remaining shells have no ssh agent

Stack Overflow
I am using git bash. I have to use

eval ssh-agent.exe
ssh-add /my/ssh/location/
every time when I start a new git bash.

Is there a way to set ssh agent permanently? Or does windows has a good ...

@shanebp
Copy link
Author

shanebp commented Sep 6, 2024 

sam3d@DESKTOP-OU7IM78 MINGW64 /c/vvv-local (develop)
$ eval "$(ssh-agent -s)"
Agent pid 988

  • have you ran that before the vagrant commands?
    Yes, before and after. Since a pid is returned, doesn't that mean ssh-agent is running? The articles you mention ( thanks ) seem to focus on starting ssh-agent, yes?

  • Can you confirm in the virtualbox software that the VM does start? Even if vagrant commands give SSH timeouts?
    Yes, every time. The VVV dashboard loads - but none of the sites can connect to the database.

  • Do you happen to have Putty/Peagant installed?
    I have puttygen installed. - that's all.

@tomjn
Copy link
Member

tomjn commented Sep 6, 2024

Yes, every time. The VVV dashboard loads - but none of the sites can connect to the database.

Does vagrant ssh work or does it timeout? Is this git bash running in the git bash window or git bash running in another terminal window? Can you share a screenshot including the window chrome?

@shanebp
Copy link
Author

shanebp commented Sep 6, 2024

Screenshot of git bash window that opens when I open "Git Bash"
Untitled

Here is the full log of commands:

sam3d@DESKTOP-OU7IM78 MINGW64 /c/vvv-local (develop)
$ vagrant ssh
VM must be running to open SSH connection. Run `vagrant up`
to start the virtual machine.

sam3d@DESKTOP-OU7IM78 MINGW64 /c/vvv-local (develop)
$ vagrant up
__ __ __ __
\ V\ V\ V / v3.14 Ruby:3.1.4, Path:"C:/vvv-local"
 \_/\_/\_/  git::develop(a65ffe1e)

Platform: mingw32 windows  missingWinAdminPriv  vagrant-goodhosts monochrome-terminal shared_db_folder_disabled
Vagrant: v2.4.1, virtualbox: v7.0.20

Docs:       https://varyingvagrantvagrants.org/
Contribute: https://github.com/varying-vagrant-vagrants/vvv
Dashboard:  http://vvv.test

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

sam3d@DESKTOP-OU7IM78 MINGW64 /c/vvv-local (develop)
$ vagrant ssh


sam3d@DESKTOP-OU7IM78 MINGW64 /c/vvv-local (develop)
$

Seems the last vagrant ssh timed out...?
So I ran it with debug: vagrant ssh --debug
Here is the result on gist.

@shanebp
Copy link
Author

shanebp commented Sep 8, 2024

It seems this is a known issue with ssh-agent being stopped or restarted when Windows comes out of sleep.
I've read through many posts - all well above my level of understanding - but it seems that turning port-forwarding on or off is part of the solution.
Could port-forwarding cause issues with VVV ?

@tomjn
Copy link
Member

tomjn commented Sep 8, 2024 via email

@tomjn
Copy link
Member

tomjn commented Sep 8, 2024 via email

@shanebp
Copy link
Author

shanebp commented Sep 8, 2024

I think it has to do with Vagrant or Virtual Box changing, stopping or 'hanging' ssh-agent when resuming from Windows sleep.

I bookmarked my research from yesterday - but didn't notice that the answers were AI-generated. So the bookmarks do not return the same info I saw yesterday ( ! ) when I did a search on vagrant ssh-agent windows sleep

The info included things like:

  • try to keep the devices.net.sleep_disconnects_link=0; devices.net.dhcp.notify=0 and SSH into VMs directly, i. e. without port forwarding.
  • Not using port forwarding to SSH into VMs seems to resolve the issue

I don't know what that means or how to implement. So before trying, I thought I'd ask if there are any issues with such tinkering vis-a-vis VVV.

@tomjn
Copy link
Member

tomjn commented Sep 8, 2024 •
edited
Loading

I'd be very suspicious of those, the only reference I can find for devices.net... is in a Parallels vagrant issue with MacOS users:

Parallels/vagrant-parallels#334 (comment)

and SSH into VMs directly, i. e. without port forwarding.

That's not really how SSH works with VVV, if you run vagrant ssh-config it will spit out an SSH config intended for your SSH config file so you can use ssh directly, this is what it gives me under MacOS with the docker provider:

vvv-local on  develop [$?] via ⍱ v2.4.1 
❯ vagrant ssh-config
Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/tomjn/.vagrant.d/insecure_private_keys/vagrant.key.ed25519
  IdentityFile /Users/tomjn/.vagrant.d/insecure_private_keys/vagrant.key.rsa
  IdentitiesOnly yes
  LogLevel FATAL
  ForwardAgent yes
  PubkeyAcceptedKeyTypes +ssh-rsa
  HostKeyAlgorithms +ssh-rsa


vvv-local on  develop [$?] via ⍱ v2.4.1 
❯

It's meant to speed things up a little but has caveats, it might provide useful information here but it's unlikely.

Port forwarding is something that can be done but if you look in the VVV vagrant file you'll see it's commented out with a note about disabling it, so there's nothing to disable there. Agent forwarding is the closest here but that would not cause your problem, it's what allows the VVV provisioners to use your SSH keys to grab stuff without copying the data into the VM. If Agent forwarding failed then you would be able to start and stop the VM fine, it would only be attempts to use private Github repos that failed.

Does starting a new separate second instance of VVV in a different folder work? What happens if you try to add an SSH key or do a test connection to github ( ssh -T [email protected] ) does it succeed and does it print out your github username or someone unexpected?

@tomjn
Copy link
Member

tomjn commented Sep 8, 2024

Also noting that the reason the database isn't running is because it's started by a script that runs once the VM is up by vagrant, with the SSH connectivity issue you're having it never gets the chance to start the database up. This is also the likely reason why you can only access it via the IP, the next step vagrant would have taken would have started vagrant-goodhosts and updated the hosts file.

@tomjn
Copy link
Member

tomjn commented Sep 8, 2024 •
edited
Loading

Also check the git version installed git --version against https://git-scm.com/download/win, if you do reinstall try to avoid using the Windows OpenSSH service if it asks ( vagrant doesn't know how to talk to this ).

I'd also note that if it is sleep related then you'd be able to start VVV ok after a restart and it would work fine until your machine went to sleep.

@shanebp
Copy link
Author

shanebp commented Sep 9, 2024

Empirical evidence strongly points to an ssh issue on resume from sleep.
But it seems it is not VVV-specific.
I appreciate your time and comments - but I'm lost.
So I'll leave it alone for now and just up / halt when I need local server - and thereby always have sql backups.

@tomjn
Copy link
Member

tomjn commented Sep 9, 2024

Ah so if you reboot it does work as expected as long as you don't sleep? I'll update the Windows troubleshooting page, you might want to experiment with the Hyper-V provider

@shanebp
Copy link
Author

shanebp commented Sep 9, 2024 •
edited
Loading

if you reboot it does work as expected as long as you don't sleep?

Yes, but windows will restart occasionally without asking first. And I lose the database connection and do not have current sql backups.

If vagrant is up and the laptop sleeps then it might lose the database connection when windows resumes.
If vagrant is down and the laptop sleeps, then I can always resume windows, restart vagrant and everything works.
vagrant up takes 50 secs and vagrant halt takes 10 secs - I can live with that and always have sql backups..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type:bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tomjn @shanebp