502 Bad Gateway (nginx) after Update to 2.3
-
The patch in message #60 worked for me. After upgrading to 2.4.2 I tried installing PFBlockerNG and started getting non-responsive web interface, ssh sessions and even serial console. I am pretty new to BSD and couldn't get the patch to take, but I got the changes in manually and my router is stable again. Created an account to say, "Thank you!"
-
Odd, I created the patch for Chris's mods and PR'd it for him. Are you saying that Patch ID: 028be76 will not apply for you?
I have just removed it and re-fetched it and re-applied it to my system without any problems.
-
It's probably something i did wrong. Like I said I'm not familiar with BSD, and only used patch a couple of times.
Saved the patch listed in this thread as rc.php_ini_setup.patch
Here's a recreation of what I did.
/etc: patch rc.php_ini_setup rc.php_ini_setup.patch
Hmm… Looks like a unified diff to me...
The text leading up to this was:-- /etc/rc.php_ini_setup 2017-07-06 19:35:29.000000000 +0100
+++ /etc/rc.php_ini_setup 2017-11-22 21:05:24.986893000 +0000 Patching file rc.php_ini_setup using Plan A... Hunk #1 failed at 265. Hunk #2 succeeded at 317 with fuzz 1. Hunk #3 succeeded at 327 with fuzz 1. Hunk #4 succeeded at 341. 1 out of 4 hunks failed--saving rejects to rc.php_ini_setup.rej done -rw-r--r-- 1 root wheel 1366 Nov 28 05:58 rc.php_ini_setup.patch
-rwxr-xr-x 1 root wheel 9395 Nov 28 05:58 rc.php_ini_setup.orig
-rwxr-xr-x 1 root wheel 9459 Nov 28 05:59 rc.php_ini_setup
-rw------- 1 root wheel 456 Nov 28 05:59 rc.php_ini_setup.rej/etc: cat rc.php_ini_setup.rej
@@ -265,10 +265,22 @@PHPFPMMAX=3
+PHPFPMIDLE=30
+PHPFPMSTART=1
+PHPFPMSPARE=2
+PHPFPMREQ=500
if [ $REALMEM -lt 250 ]; then
PHPFPMMAX=2
+ PHPFPMIDLE=5
+ PHPFPMSTART=1
+ PHPFPMSPARE=1
+ PHPFPMREQ=500
elif [ ${REALMEM} -gt 1000 ]; then
- PHPFPMMAX=4
+ PHPFPMMAX=8
+ PHPFPMIDLE=3600
+ PHPFPMSTART=2
+ PHPFPMSPARE=7
+ PHPFPMREQ=5000
fi/bin/cat > /usr/local/lib/php-fpm.conf < <eof<br>/etc: diff rc.php_ini_setup.orig rc.php_ini_setup
308c308
< pm.process_idle_timeout = 5
–-pm.process_idle_timeout = $PHPFPMIDLE
310c310
< pm.max_requests = 500
pm.max_requests = $PHPFPMREQ
318c318
< pm.process_idle_timeout = 5
pm.process_idle_timeout = $PHPFPMIDLE
320,321c320,321
< pm.start_servers = 1
< pm.max_requests = 500
pm.start_servers = $PHPFPMSTART
pm.max_requests = $PHPFPMREQ
323c323
< pm.max_spare_servers=1
pm.max_spare_servers= $PHPFPMSPARE
332c332
< pm.max_requests = 500
pm.max_requests = $PHPFPMREQ</eof<br>
After that I just restored the saved copy and just manually make the changes. Still working great. I'm using a PC engines apu2c2 and memory usage is about 12 percent Thanks again.
-
It's probably something i did wrong. Like I said I'm not familiar with BSD, and only used patch a couple of times.
Saved the patch listed in this thread as rc.php_ini_setup.patch
Use the System_Patches package, makes it a lot easier.
-
Ah, not familiar with the pfSense patch system. :)
OK, first thing to do is reverse what you have done, put everything back as it was.
Next, go into pfSense and select Package Manager from the System Menu, select 'Available Packages' and find the 'System Patches' package and install it.
You will now have a 'Patches' option in the system menu - Select it.
Click on add new patch.
In the URL/Commit ID enter the patch ID 028be76, give a description in the Description box and press save.
Now click on Test, it should say can be applied cleanly. Now click on Apply.
Job done.
-
Thank you again. I replaced the original file and re-applied the patch the proper way for pfSense. Other than some extra spaces I had it correct.
The router continues to be stable with this patch. -
That's good.
The advantage of using the patch system, apart from saving you a lot of work, is that you have a setting in the patch that allows for it to be automatically re-applied when you update pfSense. It checks to see whether it can be re-applied cleanly and does so. Obviously, if the file(s) the patches are applied against change in a way that means the patch will not cleanly apply then it does not do so, so when you use patches it's advisable to check after an update. For the average user who is not on the beta trail this means only a two or three times a year, beta testers should check every time they update.
-
tward800 thanks for your feedback, even if there is no problems, feedback is good, as it helps developers make a decision on if a patch is safe enough to rollout or not.
-
The patch gives me some errors when I test it:
/usr/bin/patch –directory=/ -t -p2 -i /var/patches/5a269040d9477.patch --check --forward --ignore-whitespace
Hmm... Looks like a unified diff to me...
The text leading up to this was:|From 2c131b10b25db593331048d4f2b28fbf9bf5662e Mon Sep 17 00:00:00 2001
|From: marjohn56
|Date: Wed, 29 Nov 2017 23:18:51 +0000
|Subject: [PATCH] Increase FPM process availability in high ram systems
|
|To reduce chance of nginx gateway error when interacting with FPM backend, this patch does the following, starts up extra FOM server processes at startup, allows more to stay running on standby, increases automatic shutdown time from 5 seconds to one hour. On systems with a gig or more of ram
|–-
| src/etc/rc.php_ini_setup | 29 +++++++++++++++++++++--------
| 1 file changed, 21 insertions(+), 8 deletions(-)
|
|diff --git a/src/etc/rc.php_ini_setup b/src/etc/rc.php_ini_setup
|index 5ce0ef7a31..03bc1178d9 100755
|--- a/src/etc/rc.php_ini_setup+++ b/src/etc/rc.php_ini_setup Patching file etc/rc.php_ini_setup using Plan A... Hunk #1 succeeded at 265. Hunk #2 failed at 317. Hunk #3 failed at 340. 2 out of 3 hunks failed while patching etc/rc.php_ini_setup done I'm using a new Pfsense 2.4.2 install and using the patch manager from the gui.
-
Try patch 2c131b1.
Yes, I had to re-sync with upstream. In doing so my Github desktop threw one and I had to pull it back and re-do the PR. However, it's against 2.4.3, so it may not work for 2.4.2 now.
-
@marjohn56:
Try patch 2c131b1.
Yes, I had to re-sync with upstream. In doing so my Github desktop threw one and I had to pull it back and re-do the PR. However, it's against 2.4.3, so it may not work for 2.4.2 now.
Exactly the same error, so indeed not for 2.4.2. I'll do the changes manually :)
-
@marjohn56:
Try patch 2c131b1.
Yes, I had to re-sync with upstream. In doing so my Github desktop threw one and I had to pull it back and re-do the PR. However, it's against 2.4.3, so it may not work for 2.4.2 now.
I am getting patch fetch failed when I try this
-
Works fine for me, just re-entered that I'd and fetched it again, no problem.
-
@marjohn56:
Works fine for me, just re-entered that I'd and fetched it again, no problem.
Does this look right?
-
Strange I get a different ID.
Try the full ID 2c131b10b25db593331048d4f2b28fbf9bf5662e
-
That fails as well
here is what is in the logDec 5 16:46:00 php-fpm 70317 /system_patches.php: Download file failed with status code 0\. URL: https://github.com/pfsense/pfsense/commit/2c131b10b25db593331048d4f2b28fbf9bf5662e.patch -
This is silly. ???
Here's the full URL that I have just used.
https://github.com/pfsense/pfsense/commit/2c131b1.patch
-
will not fetch that one either. This is weird
-
BeerCan, can you get into https://github.com
If your browser gives you an error, you will have problems downloading. It is something to do with HSTS.
-
BeerCan, can you get into https://github.com
If your browser gives you an error, you will have problems downloading. It is something to do with HSTS.
I can't get in with FF or chrome
