PHP errors
-
@stephenw10
I have NOT rebooted and the command results in:memory_limit => 1536M => 1536M
-
@bmeeks
i set it to 1024M which i guess should be more than enough. if it happens again i'll increase it more.Thanks!!
-
@jc1976 Also, double check your Suricata log rotation settings.
-
Bare in mind what Bill said above; Suricata has it's own hard coded memory limit that you still may hit there.
-
Yes, as @stephenw10 says, unless you change that line I referenced in the
/usr/local/pkg/suricata/suricata.incPHP include file, then the limit specified on that line will override what you may configure in pfSense.In the next package update I will change this logic in Suricata to check for any user-configured limit on the pfSense side and honor that limit instead. This internal limit was put there a long time ago when I think pfSense itself was still defaulting to either 128M or 256M (can't remember exactly which).
-
Thank you! awesome!
I gave it a bunch more ram.. i figured i have plenty to spare, so.. I made the change and restarted the service. that should be enough, right? I shouldn't have to restart the whole firewall to see the changes, correct?
This may sound outta left-field because it's pfblockerng related, but do you think this php memory setting could effect an issue i've been having with pfblockerng-dev?
seems over the past month or 2 i can't update my whitelist without first doing a reboot of the firewall. for example; if i wanted to either add or remove (comment out) a domain, i'd add it to the dnsbl whitelist window of pfblockerng, click "save" at the bottom, but nothing would happen. If i left the page and came back to it, the change wouldn't have been saved. Restarting the firewall completely and then going back to the whitelisting window and making my changes would update properly.
Just thought of that... I guess i could try it first and see if it works than report back instead of wasting your time with a dumb question.... LOL!
Thanks everyone!
-
You shouldn't need to reboot, just restarting Suricata should be fine.
Yes pfBlocker-ng can require a lot of php memory. If you were hitting an error there increasing the php memory could well workaround it.
-
Regarding pfblocker, unfortunately no dice... just tried and it didn't matter.
seems like the suricata php errors have been resolved but pfblocker still won't take changes to the whitelisting. -
When you hit save, it just does that save only. You need to Force Reload for the new settings to take effect. Otherwise, it's recommended to whitelist from the Alerts Tab which will take effect immediately and also include any cnames associated to a domain.
-
@jc1976 said in PHP errors:
Regarding pfblocker, unfortunately no dice... just tried and it didn't matter.
seems like the suricata php errors have been resolved but pfblocker still won't take changes to the whitelisting.You might want to search through the pfBlockerNG PHP code to see if it contains a line of code similar to what I posted earlier from Suricata's code like this one:
ini_set("memory_limit", "512M");Search for
ini_setto find any such instance.If the pfBlockerNG code contains its own line that sets the PHP memory limit, then that value will overwrite anything else. That's because each PHP process is its own independent island in terms of execution and settings. There are some global defaults, but any individual PHP session can override the global defaults and set a value that will be valid for only the time that session's code is executing.
Generally speaking, each page or tab you manipulate in the pfSense GUI represents a single session of running PHP code, and when the HTML output from that page is rendered and sent to your browser, that PHP session ends execution.
The global PHP memory limit parameter on the Advanced Settings tab under the SYSTEM menu is relatively new in pfSense. Prior to that pfSense simply set a default value hard-coded in a file. Because some packages performed operations that needed additional PHP memory, those package developers added
ini_setcommands to override the pfSense default and increase memory. But now that the user can set almost any limit they desire in the new PHP memory limit parameter (consistent with the amount of RAM in the firewall), the hard-coded increases in the packages are no longer necessary because they can override what the user has configured and result in less than the user-specified RAM being allocated.The PHP interpreter will only allocate the amount of PHP memory commanded by the most recently executed
ini_setcommand in a session. So, even though you might have configured a 2 GB global PHP memory limit in the pfSense menu, if the package code still contains an oldini_set("memory_limit", "512M")line, then PHP will only allocate 512 megabytes of string memory for the current session and ignore the user-specified 2 GB value. -
@bmeeks Many many thanks for this addition just added on 7.04. It was getting annoying every Suricata and/or pfSense upgrade having Suricata crash at each re-install and disappear from my Services menu until editing the memory_limit each time and then having to restore to a prior config after to get Suricata to pop up again in my services menu. Only other way around that in the past I found was to disable all interfaces and remove all extra rules before each update and have to re-add everything after. Should allow for much smoother updates finally, thank you again!
-
it seems that didn't work, and also i just noticed that suricata is no longer showing up under services status or services, i still keep receiving the php error message despite increasing the available memory.
i uninstalled and reinstalled suricata, cleared out my browsers web cache.. no dice..
any advice?
thanks!
-
@jc1976 said in PHP errors:
it seems that didn't work, and also i just noticed that suricata is no longer showing up under services status or services, i still keep receiving the php error message despite increasing the available memory.
i uninstalled and reinstalled suricata, cleared out my browsers web cache.. no dice..
any advice?
thanks!
Did you remove and then reinstall Suricata, or did you just click the reinstall button in the Package Manager tab? You need to remove completely and then reinstall Suricata. Otherwise the old
suricata.incfile will stick around with the incorrect settings in it because the PHP session will cache it. The package manager tab code will all execute in a single PHP session and thus can cache some PHP source files. Thesuricata.incfile is a common file containing lots of shared functions, thus it is frequently cached. Completely removing the package, the going back into Package Manager and locating and installing Suricata again dumps the cached file and then the new get used from the new package install.I also assume that you left the increased PHP memory limit setting configured in pfSense. If not, you must do that. All the change does is honor any pfSense setting. If you rolled back that setting (or never changed it), then Suricata will continue to use the default memory which is 512 MB.
-
I completely removed suricata. I initially did a reinstall but it didn't work so i uninstalled completely, rebooted the firewall, and reinstalled.
My problem at the moment is that it's showing up installed but not showing up under services so i can't get into its interface to see anything.
-
@jc1976 said in PHP errors:
I completely removed suricata. I initially did a reinstall but it didn't work so i uninstalled completely, rebooted the firewall, and reinstalled.
My problem at the moment is that it's showing up installed but not showing up under services so i can't get into its interface to see anything.
The install did not complete due to the PHP errors. Thus it will not show up under the SERVICES menu. You must remove it under Package Manager and reinstall. But before you do that, be sure you have set the PHP Memory Limit value to something large enough under SYSTEM > ADVANCED > MISC SETTINGS. Read my later edits to my post above.
-
that's what i did.
i uninstalled suricata (from within package manager).
verified my php ram settings (2048)
rebooted the firewall.
installed suricata from package manager.suricata shows up as an installed package.
it does NOT show up under the services menu or under services status.
-
also, i'm still getting the php error.
-
@jc1976 said in PHP errors:
it does NOT show up under the services menu or under services status.
That's because, as I said earlier, the full install procedure is not running to completion. During installation the installer calls a hook script that allows the package to download and install the rules previously configured. When that hook script completes, it returns control to the installer which then, as a last step, creates the menu entry under SERVICES. Because the hook call is crashing, it does not return control to the installer so that it can create the menu entry.
You can probably still call up the Suricata GUI by navigating to
<firewall_ip>/suricata/suricata_interfaces.phpdirectly. From there you can examine your rules. You must have a ton of rules enabled to crash the PHP service. Try removing some of them and see if things behave better. Likely nowhere near all of them are required.Due to the absence of similar posts, I have to assume you are the only user experiencing the problem, so it must be something specific to your setup.
-
What are you testing in? We are currently looking at an issue with the POST-INSTALL script not running in 24.03. But that's at upgrade.
-
@jc1976 If your PHP error now states "Allowed memory size of 2147483648" when PHP limit is set at 2048m at System>Advanced>Misc then that PHP limit number is going to need to be increased a bit higher to accommodate the number of rules enabled, only time it is using this much memory typically is only at install for a few seconds until all configurations and rules are processed. I set mine to about 3/4ths my total RAM at 24576m. If you're on an ARM model or other limited to only 2-4gb total ram available you may need to make sure enough swap space is present and enabled to be able to raise that PHP memory limit higher to allow it to fully load without ahead of time having to have the option unchecked to save settings on re-install, update then configure from scratch, or like another said disabling enough excess rules will bring the needed number down into playing field as well.
