Slow computer listing and high CPU with version 1.5.1.01798

[olivier.bonnici]

Same here, 1.5.10.1734 to 1.5.10.1798 on debian 13.3 freshly installed.
Hosts Web Page hangs several minute.

[Tom Elliott]

@olivier-bonnici How many hosts do you have?

@tatanas @Infojoe as well, apologies on delayed response.

[Infojoe]

@Tom-Elliott No problem.
On my side, I have about 630 hosts. Usually, hosts page loads in a second.

[olivier.bonnici]

This post is deleted!

[olivier.bonnici]

@Tom-Elliott
Hi Tom.
634 hosts
Take 3 secondes with 1.5.1734

[Tom Elliott]

Can you get some output from /var/log/php-fpm/www-error.log (if redhat based?) or /var/log/apache2/error.log (if debian)

Basically try to load the page, and tail the log and return that output here for htat rough timestamp.

Also see if there’s anything in the history table:

SELECT * from fog.history;

For around that time frame.

[tatanas]

Hi,
177 hosts and it takes almost one minute

[olivier.bonnici]

@Tom-Elliott I’m on another server, DEBIAN13.3, fog 1.5.1.01798 no slowing page here but number had been added on the hosts lists :

[olivier.bonnici]

@Tom-Elliott Error.log on the ‘non working’ UI

[Wed Mar 18 13:56:12.727237 2026] [proxy:error] [pid 907:tid 907] (111)Connection refused: AH00957: FCGI: attempt to connect to 127.0.0.1:9000 (127.0.0.1:9000) failed
[Wed Mar 18 13:56:12.727296 2026] [proxy_fcgi:error] [pid 907:tid 907] [client 10.72.228.101:56843] AH01079: failed to make connection to backend: 127.0.0.1
[Wed Mar 18 13:56:12.727758 2026] [mpm_prefork:notice] [pid 865:tid 865] AH00163: Apache/2.4.66 (Debian) OpenSSL/3.5.5 configured -- resuming normal operations
[Wed Mar 18 13:56:12.727797 2026] [core:notice] [pid 865:tid 865] AH00094: Command line: '/usr/sbin/apache2'
[Wed Mar 18 13:56:13.201595 2026] [proxy_fcgi:error] [pid 910:tid 910] [client 10.72.233.20:57281] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught Error: Call to a member function lastInsertId() on false in /var/www/fog/lib/db/pdodb.class.php:615\nStack trace:\n#0 /var/www/fog/lib/fog/fogcontroller.class.php(521): PDODB->insertId()\n#1 /var/www/fog/lib/fog/hookmanager.class.php(62): FOGController->save()\n#2 /var/www/fog/lib/fog/fogpage.class.php(223): HookManager->processEvent()\n#3 /var/www/fog/lib/pages/schemaupdaterpage.class.php(39): FOGPage->__construct()\n#4 /var/www/fog/lib/fog/fogpagemanager.class.php(381): SchemaUpdaterPage->__construct()\n#5 [internal function]: FOGPageManager->{closure:FOGPageManager::loadPageClasses():350}()\n#6 /var/www/fog/lib/fog/fogpagemanager.class.php(386): array_map()\n#7 /var/www/fog/lib/fog/fogpagemanager.class.php(79): FOGPageManager->loadPageClasses()\n#8 [internal function]: FOGPageManager->__construct()\n#9 /var/www/fog/lib/fog/fogbase.class.php(481): ReflectionClass->newInstanceArgs()\n#10 /var/www/fog/management/index.php(25): FOGBase::getClass()\n#11 {main}\n  thrown in ...'
[Wed Mar 18 14:07:08.496309 2026] [proxy_fcgi:error] [pid 910:tid 910] (70007)The timeout specified has expired: [client 10.72.233.20:57353] AH01075: Error dispatching request to : (polling), referer: http://10.72.233.19/fog/management/index.php?node=host
[Wed Mar 18 14:08:06.685207 2026] [proxy_fcgi:error] [pid 908:tid 908] (70007)The timeout specified has expired: [client 10.72.233.20:57373] AH01075: Error dispatching request to : (polling), referer: http://10.72.233.19/fog/management/index.php?node=host
[Wed Mar 18 14:09:03.333452 2026] [proxy_fcgi:error] [pid 1210:tid 1210] (70007)The timeout specified has expired: [client 10.72.233.20:57396] AH01075: Error dispatching request to : (polling), referer: http://10.72.233.19/fog/management/index.php?node=host
[Wed Mar 18 14:09:06.698197 2026] [proxy_fcgi:error] [pid 907:tid 907] (70007)The timeout specified has expired: [client 10.72.233.20:57397] AH01075: Error dispatching request to : (polling), referer: http://10.72.233.19/fog/management/index.php?node=host

[tatanas]

No problem with Fog 1.5.10.1763
Very slow with Fog 1.5.10.1798 and nothing in the logs

It’s the second server I’ve updated and the problem is the same.

[Chandlerbing]

Hello @Tom-Elliott

I have the same issue,

I try to install a new server and restore my dumped database.
The new server is not contacted by any fog client. This is slow as hell. I try to check on /etc/apache2/error.log, I got nothing.
My fog.history doesn’t show anything around the stuck time.

I enabled the slow log in fpm.
I got this showing my hosts list :

[19-Mar-2026 16:24:55]  [pool www] pid 51249
script_filename = //var/www/fog/management/index.php
[0x00007f869de13d40] filter_var() /var/www/fog/commons/init.php:25
[0x00007f869de13cc0] {closure:Initiator::setSanitize():23}() /var/www/fog/commons/init.php:28
[0x00007f869de13c50] array_walk() /var/www/fog/commons/init.php:28
[0x00007f869de13bd0] {closure:Initiator::setSanitize():23}() /var/www/fog/commons/init.php:115
[0x00007f869de13b60] array_walk() /var/www/fog/commons/init.php:115
[0x00007f869de13ad0] sanitizeItems() /var/www/fog/lib/fog/fogbase.class.php:1399
[0x00007f869de13a20] arrayChangeKey() /var/www/fog/lib/fog/fogcontroller.class.php:1095
[0x00007f869de13950] setQuery() /var/www/fog/lib/fog/fogcontroller.class.php:1107
[0x00007f869de137f0] setQuery() /var/www/fog/lib/fog/fogcontroller.class.php:140
[0x00007f869de13710] __construct() /var/www/fog/lib/fog/fogmanagercontroller.class.php:415
[0x00007f869de13420] find() /var/www/fog/lib/router/route.class.php:479
[0x00007f869de13300] listem() /var/www/fog/lib/fog/fogpage.class.php:497
[0x00007f869de13200] index() /var/www/fog/lib/fog/fogpagemanager.class.php:220
[0x00007f869de130e0] render() /var/www/fog/management/index.php:69

I can see that fpm www is taking a huge amount of CPU.

I don’t understand what is going on if you need any log I can provide them.

Thank you.

[Tom Elliott]

Can you all edit /var/www/fog/lib/db/pdodb.class.php at line -> 125:

change:

PDO::ATTR_EMULATE_PREPARES => false,

to:

PDO::ATTR_EMULATE_PREPARES => true,

I’m pretty sure this is going to break other things, but it will give me a data point I’m trying to narrow down.

[Chandlerbing]

Hello @Tom-Elliott

From my side nothing changes. I tried on my production server and my fresh server with production database.
I still have some stucking time when I show hosts.
I checked on logs files, nothing new

[tatanas]

No improvement after changing the PDO::ATTR_EMULATE_PREPARES value.
(I did a reboot of the server to be sure.)

[Infojoe]

@Tom-Elliott I modified the file. No change.

[rogalskij]

@Infojoe I am getting this exact same issue. Very long load times on the “Hosts” and “FOG Configuration” pages. Additionally there is a number now appended to the front of all the hosts for some reason.

I updated to the latest dev branch version 1.5.10.1804 hoping for a fix, but alas, no change. I applied patches to Alma Linux 9.7 and rebooted but still seeing high CPU on several processes including apache. I am happy to test anything and everything to assist in fixing this issue.

[Tom Elliott]

@rogalskij The number in front of all hosts (and groups/snapins/images/etc…) is the Database ID of the object in question, that’s expected.

I’m trying to follow what caused this and I’m having a difficult time reproducing it.

[rogalskij]

@Tom-Elliott Thank you for looking into this. Are there any log files from my setup I can provide that would help you? For reference, my server environment is:

Dell Poweredge R620
2x Intel Xeon E5-2640vs 2ghz CPUs
128 Gb ram
Alma Linux 9.7
Fog 1.5.10.1804 (was 1798)

[Tom Elliott]

@rogalskij I don’t know OS:

PHP error logs
/var/log/php-fpm/www-error.log (redhat based)
/var/log/apache2/error.log (debian based)

SQL:
SELECT * FROM history;

I doubt the sql will be of much help, but anything is better than nothing.

Most of the logs I’ve gotten this far don’t appear to have anything and maybe none of them do, in which case I don’t know when the issue was directly introduced.

If anyone is able to bisect known good and the obvious current as the starting bad to figure out when it got introduced?

I’m assuming we’ve all tried reverting to the first known good and verified it is still “good” as well?

Basically if someone doens’t mind taking where they know they’re broken, and iterating back to when it works great to exactly when it fails, it may help us figure out where to start otherwise I’m currently flying blind.

[rogalskij]

@Tom-Elliott I collected both log files and sent them to you directly via “Chat”. you should see all of them in there. Thanks so much for investigating this issue.