NEW IncrediblePBX 2026-Debian13 + VM platforms

[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.

 

[Samot]

you mentioned that such "changes require both Asterisk and FreePBX to do reviews."

For OpenSSL 3.5, both Asterisk and FreePBX need to review it. In Asterisk it changes internal APIs and how TLS is handled. Outside of that and systemd (which will have little impact I'm sure) the rest of the stuff I listed doesn't impact Asterisk.

 

[wardmundy]

Dare To Compare: The php8.2-fpm patch now has been pushed out for Incredible PBX 2026 platforms. Here's a live (unenhanced) demo (about 30 seconds) of the performance improvement compared to FreePBX old clunkers:

 

[wardmundy]

Looks like @kenn10 discovered a new bug. If you try to use Backup/Restore module to move from an older release to Incredible PBX 2026 with FreePBX 17, the module does not create the (now necessary) transient_cdr table in the asteriskcdrdb MySQL database. This will mean you get no new CDR and CEL records for calls even though previous calls from an earlier restored release will display correctly.

To fix it, log into MySQL: mysql -u root -ppassw0rd asteriskcdrdb

Create the missing table:

CREATE TABLE IF NOT EXISTS `transient_cdr` (
  `accountcode` varchar(20) NOT NULL DEFAULT '',
  `src` varchar(80) NOT NULL DEFAULT '',
  `dst` varchar(80) NOT NULL DEFAULT '',
  `dcontext` varchar(80) NOT NULL DEFAULT '',
  `clid` varchar(80) NOT NULL DEFAULT '',
  `channel` varchar(80) NOT NULL DEFAULT '',
  `dstchannel` varchar(80) NOT NULL DEFAULT '',
  `lastapp` varchar(80) NOT NULL DEFAULT '',
  `lastdata` varchar(80) NOT NULL DEFAULT '',
  `calldate` datetime NOT NULL DEFAULT '1000-01-01 00:00:00',
  `duration` int(11) NOT NULL DEFAULT 0,
  `billsec` int(11) NOT NULL DEFAULT 0,
  `disposition` varchar(45) NOT NULL DEFAULT '',
  `amaflags` int(11) NOT NULL DEFAULT 0,
  `uniqueid` varchar(150) NOT NULL DEFAULT '',
  `userfield` varchar(255) NOT NULL DEFAULT '',
  `did` varchar(50) NOT NULL DEFAULT '',
  `recordingfile` varchar(255) NOT NULL DEFAULT '',
  `cnum` varchar(45) NOT NULL DEFAULT '',
  `cnam` varchar(45) NOT NULL DEFAULT '',
  `outbound_cnum` varchar(45) NOT NULL DEFAULT '',
  `outbound_cnam` varchar(45) NOT NULL DEFAULT '',
  `dst_cnam` varchar(45) NOT NULL DEFAULT '',
  `linkedid` varchar(150) NOT NULL DEFAULT '',
  `peeraccount` varchar(20) NOT NULL DEFAULT '',
  `sequence` int(11) NOT NULL DEFAULT 0,
  PRIMARY KEY (`uniqueid`,`sequence`),
  KEY `calldate` (`calldate`),
  KEY `dst` (`dst`),
  KEY `accountcode` (`accountcode`),
  KEY `linkedid` (`linkedid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Quit to exit from MySQL. And then

fwconsole reload
fwconsole restart

 

[Samot]

This will mean you get no new CDR and CEL records for calls even though previous calls from an earlier restored release will display correctly.

This is not what this means. The transient_cdr table is for CDRs and CDRs only, there's nothing like it for CEL. All calls are logged normally to the CDR/CEL tables and current data is pushed to transient_cdr which is used for some real-time reporting, dashboard stuff and queue call agents. It's so those real-time reports don't have to queries thousands upon thousands of records and allows them to work with just current history.

So not having the table means some real-time reporting might not work but you'll still have all your CDR and CEL records.

 

[kenn10]

So not having the table means some real-time reporting might not work but you'll still have all your CDR and CEL records.

On a new Incredible2026 system upon which you restore and older FreePBX backup, the table is not there. It is likely dropped by the FreePBX backup/restore module. In my case, I was running a IncrediblePBX-2025 system that had originally been restored from a FreePBX-16 system that was restored from a prior FreePBX-15 system. The table did not exist in FreePBX-15, 16, or 17 sysems and that lack was carried through to the FreePBX-17 systems upon restoring the backups. On the new IncrediblePBX-2026 system, after the FreePBX backup/restore from the IncrediblePBX-2025 system, no CDR's or CEL's were being saved in those tables. The errors indicated that the insert failed.

Here is the log entry showing that no write occurred to asteriskcdrdb:cdr:

 Spawn extension (macro-hangupcall, s, 6) exited non-zero on 'PJSIP/210-00000010'
[2026-06-07 14:05:23] WARNING[3194097]: res_odbc.c:534 ast_odbc_print_errors: SQL Execute returned an error: 42S02: [ma-3.1.15][11.8.6-MariaDB-0+deb13u1 from Debian]Table 'asteriskcdrdb.transient_cdr' doesn't exist
[2026-06-07 14:05:23] WARNING[3194097]: res_odbc.c:429 ast_odbc_prepare_and_execute: SQL Execute error -1!
[2026-06-07 14:05:23] WARNING[3194097]: cdr_adaptive_odbc.c:766 odbc_log: cdr_adaptive_odbc: Insert failed on 'asteriskcdrdb:cdr'.  CDR failed: INSERT INTO cdr (calldate, clid, src, dst, dcontext, channel, dstchannel, lastapp, lastdata, duration, billsec, disposition, amaflags, uniqueid, cnum, cnam, outbound_cnum, outbound_cnam, linkedid, sequence) VALUES ({ ts '2026-06-07 14:04:38' }, '"John Doe" <18285551212>', '18285551212', '17704557141', 'from-internal', 'PJSIP/210-00000010', 'PJSIP/BulkVS-00000011', 'Dial', 'PJSIP/17704557141@BulkVS,300,Tb(func-apply-sipheaders^s^1,(1))U(sub-send-obrout', 44, 36, 'ANSWERED', 3, '1780855478.16', '210', 'Office

Here was some background from Gemini AI:

The transient_cdr table was introduced in FreePBX 16 (specifically tracking back to late 2023 updates via ticket FREEPBX-24353), and it became heavily integrated as a core architectural feature in FreePBX 17.

Why it was added​

The table was implemented as a performance workaround to fix slow query times on large databases.

• The Problem: When endpoints, UCP, or mobile applications queried call history, FreePBX had to scan the massive, primary cdr table (which can easily grow to millions of rows). Because of prefixed wildcards in the search queries, the database couldn't effectively use indexes, leading to API timeouts and high CPU usage.
• The Fix: The transient_cdr table acts as a lightweight buffer that mirrors and holds only the last 60 days of CDR records. API calls and phone call-log queries hit this smaller table instead, preventing the system from getting bogged down.

Common Gotchas​

If you are restoring an older backup (such as migrating from FreePBX 15 directly to FreePBX 17) or using a remote CDR database, you might run into errors where Asterisk fails to write call logs because the table is missing (Table 'asteriskcdrdb.transient_cdr' doesn't exist).

You can usually force FreePBX to build the schema properly by running the following commands from your CLI:

Bash

fwconsole ma downloadinstall cdr<br>fwconsole reload<br>
If you are using a heavily customized or external database setup where you don't want it, you can disable the feature entirely by navigating in the GUI to Settings ➔ Advanced Settings, searching for Transient CDR, setting it to No, and applying the config

 

[Samot]

Spawn extension (macro-hangupcall, s, 6) exited non-zero on 'PJSIP/210-00000010' [2026-06-07 14:05:23] WARNING[3194097]: res_odbc.c:534 ast_odbc_print_errors: SQL Execute returned an error: 42S02: [ma-3.1.15][11.8.6-MariaDB-0+deb13u1 from Debian]Table 'asteriskcdrdb.transient_cdr' doesn't exist [2026-06-07 14:05:23] WARNING[3194097]: res_odbc.c:429 ast_odbc_prepare_and_execute: SQL Execute error -1! [2026-06-07 14:05:23] WARNING[3194097]: cdr_adaptive_odbc.c:766 odbc_log: cdr_adaptive_odbc: Insert failed on 'asteriskcdrdb:cdr'. CDR failed: INSERT INTO cdr (calldate, clid, src, dst, dcontext, channel, dstchannel, lastapp, lastdata, duration, billsec, disposition, amaflags, uniqueid, cnum, cnam, outbound_cnum, outbound_cnam, linkedid, sequence) VALUES ({ ts '2026-06-07 14:04:38' }, '"John Doe" <18285551212>', '18285551212', '17704557141', 'from-internal', 'PJSIP/210-00000010', 'PJSIP/BulkVS-00000011', 'Dial', 'PJSIP/17704557141@BulkVS,300,Tb(func-apply-sipheaders^s^1,(1))U(sub-send-obrout', 44, 36, 'ANSWERED', 3, '1780855478.16', '210', 'Office

Yes but it attempted to write to the cdr table. It shows that transient_cdr doesn't exist but it attempted to INSERT into the cdr table but you cut off the rest of the log that shows the rest of the INSERT logic and the error thrown. Need to see why the INSERT failed such as a field length was too long or an unexpected value. Be helpful to see the full error because adding the transient_cdr table most likely won't fix the INSERT on the CDR table.

 

[kenn10]

Yes but it attempted to write to the cdr table. It shows that transient_cdr doesn't exist but it attempted to INSERT into the cdr table but you cut off the rest of the log that shows the rest of the INSERT logic and the error thrown. Need to see why the INSERT failed such as a field length was too long or an unexpected value. Be helpful to see the full error because adding the transient_cdr table most likely won't fix the INSERT on the CDR table.

The whole error was 3 lines long. The above scrolls well to the right so you need to scroll over to see it all. See next post.