High CPU usage issue with Perl under macOS 26

[phillscholl]

Bug reporting acknowledgment

Yes, I read it

Professional support

None

Describe the bug

Under macOS 26, Perl sometimes consumes 99% CPU indefinitely. The only way to resolve the issue is to kill the process or restart the system.

GLPI-Agent version 1.15

To reproduce

1.	Open Activity Monitor.
2.	Observe system processes over time.
3.	The issue occurs randomly, with perl sometimes getting stuck at 99% CPU usage.

Expected behavior

Perl should terminate or return to normal CPU usage after completing its task.

Operating system

MacOSX

GLPI Agent version

v1.15

GLPI version

10.0.18

GLPIInventory plugin or other plugin version

No response

Additional context

No response

[phillscholl]

I attached a sample trace of the hanging glpi-agent Perl process

What the sample shows:
• The Perl process stays stuck in a tight loop for many hours.
• The main thread repeatedly cycles through:
• XS_IO__Poll__poll → Perl_my_poll → __select
• followed by Perl_pp_sysread
• then a large amount of Perl opcodes.
• This indicates continuous poll/read activity in userland rather than a blocking syscall or deadlock.
• The trace does not reveal which internal agent task triggers the loop.

The attached file (glpi-agent-perl-sample.txt) contains the full sample output.

glpi-agent-perl-sample.txt

[phillscholl]

[andreilabin]

we're also affected, seeing multiple instances where users try to uninstall. please look into it.

[g-bougard]

Hi,

the problem here is there's no clue showing what could be the problem behind. If the problem is recurrent, even happens every time after a while, can you enable debug=2 in configuration and share the resulting log ?

My guess for now is something probably heavily changed in OS comportment under MacOS 26 and glpi-agent may be impacted.

If the problem happens every time an inventory is run, you can share the output of the following command run from a root console:

glpi-agent --logger=stderr --debug --debug --force --full

[phillscholl]

Hi,

The Problem does not happen every time an inventory is run, so i will enable debug=2 and will keep you up to date.

[g-bougard]

If the problem occurs on other computers, try to install also nightly build on another one and check if the problem still occurs there. Nightly build uses perl 5.42 and OpenSSL 3.5.4 where 1.15 uses perl 5.40.2 and OpenSSL 3.5.0, this still may make a difference.

[phillscholl]

I will try with the nightly build on one machine to see if the problem would be solved.

[phillscholl]

Still the same issue with v. 1.16 Nightly build

[g-bougard]

Then have you anything to share which can help to identify where could be the problem ? Maybe in log after you enabled debug=2 ?

[phillscholl]

Attached is the log file with debug=2 enabled from the moment the Perl problem started.

glpi-agent.log

[g-bougard]

Hi @phillscholl

in your log, I see the inventory task starting just before 9h45 and the inventory is sent approximately 30 seconds after.

The last line tells when the next run should occur, one hour later. But it seems glpi-agent didn't get any answer from the server.

So do you mean nothing comes in the log since then ?
If yes, can you check server-side if glpi answered to the request ? You may even check the GLPI php-errors.log for errors.

[phillscholl]

Since I installed the nightly build, yes — on the inventory server I can see that the last inventory it received was from before the installation. But this is not the issue right now. The problem is that Perl still randomly gets stuck at 99.9% CPU indefinitely.
The glpi-agent itself (version 1.15) is reporting to the server and the log looks fine. Inventory is still working even while Perl is already stuck.

[g-bougard]

I just understood few lines are missing just after the inventory submission: you have authentication enabled as we can see at the beginning after the first request:

[Thu Dec  4 09:44:59 2025][debug] [http client] authentication required, submitting credentials
[Thu Dec  4 09:44:59 2025][debug] [http client] authentication required, trying basic with xxxxxxx user (xxxxxxxxx)
[Thu Dec  4 09:44:59 2025][debug2] format: Zlib

This is correct, but the fact they are missing when submitting inventory can suggest the problem is linked to a processing during the connection to the server.

In the case you don't require to extract server certificate from your system keychain, can you try the following option and tell us if at least one seems to work-around the problem ?

1. Using system CA keychain:

   ssl-keystore = system-ssl-ca
   

2. Disabling keychain with:

   ssl-keystore = none
   

3. Disabling ssl check with

   no-ssl-check = 1
   

P.S.: Edited to change the order of testing