Slow computer listing and high CPU with version 1.5.1.01798

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

[Tom Elliott]

Is everyone having this particular problem consistently using the LDAP plugin by chance?

[rogalskij]

@Tom-Elliott Yes we utilize the LDAP Plugin for all logins. Version 1.5.5, I will tried logging in with a local account but the slowness persisted.

[rogalskij]

A test for anyone having this issue. I did a little trouble shooting, and if you go to: Reports > Pending Mac List and approve all the pending mac addresses at once, performance improved somewhat.

I am unsure if this is coincidental but for me my “Hosts” tab is now much more responsive. Same thing with the “Fog Settings” tab. Give that a try. Certainly worked for me for the moment.

[Petěrko]

Hi,
dev-branch 1.5.10.1754 was OK.
dev-branch and stable 1.5.10.1798 is not OK.

Running on Debian VM 13.4 in Proxmox.
Everything is OK until I click “Hosts” . PHP-FPM starts eating taking 100% of CPU for minutes but gives no errors in apache2 or php8.4-fpm logs.
Other listings and dashboard are OK. Report/Pending Mac List is slow too.

Approve All Pending MACs for All Hosts returned the speed of server back to normal. Thanks @rogalskij!

Host IDs are showed in front of names like this: (271) - DELL-AT-WORK

Installed PlugIns
accesscontrol
persistentgroups
site
tasktypeedit

I have got a plenty of these warnings but it is problem of old plugin, I suppose:
[Sat Mar 21 06:28:04.452523 2026] [proxy_fcgi:error] [pid 781:tid 781] [client 172.28.99.2:54436] AH01071: Got error ‘PHP message: PHP Warning: Undefined array key 0 in /var/www/html/fog/lib/plugins/site/hooks/addsitefiltersearch.hook.php on line 220’, referer: https://**********/fog/management/index.php?node=task&sub=active

[Petěrko]

Unfortunately solved just for a moment.
No pending MACs but the Hosts listing is very slow again.
Peter

[Infojoe]

@Tom-Elliott No LDAP here.

[Chandlerbing]

Hello @Tom-Elliott

No LDAP plugin, logins are local
I don’t have any pending mac to approve.

Thank you for your time @Tom-Elliott

[Tom Elliott]

@Infojoe Unfortunately my test environment where I would normally work on these things hasn’t been behaving nicely.

Luckily, however, a fellow developer @rodluz was able to narrow the “what” and I believe I have fixed it.

The issue at least based on what was found:

PHP 8.1 deprecated the FILTER_SANITIZE_STRING feature and I replaced it with FILTER_SANITIZE_SPECIAL_CHARS or something alike to it.

This was the expected change at the time, but forgot that special characters may show up in Session variables (among other variables)

So say an & would get created, well FILTER_SANITIZE_SPECIAL_CHARS would encode & to & which would then see the & again and perform the same trick over and over and over in a recursive loop.

This is what was causing the CPU spikes, my apologies for that oversite. This has been addressed within the latest dev-branch if anyone would like to kick the tires?

Thank you!

[Chandlerbing]

Hi @Tom-Elliott

I think this is it. I just updated on the latest dev branch and I don’t have any CPU spike and no waiting time when I sho the host anymore.

Thank you for this tricky updates!

Good job