504 Gateway Timeout

Support
, ,
1

Issue Summary

Keep getting 504 Gateway Timeout errors

Troubleshooting Questions

  • Does this happen for all sites in Local, or just one in particular? all

  • Are you able to create a new, plain WordPress site in Local and access it in a Browser? yes

Replication

Trying to import XML file.

System Details

  • Which version of Local is being used?

  • What Operating System (OS) and OS version is being used? Windows 10 Pro 65 bit

  • Attach the Local Log. See this Community Forum post for instructions on how to do so:

2020/09/12 15:45:16 [alert] 16172#14840: OpenEvent("ngx_master_3700") failed (2: The system cannot find the file specified)
1 Like
2

Not sure if related, but on the most recent version I’m getting a 504 error everywhere whenever I update or install plugins. Restarting the site usually fixes it, but didn’t this last time, which is why I was looking for similar issues people might be experiencing.

1 Like
3

Hey @PeterFolk and @redblue – Couple of follow up questions:

  • What version of Local are you using?
  • Can you please provide your Local Log? See this Community Forum post for instructions on how to do so:
  • Can you provide the “Router Log”? Nagivate to “Help > Reveal Local Router’s Log”

From this error:

That seems like a line in the “Router Log” which is an NGINX proxy to help point the browser to the actual WordPress site that Local’s managing. It seems like it might be having some sort of permissions issues.

@redblue – you don’t mention it explicitly, but I want to double-check: are you running Windows 10 as well?

4

I’m on Mac, actually. In the middle of something, but as soon as I’m done I’ll try to replicate the error and get you the log. Should be about 30 minutes.

5

My log is attached, my error is actually a 502 error; my apologies if I’ve conflated two separate issues here (and I might have). I’m on the most recent version for Mac (5.7.5+4909)

I replicated this error by simply moving an active plugin out of the plugins directory. Moving it back in did not fix the issue; restarting the site usually fixes it. This seems like a new issue with this version of Flywheel.

error.log (2.5 MB)

6

Interesting… I’m seeing a few lines like this:

2020/10/06 13:27:04 [warn] 71812#0: *1321 upstream server temporarily disabled while reading response header from upstream, client: ::1, server: ebt.local, request: "GET /browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_AhGh&sid=KCMIFeKwVZVm7tnnAAAD HTTP/1.1", upstream: "http://[::1]:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_AhGh&sid=KCMIFeKwVZVm7tnnAAAD", host: "ebt.local", referrer: "http://ebt.local/wp-admin/"
2020/10/06 13:27:04 [error] 71812#0: *1321 kevent() reported that connect() failed (61: Connection refused) while connecting to upstream, client: ::1, server: ebt.local, request: "GET /browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_AhGh&sid=KCMIFeKwVZVm7tnnAAAD HTTP/1.1", upstream: "http://[fe80::1]:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_AhGh&sid=KCMIFeKwVZVm7tnnAAAD", host: "ebt.local", referrer: "http://ebt.local/wp-admin/"
2020/10/06 13:27:04 [warn] 71812#0: *1321 upstream server temporarily disabled while connecting to upstream, client: ::1, server: ebt.local, request: "GET /browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_AhGh&sid=KCMIFeKwVZVm7tnnAAAD HTTP/1.1", upstream: "http://[fe80::1]:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_AhGh&sid=KCMIFeKwVZVm7tnnAAAD", host: "ebt.local", referrer: "http://ebt.local/wp-admin/"
2020/10/06 13:27:04 [error] 71812#0: *1321 kevent() reported that connect() failed (61: Connection refused) while connecting to upstream, client: ::1, server: ebt.local, request: "GET /browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_AhGh&sid=KCMIFeKwVZVm7tnnAAAD HTTP/1.1", upstream: "http://127.0.0.1:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_AhGh&sid=KCMIFeKwVZVm7tnnAAAD", host: "ebt.local", referrer: "http://ebt.local/wp-admin/"
2020/10/06 13:27:04 [warn] 71812#0: *1321 upstream server temporarily disabled while connecting to upstream, client: ::1, server: ebt.local, request: "GET /browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_AhGh&sid=KCMIFeKwVZVm7tnnAAAD HTTP/1.1", upstream: "http://127.0.0.1:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_AhGh&sid=KCMIFeKwVZVm7tnnAAAD", host: "ebt.local", referrer: "http://ebt.local/wp-admin/"
2020/10/06 13:27:04 [error] 71812#0: *1321 no live upstreams while connecting to upstream, client: ::1, server: ebt.local, request: "POST /browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_Ahgb&sid=KCMIFeKwVZVm7tnnAAAD HTTP/1.1", upstream: "http://localhost/browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_Ahgb&sid=KCMIFeKwVZVm7tnnAAAD", host: "ebt.local", referrer: "http://ebt.local/wp-admin/"
2020/10/06 13:27:05 [error] 71812#0: *1321 no live upstreams while connecting to upstream, client: ::1, server: ebt.local, request: "GET /browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_Ahss HTTP/1.1", upstream: "http://localhost/browser-sync/socket.io/?EIO=3&transport=polling&t=NJ_Ahss", host: "ebt.local", referrer: "http://ebt.local/wp-admin/"

Are you using BrowserSync while updating this plugin? Do you have Local’s Instant Reload enabled while doing this?

I’m wondering if there’s some sort of lingering process that’s holding onto those files so that WordPress can’t cleanly delete/update the file?

7

Yes; I’m using the new built-in livereload feature that’s part of Local. I also did notice earlier today that doing the same actions did NOT cause an error when working on another site without that option enabled.

Perhaps it’s just changing too many files at a time?

1 Like
8

One other note: after restarting the site, it actually usually works fine without moving any files around further or anything (and generally the update actually does go through fine). It’s just a momentary error; albeit an annoying one (since updating a plugin is a pretty common thing to do). I usually update via CLI, and that was definitely triggering the error.

9

New symptom I’ve noticed (also only when Instant Reload is on): admin-ajax is failing when submitting a gravity form.

10

Please mark my issue closed as somehow someone else’s problems got into my thread. I will start a new one if the problem continues.

11

My apologies, @PeterFolk. I’d thought we were having the same issue. Turns out to be different.

12

Just wanted to note that the new version of Local does not address this particular issue. When I update a plugin via CLI, I’m still getting a 502 error.

13

Just checking in on this ticket. If you’d prefer that I open this as a clean ticket, I’d be happy to as well. The error (for me) appears to be an issue with Live Reload (the built-in version), which makes a site error out as a 502 whenever I update or add a plugin.

14

Hey @PeterFolk, We’re not trying to hijack this thread, we just don’t really know if these are separate issues.

A 504 error is quite general, so if you can answer a few of the questions from my earlier reply, we can start to zero in on the nature of the issue you are experiencing and if it is similar to the one that redblue is having.

To be specific @PeterFolk, can you answer these questions?

15

Thanks for helping clarify what you’re seeing!

That seems like a plausible explanation for the plugin update/installation workflow. I’ll look into trying to replicate on my end.

For the Gravity Form part of things, is it saving something to disk? What kind of info is being POST’ed? Maybe there’s more info about that specific request within the Router Log?

16

On the Gforms issue: I just tried to replicate the issue with Gravity forms and was unable to, so I can’t be more specific there. However, I believe it was just a contact form (name, email, phone, message, no uploaded files or anything like that). When I previously saw it fail, it was on an AJAX request.

On the more significant issue (the 502 error happening whan a plugin is installed/updated), that one has been replicable so far; if a video would be helpful showing what’s happening there I’d be happy to make one.

17

Having a screencast would be awesome! I’ll create a bug so it’s in the backlog for our devs to take a look at!

18

Sure! Here you go! I should note that plugin updates/additions/deletions all cause the same issue, and all only while Instant Reload is on:

Late in the video, I’m moving my mouse and talking about the instant reload bug and how it would be cool if it could be toggled from the overview tab. Loom appears to have lost track of my mouse there. I’m actually hovering over the words “instant reload” next to the “stop site” at the top right of Local.

2 Likes
19

Another piece of information that might help. I do a lot of pulling from live sites via Migrate DB Pro, which I often set to pull in media files as well. Even when pulling a bunch of media files, so far I’ve not seen that particular thing take down a site in this way. Not sure if you’re monitoring the uploads directory with instant reload, but perhaps that helps narrow things slightly.

20

This is so helpful, thanks for this screencast as well as the excitement over Instant Reload!

Yeah, we don’t monitor the uploads folder, we found that there was just too much of a performance impact when watching that many files.

I think that Instant Reload is only watching the files within the plugins and themes folders, which is why this has been localized to just when the plugins are being updated.

I’m adding this to our internal bug tracker so that the team can take a closer look!

1 Like