Answers.Body: <p>Without direct access to the Supervisor configuration, the system may be using the default <code>startretries</code> setting, and running out of attempts. The progressive “back-off” may be inadequate to survive intermittent database connectivity issues:</p>
  <blockquote>
  <p>Retries will take increasingly more time depending on the number of subsequent attempts made, <strong>adding one second each time</strong>.</p>
  <p>So if you set <code>startretries=3</code>, supervisord will wait one, two and then three seconds between each restart attempt, for <strong>a total of 5 seconds</strong>.</p>
  </blockquote>
  <p>(<a href="http://supervisord.org/subprocess.html#process-states" rel="nofollow noreferrer">Source</a>)</p>
  <p>If you are unable to change this behavior, there is no harm in configuring a second, scheduled queue runner. My recommendation would be to alert Forge of the issue, especially if the underlying services are part of a package configured by their platform.</p>
  <p> Check your logs for evidence that might point to the reason for the exit!</p>
  <hr />
  <p>In general, <code>runQueueAutomatically</code> can be disabled when you have a scheduled or daemonized queue runner.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-06-24T19:11:59.893Z
Answers.Text: Unfortunately, the issue is more complex. A couple other people (including me) are having the issue where queue jobs stop being processed. The problem is that the daemon doesn't fail or crash, it just stops processing queue jobs. So supervisor doesn't even attempt to restart the service. I've [described a workaround (restarting all daemons nightly) here](https://craftcms.stackexchange.com/a/41261/11705). But still no idea what's causing this. Forge support won't be able to help, as it's likely Craft-specific.
Answers.UserDisplayName: MoritzLost
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-06-24T17:54:35.593Z
Answers.LastActivityDate: 2024-06-24T17:54:35.593Z
Answers.UserDisplayName: August Miller
Body: <p>I'm a little confused about the best way to setup server processes using Laravel Forge with Craft CMS (4.8.0).</p>
  <p>Currently we are running the following <a href="https://forge.laravel.com/docs/resources/daemons.html" rel="nofollow noreferrer">Daemon</a>:</p>
  <p><code>/usr/bin/php /home/forge/domain.com/craft queue/listen --verbose</code></p>
  <p>Should I be running this as a <a href="https://forge.laravel.com/docs/resources/scheduler.html" rel="nofollow noreferrer">Scheduler</a> instead?</p>
  <p>And should <a href="https://craftcms.com/docs/4.x/config/general.html#runqueueautomatically" rel="nofollow noreferrer">runQueueAutomatically</a> be set to false in either case?</p>
  <p>The problem with the current setup is the daemon fails and gets backed up quite often. I'm still researching the problem but would love to hear if anyone else has a more hardened solution in a similar scenario as mine.</p>
  
Tags: <php><craft4><server>
Title: Craft Queue in Laravel Forge: Scheduler or Daemon?
ThreadText: # Craft Queue in Laravel Forge: Scheduler or Daemon?
  
  (Asked by: username_0 on 2024-06-24)
  
  I'm a little confused about the best way to setup server processes using Laravel Forge with Craft CMS (4.8.0).
  
  Currently we are running the following [Daemon](https://forge.laravel.com/docs/resources/daemons.html):
  
  `/usr/bin/php /home/forge/domain.com/craft queue/listen --verbose`
  
  Should I be running this as a [Scheduler](https://forge.laravel.com/docs/resources/scheduler.html) instead?
  
  And should [runQueueAutomatically](https://craftcms.com/docs/4.x/config/general.html#runqueueautomatically) be set to false in either case?
  
  The problem with the current setup is the daemon fails and gets backed up quite often. I'm still researching the problem but would love to hear if anyone else has a more hardened solution in a similar scenario as mine.
  
  **Tags:** php, craft4, server
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-06-24. Score: 2
  
  Without direct access to the Supervisor configuration, the system may be using the default `startretries` setting, and running out of attempts. The progressive “back-off” may be inadequate to survive intermittent database connectivity issues:
  
  > Retries will take increasingly more time depending on the number of subsequent attempts made, **adding one second each time**.
  >
  > So if you set `startretries=3`, supervisord will wait one, two and then three seconds between each restart attempt, for **a total of 5 seconds**.
  
  ([Source](http://supervisord.org/subprocess.html#process-states))
  
  If you are unable to change this behavior, there is no harm in configuring a second, scheduled queue runner. My recommendation would be to alert Forge of the issue, especially if the underlying services are part of a package configured by their platform.
  
  Check your logs for evidence that might point to the reason for the exit!
  
  ---
  
  In general, `runQueueAutomatically` can be disabled when you have a scheduled or daemonized queue runner.
  
  > **Comments:**
  > **username_2**: Unfortunately, the issue is more complex. A couple other people (including me) are having the issue where queue jobs stop being processed. The problem is that the daemon doesn't fail or crash, it just stops processing queue jobs. So supervisor doesn't even attempt to restart the service. I've [described a workaround (restarting all daemons nightly) here](https://craftcms.stackexchange.com/a/41261/11705). But still no idea what's causing this. Forge support won't be able to help, as it's likely Craft-specific.  
  
  ---
  
  