Trellis multisite vagrant up success, but after reboot page refuses to connect

I have a Wordpress multisite that I’m trying to run through a vagrant machine, and it’s doing some very strange things.

If I start from scratch with no server and vagrant up, the process proceeds as normal and the virtual machine is created successfully and the dev site works fine.

However, if I then vagrant halt and vagrant up again, things get weird. The machine boots with no errors in the terminal (“Your Trellis Vagrant box is ready to use!”), but trying to go to the url fails, with chrome saying “This site can’t be reached. [sitename].test refused to connect.” The only way to get the site working again is to do a vagrant destroy and vagrant up and port my database over all over again.

I’m not really sure how to fix something like this if the terminal isn’t returning any errors, and I find it strange that it would work initially but not after a reboot. Any ideas?

If you’re using landrush for multisite, I wonder if you have to vagrant landrush start after a halt and up.

In the vagrant up process in the terminal, it already specifies that it is starting landrush as part of the process. Still, I just gave “vagrant landrush start” a try, just in case, but the issue is still happening.

Thanks for trying the landrush start.

Unfortunately there are many possible causes. Here are a few common troubleshooting tips for vagrant VMs that aren’t accessible in browser.

Power off or destroy any other VirtualBox VMs. Check the VB GUI for orphaned VMs. Also check vagrant global-status for any weird extra VMs and destroy them if possible. If this last command lists VMs that no longer exist in VB, you can vagrant global-status --prune to remove them from the list.

If you have other VMs, use a different vagrant_ip for each VM.

Check for conflicting entries in your /etc/hosts file.

You could check for helpful info in logs. Run vagrant ssh and check contents of

  • /srv/www/example.com/logs/error.log
  • /var/log/nginx/error.log
  • /var/log/nginx/php7.2-fpm.log (or php7.1-fpm.log)

Looks like you’re using a *.test domain, which should work. Sometimes people get the refused to connect with *.dev on chrome.

If you ever had SSL enabled for this domain, then disabled it, your browser may be forcing https due to HSTS headers having been set, which could cause page to fail to load if the server isn’t serving https requests. In this case, you could re-enable SSL or clear hsts headers in your browser. Trying a different browser that hasn’t loaded this dev site before should be an easy test for whether it might be an hsts issue (possibly hsts if page loads in other browser).

I hope you can resolve it. If you want to pursue it here, go ahead and confirm what you found in checking the items above, and whatever else you’ve tried and discovered.

1 Like

We figured out the issue!

In /var/log/nginx/error.log, there actually were errors being logged every time we did a vagrant up that read:

"/srv/www/[SITE]/current/web/app/uploads/nginx-helper/map.conf" failed (2: No such file or directory) in /etc/nginx/sites-enabled/[SITE].conf:8

We had installed this nginx helper plugin and, for some reason, it was returning this “no such file or directory” error, even though the file/directory DID exist. To solve it, vagrant ssh-ed into the server, typed sudo -i to get root access, and ran service nginx restart. The plugin could now find the file/directory, and refreshing the webpage now loads the site.

The one downside is that now every time I vagrant up I have to go through this process, but it’s MUCH easier than destroying and recreating the VM and porting my database over every time.

2 Likes