504 Gateway Time-out (nginx) - 2.3 upgrade on 2x APU1
-
@cmb:
This was likely fixed in either 2.3.1 or 2.3.1_1 depending on which instance of the issue is responsible.
Yes, I can confirm that this issue is resolved (at least I haven't noticed the problem arising lately). Latest updates have been doing wonders :)
-
Hello
This issue is NOT resolved in version 2.3.1_1 . I contantly gett 502 BAD gateway after some time of usage.
I have removed IPSEC gadgets etc and the problem still persists.
I have to reboot the pfsense everyday because of this.Best regards
Toby -
There's no need to reboot, simply restart PHP-FPM and the webconfigurator from the shell menu. Plus you are two releases behind.
-
Hello
Running 2.3.2 P1 , sorry i did not check. But anyway the error is still there. I have it on several units
/Toby
-
Hello
Running 2.3.2 P1 , sorry i did not check. But anyway the error is still there. I have it on several units
/Toby
If you can please run this command, and try to capture the output; when the issue happens ps uxawww either by ssh, or the local terminal. Install pstree for an even better way to find the issue. One of the devs instructed me to do this in order to see what was the cause.
pkg install pstree
rehash
pstree -
I have the same issue here with version:
2.3.2-RELEASE-p1 (amd64)
built on Tue Sep 27 12:13:07 CDT 2016
FreeBSD 10.3-RELEASE-p9After some hours I get the "504 Gateway Time-out" or Bad Gateway error.
-
You are on a totally different version. Nano i386 vs amd64.
Did you restart PHP-FPM from console/ssh? What was the result? -
About ~100% of cases this is fixed by Restart PHP-FPM + Restart webConfigurator from console. (Not that it'd make me love the nginx thing, or the pkg's stupidity of being absolutely unable to work offline.)
And disable the updates checking on dashboard, plus definitely do NOT add the installed packages widget.
-
I know the version thing, I only want to say, that the issue is still alive :D
-Restart PHP-FPM is working every time, but its not really usable to do this so often
But I try to disable the updates checking thing. Installed packages widget is not installed.
Thanks :)
-
@crisdavid:
If you can please run this command, and try to capture the output; when the issue happens ps uxawww either by ssh, or the local terminal. Install pstree for an even better way to find the issue. One of the devs instructed me to do this in order to see what was the cause.
pkg install pstree
rehash
pstreeDon't bother installing that. ps forest/tree format under bsd:
ps auxdww
Gives more info on all processes.
("w" 's are for long line wrapping - 'd' is for forest view (tree) )https://www.freebsd.org/cgi/man.cgi?ps(1)
-
I tried that thing with uncheck updates - didn't work. After some days the http request timed out because ngin didn't respond
-
There was a problem with the IPsec widget a while back. If you have that on the dashboard then try to remove it.
-
bump
Setup :
- 2.3.2-RELEASE-p1 (i386)
- 2013 ALIX Engine
- 4G NanoBSD
- bare install, no-addons
I have been trying to taccle down similar issues as those mentionned in this topic :
-
nginx timeouts ( 504, 502 … ) or slowness
-
nginx timeouts in syslog
-
traffic still going trough, only the UI is impacted
My appliance is coupled w/ a 100Mbps DSL line ( which is well below the maximum troughput it can handle ), and I started noticying that the nginx issues were happening at high troughput ( >= 90Mbps ).
I disabled traffic shaping at first ( as it can be quite CPU intensive ), but it didn't change the behaviour.
The moment the troughput drops to values like 20Mbps, the UI becomes responsive again ( no slowness, no timeouts ).
What can I do to solve these problems ? :-\
-
bump
..Alix..
What can I do to solve these problems ?Bump in place ?
First off: Install a fast/excellent CF like a Transcend Industrial grade.
Then start with a 2.3 from scratch i.s.o. upgrading from a 2.2
Set the CF to read/write all the time.
2.3 works fine with an Alix. -
@hda:
First off: Install a fast/excellent CF like a Transcend Industrial grade.
Then start with a 2.3 from scratch i.s.o. upgrading from a 2.2
Set the CF to read/write all the time.
2.3 works fine with an Alix.- SLC SD card w/ high i/o installed
- last "from scratch" install was done on the initial 2.3 release ( and it's irrelevant since the NanoBSD upgrade procedure is equivalent to an initial install w/ config copy only )
- RW mode enabled ( it's now a NanoBSD default setting )
-
I started noticying that the nginx issues were happening at high troughput ( >= 90Mbps ).
I disabled traffic shaping at first ( as it can be quite CPU intensive ), but it didn't change the behaviour.
The moment the troughput drops to values like 20Mbps, the UI becomes responsive again ( no slowness, no timeouts ).What can I do to solve these problems ? :-\
Get an adequate hardware to handle the load. These things are simply EOL. Having issues even when updating due to lack of RAM, especially if you hit some bigger package update (python, perl comes to mind.)
-
The moment the troughput drops to values like 20Mbps, the UI becomes responsive again ( no slowness, no timeouts ).
What can I do to solve these problems ? :-\So if the load is too high, which it is, and you want to keep the Alix, you could then restrict your 100-line to 50 or 25 with a managed switch.
-
These things are simply EOL. Having issues even when updating due to lack of RAM, especially if you hit some bigger package update (python, perl comes to mind.)
EOL ?! :o
These ALIX appliances are still being sold and are rated for a 250Mbp/s Firewall throughput, which, if I'm right, should be more than enough for what I do with it ???
EDIT : looking carefully @ the specs, I noticed that, while the FW t.p. is rated at 250Mbp/s, the port-to-port t.p. is rated at 85Mbp/s, so that might be a clue indeed ( altough I don't fully understand what it means compared to the FW t.p. )
-
These things are simply EOL. Having issues even when updating due to lack of RAM, especially if you hit some bigger package update (python, perl comes to mind.)
EOL ?! :o
Yeah, these are certainly EOLed as far as pfSense is concerned (together with rest of x86 arch). x86 is gone with 2.4. I mean, recycle them to run LEDE/OpenWrt or something similar on it and they can keep running for lot more years, but pfSense/FreeBSD is getting a pain to run on these.
-
These things are simply EOL. Having issues even when updating due to lack of RAM, especially if you hit some bigger package update (python, perl comes to mind.)
EOL ?! :o
Yeah, these are certainly EOLed as far as pfSense is concerned (together with rest of x86 arch). x86 is gone with 2.4. I mean, recycle them to run LEDE/OpenWrt or something similar on it and they can keep running for lot more years, but pfSense/FreeBSD is getting a pain to run on these.
For details of will no longer be supported from 2.4 onwards: https://forum.pfsense.org/index.php?topic=121255.0
