Open a ticket -> php process stuck at 100% CPU

energywave

Hello,
on my osticket instance, that was working perfectly until now, there is now a strange and very bad problem.
If a user open a ticket on the public interface the page is stuck with the message "Wait, it will take a moment" (well, I see it in italian language) until php timeout occur, then an HTTP error 500 is shown.

The same is happening when I simply click on some tickets in the admin area, only on certain tickets! Some are opening correctly, other do the same behavior: php stuck at 100% cpu and webserver sluggish (due to cpu consumption), but then the browsers shows the ticket page till the "expiration date" field that is not compiled:

So maybe there is something with that field...?

Note: well php is using 50% cpu in reality as the VM has two virtual cpu, but you get the point.

I've done these trials, with no results:

checked the php log, no relevant error.
set registry level to DEBUG, no relevant entry in the log
updated php (that was 8.1.5) to 8.2.9, same behavior
updated osticket, that was 1.17.3 to 1.18, same behavior (update was successful however)

So I'm now lost. Is there a way to understand what's happening? Activate some sort of a verbose log to see what osticket is stuck on? It could be helpful for many other cases to know what to do in these cases.

Here a screenshot of system info:

FURTHER DIGGING...
So, I've continued to dig and I've found that the problem seems to be the SLA.
I've set the default SLA to nothing and, in the public area, the tickets are now opened without problem.
I've then found the place where the error happened in my php log with this line:
PHP Fatal error: Maximum execution time of 60 seconds exceeded in C:\inetpub\Sites\helpdesk.poliware.net\include\class.schedule.php on line 803

So I've checked that line (it's the $this->_current = clone $from; near the end):

    function getCurrent($from=null) {
        if (!isset($this->_current) || $from) {
            // Figure out starting  point (from)
            $from = is_object($from) ? clone $from : Format::parseDateTime($from ?: 'now');
            $start =  $this->getStartsDatetime();
            if ($start->getTimestamp() > $from->getTimestamp())
                $from = clone $start;
            // Check to make sure we're still in scope
            $stop = $this->getStopsDatetime();
            if ($stop && $stop->getTimestamp() < $from->getTimestamp())
                return null;

            // Figure out start time for the entry.
            $from->modify($this->getIntervalSpec($from));
            $this->_current = clone $from;
        }
        return $this->_current;
    }

But here I don't know how to proceed.
Existing tickets still cannot be opened so I'm now trying to set them to no SLA from the database...
Ok, updated sla_id to 0 (that means "no sla") in the table os_ticket and now os ticket is back to life.

So it's most worth for you to fix this issue so that it will not happen to other people and to understand what happened.
I'll be happy to help you understand by checking what's useful for you.

nandi96

It is very simple.
The problem is:

PHP Fatal error: Maximum execution time of 60 seconds exceeded

Solution: Modify the PHP execution time on your webserver, recommended value: 240-360 s

energywave

nandi96
Thank you but the problem is not that. I started with a maximum execution time of 300 seconds and the request was killing the CPU of my server (as every request there added a php process at 50% cpu...) and I was forced to kill the processes. I even tried to leave the process running but after 300 seconds (hey, 5 minutes in front of a web page...) the timeout error with http 500 arrived.
So I scaled to 60 seconds to be able to see the error and to have a decent timeout (who in the world will wait for 5 minutes in front of a inresponsive website...?)
I'll investigate if it's better to set 300 back again but the problem I had is not related to that.
Furthermore, all those operations without SLA set (or before the problem was present) where super fast, a matter of less than a second...

Thank you for the effort, however 🙂

KevinTheJedi

energywave

Delete the US Holidays schedule under Admin Panel > Manage > Schedules.

Cheers.

energywave

KevinTheJedi
Thank you, I did that but behavior didn't change, same effect.
I've found the php errors log three distinct errors:

[10-Aug-2023 13:05:44 UTC] PHP Fatal error:  Maximum execution time of 60 seconds exceeded in C:\inetpub\Sites\helpdesk.poliware.net\include\class.schedule.php on line 686
[10-Aug-2023 13:10:15 UTC] PHP Fatal error:  Maximum execution time of 60 seconds exceeded in C:\inetpub\Sites\helpdesk.poliware.net\include\class.schedule.php on line 832
[10-Aug-2023 13:10:45 UTC] PHP Fatal error:  Maximum execution time of 60 seconds exceeded in C:\inetpub\Sites\helpdesk.poliware.net\include\class.schedule.php on line 855

I tried to tinkering with SLA plan, changing schedule and holidays but that isn't changing the behavior. When I create a ticket with SLA set php process will be stuck.

KevinTheJedi

energywave

Apply this patch:

diff --git a/include/class.schedule.php b/include/class.schedule.php
index 1b02469a3..38cffa833 100644
--- a/include/class.schedule.php
+++ b/include/class.schedule.php
@@ -1052,7 +1052,7 @@ class ScheduleEntry extends VerySimpleModel {
         static $translated = false;
         if (!$translated) {
             foreach (static::$days as $k=>$v)
-                static::$days[$k] = __($v);
+                static::$days[$k] = $v;
         }
 
         return static::$days;

Cheers.

energywave

"Damn"! I was tinkering even further with schedule and... it stopped to get stuck! I don't know what exactly was, however. I had in my main schedule every single week day as a single item (monday, tuesday, etc) and I've inserted one item only as "weekday" (mon-fri), then I've inserted in holidays Easter 2024 and the monday after Easter. From then it stopped to get stuck even if setting SLA but maybe a single setting that I've changed and I don't remember... I'm sorry.

Do you have an idea on what it could be? Do you want me to apply the patch even if now the problem is not there anymore? Could that help you?

KevinTheJedi

energywave

My commit notes from the patch are:

This addresses an issue where using a language such as French breaks the Ticket view page for Tickets with no Due Date, SLA with grace period longer than 41 hours, and the SLA is attached to a Schedule with working days. This is due to mistakenly translating the day names in getDays() function. PHP only likes English day names. This removes the translation method from the days so the names are in English and the page does not break.

So the issue is with translating certain days and PHP does not like that; only english dates.

Cheers.

energywave

KevinTheJedi
Ok, I can confirm that the patch seems to work with no error. It was already working and I don't know why but making the patch there is no problem.
Thank you so much for your great help!