Good morning

Since a couple of days I have the following problem, using the updated version of Osticket 1.17.3. This version has been installed and working for several weeks.

Entering a new ticket, either from the main panel, or from an operator via the manual entry function, the ticket is immediately entered, seemingly smoothly, but the panel remains "waiting", with the message:

WAIT... IT WILL TAKE A MOMENT

After exactly 5 minutes, web server error 500 comes out.

This is the message I find in the webserver log:

mod_fcgid: read data timeout in 301 seconds, referer: https://supporto.cpbesana.it/open.php

In php.ini there is the following parameter:

max_execution_time = 299

What could have happened? Does anyone have any suggestions on this?

To summarize: the ticket entry is successful, but the procedure is waiting for "something", until the timeout.

Thank you

    cpbesana

    Probably email issues. When posting a reply we then generate the response to the user and any alerts to agents. Sounds like it’s taking too long to connect to mail server and timing out. Can’t be sure unless you do further tracking.

    Cheers.

      Thank you. We can't rule it out.

      But how is it possible to debug it more thoroughly?
      And why does it seem that it is the web server that is going wrong?

      Also: even from the operator panel, the moment I click on a ticket that is already there, an activity that therefore I don't think involves the mail server in any way, how come it seems that the program is again waiting, I don't know what, until some sort of timeout?

      To summarize: how do you go about enabling a more timely logging system?

      The web server side log registers problems, and I can't figure out if it is an application side malfunction, or hosting side.

      Thank you

        cpbesana

        The way you described it sounded like this issue occurs when posting a reply, am I correct? If so, then it would definitely seem like it's waiting on the mail to send.

        You can set your Default Log Level to DEBUG but this likely won't help. Other than that you can review your logs (general server logs, webserver error logs, PHP error logs, MySQL/MariaDB error logs, osTicket System Logs, Browser Console logs, etc.) for any related errors.

        Cheers.

          6 days later

          I would like to add some details, as we are in trouble and cannot find the problem.
          We have meanwhile had to STOP the service...

          The problem on sending the message is not ruled out.
          But then I tried running OSTicket's internal function--from the administrator's panel--by which I ran the EMAIL DIAGNOSTICS function on all three of the addresses we use, and they all yielded POSITIVE results. The messages were sent and received.

          The other strange thing is that the tickets BEFORE the problem, you are able to open them, without any problem.
          Those entered since the onset of the problem, do NOT open.
          And again you find various errors in the WEB server log.

          I've also tried to check for problems on the database out of scrupulosity: no reports.

          In short.
          I can't figure out where the problem lies: whether it's a problem with the application, or with the web server....

          Any additional suggestions?
          Thanks

            cpbesana

            Other than checking your logs the only other option would be to start from the beginning and debug. Ruling out every step from the beginning.

            You can also enable MySQL slow query logs to see if any query is taking too long to execute and timing out.

            Cheers.

              5 days later

              After a LONG series of debugging activities, including transferring the entire application from the hosting environment to a local PC environment, via XAMPP, I found the "problem".

              I think it may be useful to share the result, so that it may become useful for anyone else in the same situation.

              All problems depend on DEFAULT SLA (time limit for ticket resolution).

              I guess it is a malfunction....
              I don't give myself any logical explanation....

              Basically, by setting Grace Period: 48 hours, as of April 18, the procedure was no longer able to enter a new ticket without going into timeout, just as it was no longer possible for an Agent to open tickets other than those previously entered.

              Even with a new installation performed from scratch, done locally on the PC, with DB creation from "blank," with Grace Period: = 16 hours (default proposed by the installation), it works. With 48 hours it crashes.
              I had set it to 48 hours from the very day of my installation, two years ago, and it always worked.... Until April 18.

              Granted that in my case there was NO specific interest in the function of checking for delays in closing tickets, I DISABLED the SLA function, and everything started working again.

              I hope I have made myself clear. Sorry if I was a bit long.

              a year later

              Hi everybody,
              I think this is worth investigating more.
              I am having the exact same problem with my osTicket installation (v1.18.1).
              I tried creating a dozen tickets from the web UI, and each and every time the request would wait forever until reaching the PHP max_execution_time.
              The web server logs report an HTTP 500 error.
              The PHP logs report reaching the max_execution_time.
              Other logs do not report anything suspicious.

              When I go to the tickets list page, I see that the ticket has been created, but if I click on it the page stalls.
              However, if I enter the URL directly I can see the ticket, and I have verified that, each time, the created ticket is malformed (missing several parts) and the UI somehow misbehaves (menus become transparent and other glitches).
              Meanwhile, after clicking on the malformed ticket, the server show a couple of php-fpm processes eating 100% of a cpu.
              If I go again to the list of tickets and delete the malformed tickets, everything goes back to normal (and after a while, the cpu-eating processes die or slow down).

              Creating the exact same ticket by email, it works without issues.

              I have been fighting with this problem all the afternoon, until I found this thread.
              As soon as I created a new ticket from the web UI, doing exactly the same things as before, but NOT EXPLICITELY SPECIFYING A SLA for the new ticket, it worked in half a sec!

              Now I know how to avoid the problem, but I think it should be investigated more.

              Thank you in advance.
              Cris

                Write a Reply...