Tickets not closing, PHP fatal error

sickopsycho

Recently installed version 1.14.1 of OSTicket. Used PHP7.3 and apache, per documentation. We receive a strange error when attempting to close some tickets. I cannot seem to find any relation between the tickets we have had this error with. Initially, the first one had a large number of images in it, so I assumed it was having trouble parsing those images. I had since denied use of images, and have received the same error. Basically, I'll go to close a ticket, and it will time out giving me a generic 504 Gateway Time-out error in the browser window. When I "tail ... apache2/error.log", I receive the following error...

PHP Fatal error: Maximum execution time of 60 seconds exceeded in /var/www/html/upload/include/class.schedule.php on line 770

I initially received an error of PHP running out of memory, so I upped the default memory and the error changed to timeout after 30 seconds, per a thread I saw about a similar issue that went unresolved. I upped the execution time to 60 seconds (next obvious troubleshooting step), but it appears something is hanging. Any suggestions of where to look next? 90% (or more) of our tickets close correctly, and we don't have any issues with them. But these 2 for some reason are not closing correctly and I cannot find any correlation between the two of them.

Edit: I did not mention, OSTicket is running on bare metal install, Debian latest release.

Also, I have all suggested PHP extensions installed and configured. The only warning I was getting on the "about" page of OSTicket were regarding PHP settings...
PHP Settings
cgi.fix_pathinfo "1" is recommended if AJAX is not working <---- I changed to one, but it did not take effect.

date.timezone America/New_York <--- I recently added the time zone.

ntozier

This
PHP Fatal error: Maximum execution time of 60 seconds exceeded

Means that a script ran and it took longer than you allow scripts to run on your system. This directive is configurable in your PHP.ini. I'm not sure what would cause this to run for so long though. So I'll ask a dev if they have any suggestions.

Out of curiosity are you running anything like SELinux or mod_security?

sickopsycho cgi.fix_pathinfo "1" is recommended

is only used on IIS.

sickopsycho

ntozier

Yup. The default timeout was 30 seconds, but I changed it to 60 when I saw the error for troubleshooting.
selinux is not enforced, and we are not running mod_security as it is an internal only ticketing system. Thank you for the quick reply, I have seen a couple of other posts regarding a similar issue, and while none of the ones I have found were marked as resolved, the first couple steps seemed to be give PHP process more ram and extend the timeout a little longer. Unfortunately neither of these helped our situation.

ntozier

Mine is set to 300. (5 minutes)
You might try setting it to the same and see if the script finishes.

sickopsycho

ntozier
I'll give it a go and report back what I find.

sickopsycho

I have set the timeout to 300 seconds and am waiting for another error. Unfortunately the offending ticket from before was deleted 😅 so I do not have a ticket to test the change against. Just wanted to update, as I still consider this issue open.

ntozier

I'll leave this thread open. Let us know if it happens again.

sickopsycho

I think I've located the issue. Seems to be related to an SLA I created with an excessive time. I created an SLA "pending response" that had a grace period of 114,890 years. My intent was just to have an open ticket that would not be marked late as it is assumed that we are waiting on a response. I entered a bunch of 9's without thinking of how long it actually was. I tested the theory by changing the SLA in a ticket that was crashing when I tried to close it, and I was able to successfully close it when I shortened the SLA. I have since changed that extended SLA to a shorter time frame of 1 year (8760 hours- this may even be excessive, but I'll keep an eye on it). I think this issue is resolved, and if you would like to close this thread that would be fine. Thank you for the assistance-

sickopsycho

The shortened "extended" SLA works fine. Note to self- spend a second to think about what you are entering into configs. It might save you a headache in the future.