I created a new site in order to test out and learn about Ajax Headless setups, but after creating the site it won’t start. Instead shell windows keep popping up and dissappearing endlessly, two at a time.
Troubleshooting Questions
Only happens to Ajax sites even when they are brand new.
During the error the frontend returns a 502 error, but the backend works normally. local-logs.zip (7.5 KB)
Regular wordpress site works normally in all respects
Replication
All I have to do to replicate the issue is creating a new headless site on a windows 11 install of local, updated to the latest version. (7.0.1+6387)
I don’t know how anyone else can reproduce this.
System Details
Which version of Local is being used?
(7.0.1+6387)
What Operating System (OS) and OS version is being used?
Windows 11 Home & Windows 10 Home
@Nick-B No, I just tried creating the node sites with the blueprints.
Interestingly, now that I tried creating a test site without using a blueprint, according to that help doc, the site spins up normally and the “Node.js Host” URL works just fine. However using the “Open site” link to open the URL I gave, I get the 404 error “The site you requested does not have an associated route in Local.”
I did not notice anything about setting up that route in the help doc.
I looked back at your original log and there are a lot of errors like this:
{"thread":"main","class":"Process","process":"mariadb","level":"warn","message":"2023-06-19 16:32:05 9 [ERROR] mysqld.exe: Table '.\\local\\wp4fk8_options' is marked as crashed and should be repaired","timestamp":"2023-06-19T13:32:05.948Z"}
The “marked as crashed and should be repaired” could indicate a hardware issue like corruption or lack of disk space. There are some other errors in there as well that could indicate an issue with mariadb.
I feel that it is unlikely that it is a hardware issue, since I have the exact same issue on two very different systems: A 2 year old laptop with windows 11 (Where the logs are from) and a 8 year old desktop with windows 10. And neither of them are short on disk space.
I’ll read those links and see if there is something I can try there when I have a spot of time on my hands.
Well, I cleared the log and fixed the database tables but the problem still persists. However the log now doesn’t contain any warnings pertaining to mariadb anymore. There are mysql messages about crash recovery starting and finishing. Any tips on where there might be a mysql log that might have more info on why it is crashing?
Funnily enough the local-lightning-verbose log doesn’t show those mysql warnings at all just nodejs messages.
Here are the logs, local-logs.zip (7.8 KB)
I cleared them again, then created a new portfolio blueprint site and tried to restart it a couple of times. The frontend url for the site is blueprinttest6.local but it just gets a 404 error, while the Node.js frontend address localhost:10019 does not respond at all (ERR_CONNECTION_RESET says the browser).
All the while there are two console windows opening and closing constantly.
I checked with our Devs on this, and in the router log, they’re noticing this entry for that 127.0.0.1:10019 URL you’ve mentioned:
2023/07/06 22:56:25 [error] 28840#9720: *1 WSARecv() failed (10054: An existing connection was forcibly closed by the remote host) while reading response header from upstream, client: ::1, server: bt5.local, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:10019/", host: "bt5.local"
“Upstream” in this case likely means the PHP process for that specific site. It almost seems like the PHP process for the site accepts the request, but then crashes midway through fulfilling the request. In order to get a bit more information, could you enable WP_DEBUG for the site and then try again to make the connection? After that, there should be some additional details in the site’s server logs to help us move further along.
Thanks for providing those logs @ramela – Since these errors seem to be more related to the individual site than to Local as a whole, can you provide the individual site’s server logs?
To do this, click on the “Go to site folder” button in Local, and then zip up the logs folder. Here’s a screenshot to help visualize where to look:
Hi, here are the logs for the site. I first checked that the site still behaves like before, backend seems to work fine, but front end has teh same behaviour I have described before. logs.zip (7.2 KB)
Hi @ramela - yes, we took a look! Our theory is this is caused by an issue in the nginx config. From a user who resolved the issue on their machine…
The issue is that the Local NGINX site config is not listening on IPv6, only IPv4. MacOS supports IPv6 and so the isomorphic fetch tries over that protocol by default instead of IPv4; and the Local NGINX site config does NOT enable IPv6. It worked through the WP back-end because it was just using IPv4 there. The solution was to enable IPv6 in the NGINX config for Local.
The fix was to edit the site.conf.hbs file in the site’s conf/nginx folder and add this on line 9, right below the line for IPv4:
Thank you for the suggestion, sadly it did not resolve the issue, the same behaviour continues. The only change is that now trying to open the node frontend gives a 502 error instead of the 404 error it gave before. I’ll attach both Locals logs and the site’s logs, in case there is something new in there.
