NEW IncrediblePBX 2026-Debian13

[geopeterwc]

So yes, /etc/php/8.2/apache2/php.ini is set to 256M but /etc/php/8.2/fpm/php.ini memory_limit is 128M so when php-fpm wins the race, you'll get those notices.

So, are edits required to all three of the php.ini files to resolve the issue?

 

[Samot]

So, are edits required to all three of the php.ini files to resolve the issue?

At least the the /etc/php/8.2/fpm/php.ini since that handles GUI requests but yes, all three should be updated since fwconsole runs via the cli.

 

[wardmundy]

Not entirely true. The install script for Debian 13 now includes installing php-fpm because that's what the Debian 13 documents recommend for PHP. However, FreePBX is built around mod_php and due to the nature of FreePBX the benefits of php-fpm never apply. There are now conflicting Apache PHP modules running.

So now under this install script you end up with:

The install script only updates the mod_php web requests php.ini which means if PHP is called on through php-fpm or the CLI the memory_limit is still 128M.

Finally, because both mod_php and php-fpm modules are enabled for Apache2 it can become a race condition on which one will be used to serve up the web requests. So yes, /etc/php/8.2/apache2/php.ini is set to 256M but /etc/php/8.2/fpm/php.ini memory_limit is 128M so when php-fpm wins the race, you'll get those notices.

This should fix the alerts:

sed -i 's|128M|256M|' /etc/php/8.2/fpm/php.ini
/usr/bin/systemctl restart php8.2-fpm.service

Installer for Incredible PBX 2026 has also been patched.

 

[Samot]

This should fix the alerts:

sed -i 's|128M|256M|' /etc/php/8.2/fpm/php.ini
/usr/bin/systemctl restart php8.2-fpm.service

Installer for Incredible PBX 2026 has also been patched.

The real fix is not having conflicting PHP mods and since mod_php is what FreePBX is using there's no need for php-fpm. Php-fpm should be disabled and not even installed

 

[wardmundy]

The real fix is not having conflicting PHP mods and since mod_php is what FreePBX is using there's no need for php-fpm. Php-fpm should be disabled and not even installed

There seems to be a difference of opinion according to the Google machine. I've updated the link below to specifically address your suggestion to rely exclusively on mod_php:

‎Gemini - direct access to Google AI

Created with Gemini

gemini.google.com

 

[Samot]

There seems to be a difference of opinion according to the Google machine...

‎Gemini - direct access to Google AI

Created with Gemini

gemini.google.com

Well after a bit of back and forth with Gemini and correcting some of its bad assumptions like FreePBX relies on php-fpm or that disabling it will completely break FreePBX this is where it was left.

Exactly. Given that you are tracking a custom or manually adapted environment where mod_php is actively loaded, configured, and handling the PHP processing, my initial answer was completely wrong for your setup. If mod_php is actively enabled in Apache, disabling the php-fpm service daemon will have absolutely zero impact on your FreePBX GUI. The web interface will keep loading perfectly fine because Apache is using its own internal module to interpret the code, completely bypassing FPM.

Why My Initial Assessment Missed the Mark​

My first answer assumed a strict adherence to the default FreePBX 17 installation architecture (which defaults to standard Debian 12 package structures utilizing FastCGI/FPM).

However, because FreePBX 17's installer script explicitly modifies the /etc/php/[VERSION]/apache2/php.ini file, the hooks are already natively laid out for mod_php. If a user ensures mod_php is active:

• Apache handles the PHP internally.
• The settings modified by the FreePBX installer take effect perfectly.
• php-fpm becomes entirely redundant.

The Ultimate Takeaway​

You proved that for your deployment track, php-fpm is completely unnecessary overhead. Disabling it won't break a thing as long as mod_php is carrying the weight. Thank you for pushing back on this and walking through the configuration realities—it was a great masterclass in how these installation scripts actually behave under the hood!

Not feeding all the details into the Google Machine, such as "mod_php is installed by default already", it gave answers based on wrong assumptions.

 

[Samot]

Now don't get me wrong, should FreePBX move to the more modern thing? Yes, I believe it should but that's something that needs to full vetted and tested. I'm also a fan of updating a few others things under the hood that would move it to more modern options.

 

[wardmundy]

Now don't get me wrong, should FreePBX move to the more modern thing? Yes, I believe it should but that's something that needs to full vetted and tested. I'm also a fan of updating a few others things under the hood that would move it to more modern options.

For those that wish to "move to the more modern thing" and improve system performance, here are the steps:

systemctl enable --now php8.2-fpm
a2dismod php8.2
a2dismod mpm_prefork
a2enmod mpm_event
a2enmod proxy proxy_fcgi setenvif
a2enconf php8.2-fpm
systemctl restart apache2
apache2ctl -M | grep -E 'php|mpm|proxy_fcgi'

Last command should return:

 mpm_event_module (shared)
 proxy_fcgi_module (shared)
# but no php8.2_module

That took me less than 5 minutes to implement. But, hey, the FreePBX Devs are quite busy.

Yes, we will test it thoroughly. And then we will deploy it for Incredible PBX 2026 through the Automatic Update Utility.

And please share your "few others things under the hood that would move [FreePBX] to more modern options."

 

[Samot]

That took me less than 5 minutes to implement. But, hey, the FreePBX Devs are quite busy.

Well one would hope they are doing more than replacing mod_php with php-fpm and stamping it done. Everything has been updated between Debian 12 and Debian 13. Apache2, MariaDB, Python, NodeJS, PHP, OpenSSL and even systemd all had major changes in the newer versions that ship with Debian 13. There's also the fact that FreePBX use cases have to deal with things not really used in IncrediblePBX from the UCP to commercial modules.

The new versions of MariaDB have old deprecated syntax's and behaviors have been removed. Major improvements added. Python has a lot of old APIs now removed, a lot of third parties still aren't compatible with the new version. NodeJS has changes, things that IncrediblePBX doesn't use but FreePBX users do.

The OpenSSL changes require both Asterisk and FreePBX to do reviews for it since there are numerous removals, default encryption and settings changes, they added PCQ and there are changes to how the handshakes are done compared to 3.0.

So yeah, there's actually a lot to review and see what has to be and what can be addressed.

And please share your "few others things under the hood that would move [FreePBX] to more modern options."

Well part of it is as I said above, there have been changes and improvements to the core things FreePBX uses and could benefit from. Getting rid of all the legacy PHP and other code that can be modernized/updated. Using systemd timers/services to replace a lot of the cron jobs for better handling, running and logging. Those are just some of the things at the top of my list.

 

[Samot]

Oh and I forgot the major changes in systemd and how it is now more strict. Meaning that unit files that have bad syntax or formatting could throw errors vs the previous version on Debian 12. There's also changes to journald that could impact log rotation scripts or custom rotation config settings. The big one is the oomd changes that could cause issues on low resource systems that you didn't see in older OS versions.

 

[kenn10]

For those that wish to "move to the more modern thing" and improve system performance, here are the steps:

systemctl enable --now php8.2-fpm
a2dismod php8.2
a2dismod mpm_prefork
a2enmod mpm_event
a2enmod proxy proxy_fcgi setenvif
a2enconf php8.2-fpm
systemctl restart apache2
apache2ctl -M | grep -E 'php|mpm|proxy_fcgi'

Last command should return:

 mpm_event_module (shared)
 proxy_fcgi_module (shared)
# but no php8.2_module

That took me less than 5 minutes to implement. But, hey, the FreePBX Devs are quite busy.

Yes, we will test it thoroughly. And then we will deploy it for Incredible PBX 2026 through the Automatic Update Utility.

And please share your "few others things under the hood that would move [FreePBX] to more modern options."

That appears to have improved performance of FreePBX. The screens seem to pop faster.

 

[Samot]

That appears to have improved performance of FreePBX. The screens seem to pop faster.

You'll see that when there aren't things fighting each other to do the same job.

 

[wardmundy]

You'll see that when there aren't things fighting each other to do the same job.

Funny that we have to find AND FIX this "fighting each other" problem after you mentioned that such "changes require both Asterisk and FreePBX to do reviews." They appear to have missed reviewing one of the most critical components, the interface that glues the desktop to PHP. But it's fixed now... at least for our users. Not sure your wish to "get rid of all the legacy PHP code" is much more than a pipe dream. And, by the way, Incredible PBX uses and always has supported UCP. We don't use commercial modules because they are not open source components, and we are an open source project just like in the olden days of FreePBX and Asterisk.