Slow computer listing and high CPU with version 1.5.1.01798

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