<p>I wanted to post a follow-up in case anyone else encounters a similar error.</p>
<p>It appears the error itself is being reported by a Symfony library. But what it's reporting (in the case of a signal 9 error) is that the process was terminated via <code>SIGKILL</code>. The reason for this could be any number of things.</p>
<p>To troubleshoot further I ran some after-hours tests with our hosting partners and we determined that the servers were dealing with an <strong>out of memory (OOM) error</strong>. Seems the introduction of PHP-FPM in the infrastructure has changed the way the php processes are given memory and it's possible for them to use/require more than the previous infrastructure had.</p>
<p>We swapped the server instances we were using with ones that had significantly more memory. Once we did that the errors were no more!</p>
<p>Hope this is useful to anyone else encountering a &quot;signal 9&quot; error in their Craft queue.</p>

CC BY-SA 4.0
2021-08-12T12:19:48.593Z
2021-08-12T12:19:48.593Z
Aaron Bushnell
<p>I think this is a Symfony error for when the server kills your PHP process. Could be a timeout or exhaustion of RAM.</p>
<p>Are you using the Craft Async Queue plugin? It offloads these jobs to the PHP CLI to run in the background and lets you get around timeouts and jamming your site up.</p>
<p>I'd tail or grep through both your Craft error logs and Apache logs for hints too.</p>

CC BY-SA 4.0
2021-08-09T12:19:15.283Z
Good question! We do run the queue via the CLI with a cron job. So `runQueueAutomatically` is set to `false` and we have a cron job running every minute to send the `queue/run` command. Unfortunately, we've had no luck in the Craft logs, but the Apache logs are worth checking into! What about PHP-FPM logs? Anything there?
Aaron Bushnell
CC BY-SA 4.0
2021-08-10T16:19:24.983Z
I don't know that the PHP-FPM logs would say much but don't rule them out. Check your cron logs too (/var/log/cron). For important cron jobs I like to use EasyCron (or a similar service) because they are super cheap and give you retry, debugging logs, etc. Check your RAM usage too in AWS for that VM. Spitballing here!
Judd Lyon
CC BY-SA 4.0
2021-08-12T12:21:41.143Z
This was super helpful in determining the answer! Thanks very much for your suggestions, Judd
Aaron Bushnell
CC BY-SA 4.0
2021-08-09T03:35:40.483Z
2021-08-09T03:35:40.483Z
Judd Lyon
<p>We're running Craft in an AWS environment that is configured using CentOS 7, Apache 2.4.x, PHP 7.4.x, PHP-FPM and we've noticed many of our queued tasks fail (sometimes only 8-10 minutes into the process) with the following error:</p>
<blockquote>
<p>The process has been signaled with signal &quot;9&quot;.</p>
</blockquote>
<p>Perhaps I'm wrong, but this error seems like a low-level process is running the <code>KILL</code> command on processes that are taking too long to complete. However, I'm not sure where to look to debug this.</p>
<p>Are there any recommendations on where to check on these settings and how to prevent this?</p>

<php><performance><server><queue>
What server settings would be responsible to debug "The process has been signaled with signal 9" errors?
# What server settings would be responsible to debug "The process has been signaled with signal 9" errors?

(Asked by: username_0 on 2021-08-09)

We're running Craft in an AWS environment that is configured using CentOS 7, Apache 2.4.x, PHP 7.4.x, PHP-FPM and we've noticed many of our queued tasks fail (sometimes only 8-10 minutes into the process) with the following error:

> The process has been signaled with signal "9".

Perhaps I'm wrong, but this error seems like a low-level process is running the `KILL` command on processes that are taking too long to complete. However, I'm not sure where to look to debug this.

Are there any recommendations on where to check on these settings and how to prevent this?

**Tags:** php, performance, server, queue

---

## 2 answers

### Answer by username_0 on 2021-08-12. Score: 1 | Accepted answer

I wanted to post a follow-up in case anyone else encounters a similar error.

It appears the error itself is being reported by a Symfony library. But what it's reporting (in the case of a signal 9 error) is that the process was terminated via `SIGKILL`. The reason for this could be any number of things.

To troubleshoot further I ran some after-hours tests with our hosting partners and we determined that the servers were dealing with an **out of memory (OOM) error**. Seems the introduction of PHP-FPM in the infrastructure has changed the way the php processes are given memory and it's possible for them to use/require more than the previous infrastructure had.

We swapped the server instances we were using with ones that had significantly more memory. Once we did that the errors were no more!

Hope this is useful to anyone else encountering a "signal 9" error in their Craft queue.


---

### Answer by username_1 on 2021-08-09. Score: 2

I think this is a Symfony error for when the server kills your PHP process. Could be a timeout or exhaustion of RAM.

Are you using the Craft Async Queue plugin? It offloads these jobs to the PHP CLI to run in the background and lets you get around timeouts and jamming your site up.

I'd tail or grep through both your Craft error logs and Apache logs for hints too.

> **Comments:**
> **username_0**: Good question! We do run the queue via the CLI with a cron job. So `runQueueAutomatically` is set to `false` and we have a cron job running every minute to send the `queue/run` command. Unfortunately, we've had no luck in the Craft logs, but the Apache logs are worth checking into! What about PHP-FPM logs? Anything there?  
> **username_1**: I don't know that the PHP-FPM logs would say much but don't rule them out. Check your cron logs too (/var/log/cron). For important cron jobs I like to use EasyCron (or a similar service) because they are super cheap and give you retry, debugging logs, etc. Check your RAM usage too in AWS for that VM. Spitballing here!  
> **username_0**: This was super helpful in determining the answer! Thanks very much for your suggestions, Judd  

---

