PHP errors

[stephenw10]

Do you see any errors in the Suricata log?

Have you restarted PHP at the console or rebooted since setting that php value? What does php -i | grep memory_limit show?

[bmeeks]

@jc1976 said in PHP errors:

I've been receiving this error. I increased the memory available under PHP Settings to 4096 MiB (default was 512) so should be more than enough.

PHP errors

PHP ERROR: Type: 1, File: /usr/local/pkg/suricata/suricata.inc, Line: 2451, Message: Allowed memory size of 536870912 bytes exhausted (tried to allocate 12288 bytes) @ 2024-03-18 17:40:58

Any ideas?

Suricata sets its own limit in the usr/local/pkg/suricata/suricata.inc file:

// Suricata GUI needs some extra PHP memory space to manipulate large rules arrays
ini_set("memory_limit", "512M");

It did this a long time before the option was added to the pfSense GUI. Probably time to remove that line of code from the package or else test it to see if the pfSense limit is greater than 512M.

For now all you can do is manually edit the file to a higher value if desired. Any change you make will get overwritten the next time the package is updated, though.

Normally users should never hit this PHP error. The most likely cause is trying to perform an operation on a file that is way too large. PHP is basically a stateless programming language. So, when you want to read the content of a large text file into a string variable the entire text file has to fit into the PHP allocated memory space so it can be manipulated. There is no built-in method to "remember" a file pointer position and read or output that text in blocks.

[jc1976]

@stephenw10
I have NOT rebooted and the command results in:

memory_limit => 1536M => 1536M

[jc1976]

@bmeeks
i set it to 1024M which i guess should be more than enough. if it happens again i'll increase it more.

Thanks!!

[SteveITS]

@jc1976 Also, double check your Suricata log rotation settings.

[stephenw10]

Bare in mind what Bill said above; Suricata has it's own hard coded memory limit that you still may hit there.

[bmeeks]

Yes, as @stephenw10 says, unless you change that line I referenced in the /usr/local/pkg/suricata/suricata.inc PHP 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).

[jc1976]

@bmeeks

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!

[stephenw10]

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.

[jc1976]

@stephenw10

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.

[BBcan177]

@jc1976

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.

[bmeeks]

@jc1976 said in PHP errors:

@stephenw10

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_set to 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_set commands 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_set command 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 old ini_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.

[smolka_J]

@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!

[jc1976]

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!

[bmeeks]

@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.inc file 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. The suricata.inc file 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.

[jc1976]

@bmeeks

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.

[bmeeks]

@jc1976 said in PHP errors:

@bmeeks

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.

[jc1976]

@bmeeks

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.

[jc1976]

@bmeeks

also, i'm still getting the php error.

[bmeeks]

@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.php directly. 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.