Answers.Body: <p>I can think of a couple things why this is happening:</p>
  <h1>1) Custom code doing a save operation.</h1>
  <p>If you're hooking into <a href="https://craftcms.com/docs/plugins/events-reference#entries-onSaveEntry" rel="nofollow noreferrer"><code>onSaveEntry</code></a> for example,  Craft also lets other plugins have a chance at calling their own save code as well.</p>
  <p>So when you do a <code>saveEntry</code> (or other element), Craft is going to <em>repeat</em> that call when you do it from your own code, basically putting you into an infinite loop because it keeps getting called until the server times out.</p>
  <p>The fix is to make sure  you only call <code>saveEntry</code> once. There's a couple ways to do this depending on what you're trying to do.</p>
  <p>One way to debug this would be to a create super simple plugin, using <a href="https://github.com/lindseydiloreto/craft-businesslogic" rel="nofollow noreferrer">Business Logic</a> or <a href="https://pluginfactory.io" rel="nofollow noreferrer">PluginFactory</a> that listens for the <code>saveEntry</code> event and <a href="https://craftcms.stackexchange.com/questions/2905/how-to-log-info-from-an-onsaveentry-event">logs it</a>.</p>
  <p>If you see the plugin's log fill up, then some plugin is putting itself into a loop more than once.</p>
  <h1>2) runTasksAutomatically is not being called</h1>
  <p>Over time, Craft generates a lot of cache files, sessions, etc. Craft will automatically do some housekeeping for you and clean this up, however, the <a href="https://craftcms.com/docs/config-settings#runTasksAutomatically" rel="nofollow noreferrer"><code>runTasksAutomatically</code></a> config doesn't run on some server setups, forcing you to do the maintenance yourself. It's like a stuffed up drain, if it doesn't run for awhile, it takes longer to purge.</p>
  <p>If your server doesn't support cron, you could use an uptime monitoring service like <a href="https://uptimerobot.com" rel="nofollow noreferrer">Uptime Robot</a> or Pingdom to trigger the task call for you periodically.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-09T07:42:14.750Z
Answers.Text: Ok, so to debug things, if #1 is the culprit, would disabling all third-party plugins resolve the issue? And where would I see info about `runTasksAutomatically`? I looked in both the Server Info and Craft Logs screens but found nothing to indicate it wasn't successfully running. The server _does_ appear to have gzip enabled though, which the docs mention is incompatible with `runTasksAutomatically`. So I'm guessing that's the culprit?
Answers.UserDisplayName: Sandwich
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-10T17:57:45.220Z
Answers.Text: I've updated my answer for a couple ways you could test this for both.  #2 is more insidious. It seems to only happen on Apache, not nginx. I've used PHP's FPM on both and Apache has always given me problems. No need for cron on nginx, it just works.
Answers.UserDisplayName: RitterKnight
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-11T11:02:03.373Z
Answers.Text: Ok, cool... I still would like to know if disabling 3rd-party plugins would address #1; I barely have any installed, and the site is still in development, so it's easy to do. As for #2, the sysadmin already disabled gzip (and replaced it with "php compression"), so I'll be testing that for a bit.
Answers.UserDisplayName: Sandwich
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-11T22:07:40.587Z
Answers.Text: @Sandwich: yeh disabling would do the same thing.
Answers.UserDisplayName: RitterKnight
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-07T16:14:35.680Z
Answers.LastActivityDate: 2017-10-10T18:03:35.223Z
Answers.LastEditDate: 2020-06-17T08:56:27.903Z
Answers.UserDisplayName: RitterKnight
Body: <p>Occasionally—I'd say about 30-40% of the time—when submitting a form in the backend, be it saving an entry, updating a custom field, etc, the page will just sit there, loading. This can and often does continue for ~ 299.88 seconds, after which it will proceed to the next screen as if nothing ever happened.</p>
  
  <p>I've looked through the console log, but all the timestamps seem to be within a second of each other, so nothing jumps out as the step where things are getting hung up. I suspect a server problem, but I'm posting here just in case anyone can point me in a more specific direction than "there's a problem somewhere".</p>
  
  <p>To date, this has not occurred on the frontend, but there aren't any frontend forms to submit, either.</p>
  
  <p>Pastebin of the console log (the load time is on line 725): <a href="https://pastebin.com/aB4JkrBv" rel="nofollow noreferrer">https://pastebin.com/aB4JkrBv</a></p>
  
Tags: <control-panel><timeout>
Title: CP form submissions occasionally reaching PHP's 300 second timeout
ThreadText: # CP form submissions occasionally reaching PHP's 300 second timeout
  
  (Asked by: username_0 on 2017-10-07)
  
  Occasionally—I'd say about 30-40% of the time—when submitting a form in the backend, be it saving an entry, updating a custom field, etc, the page will just sit there, loading. This can and often does continue for ~ 299.88 seconds, after which it will proceed to the next screen as if nothing ever happened.
  
  I've looked through the console log, but all the timestamps seem to be within a second of each other, so nothing jumps out as the step where things are getting hung up. I suspect a server problem, but I'm posting here just in case anyone can point me in a more specific direction than "there's a problem somewhere".
  
  To date, this has not occurred on the frontend, but there aren't any frontend forms to submit, either.
  
  Pastebin of the console log (the load time is on line 725): <https://pastebin.com/aB4JkrBv>
  
  **Tags:** control-panel, timeout
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-10-07. Score: 3
  
  I can think of a couple things why this is happening:
  
  # 1) Custom code doing a save operation.
  
  If you're hooking into [`onSaveEntry`](https://craftcms.com/docs/plugins/events-reference#entries-onSaveEntry) for example, Craft also lets other plugins have a chance at calling their own save code as well.
  
  So when you do a `saveEntry` (or other element), Craft is going to *repeat* that call when you do it from your own code, basically putting you into an infinite loop because it keeps getting called until the server times out.
  
  The fix is to make sure you only call `saveEntry` once. There's a couple ways to do this depending on what you're trying to do.
  
  One way to debug this would be to a create super simple plugin, using [Business Logic](https://github.com/lindseydiloreto/craft-businesslogic) or [PluginFactory](https://pluginfactory.io) that listens for the `saveEntry` event and [logs it](https://craftcms.stackexchange.com/questions/2905/how-to-log-info-from-an-onsaveentry-event).
  
  If you see the plugin's log fill up, then some plugin is putting itself into a loop more than once.
  
  # 2) runTasksAutomatically is not being called
  
  Over time, Craft generates a lot of cache files, sessions, etc. Craft will automatically do some housekeeping for you and clean this up, however, the [`runTasksAutomatically`](https://craftcms.com/docs/config-settings#runTasksAutomatically) config doesn't run on some server setups, forcing you to do the maintenance yourself. It's like a stuffed up drain, if it doesn't run for awhile, it takes longer to purge.
  
  If your server doesn't support cron, you could use an uptime monitoring service like [Uptime Robot](https://uptimerobot.com) or Pingdom to trigger the task call for you periodically.
  
  > **Comments:**
  > **username_0**: Ok, so to debug things, if #1 is the culprit, would disabling all third-party plugins resolve the issue? And where would I see info about `runTasksAutomatically`? I looked in both the Server Info and Craft Logs screens but found nothing to indicate it wasn't successfully running. The server _does_ appear to have gzip enabled though, which the docs mention is incompatible with `runTasksAutomatically`. So I'm guessing that's the culprit?  
  > **username_1**: I've updated my answer for a couple ways you could test this for both.  #2 is more insidious. It seems to only happen on Apache, not nginx. I've used PHP's FPM on both and Apache has always given me problems. No need for cron on nginx, it just works.  
  > **username_0**: Ok, cool... I still would like to know if disabling 3rd-party plugins would address #1; I barely have any installed, and the site is still in development, so it's easy to do. As for #2, the sysadmin already disabled gzip (and replaced it with "php compression"), so I'll be testing that for a bit.  
  > **username_1**: @username_0: yeh disabling would do the same thing.  
  
  ---
  
  