# Is the restart of PHP-FPM on each deploy necessary?

**URL:** https://discourse.roots.io/t/is-the-restart-of-php-fpm-on-each-deploy-necessary/21672
**Category:** trellis
**Tags:** trellis
**Created:** 2021-11-08T13:14:44Z
**Posts:** 13

## Post 1 by @charlestroluxe — 2021-11-08T13:14:44Z

One of the last things that Trellis does on a deploy is restart the PHP-FPM service. Is there a reason it **has** to do this, or is it just good housekeeping? We have a number of Trellis-deployed sites on the same server, so, when we deploy updates to one of them, there is the potential for anyone who is logged into the back end of any of them to see a temporary Bad Gateway error while PHP-FPM comes back up. If it’s imperative, we’ll work around it; if not, I was flirting with disabling the restart.

---

## Post 2 by @strarsis — 2021-11-08T16:28:37Z

`php-fpm` is actually _reloaded_ and not restarted:

> <https://github.com/roots/trellis/blob/17430191bb7211545eb63ba3ba989ee95c262c5f/roles/deploy/hooks/finalize-after.yml#L36>

Reloading should (if all works well) gracefully end all existing connections and seamlessly hand over to new `php-fpm` processes.

---

## Post 3 by @charlestroluxe — 2021-11-08T16:49:52Z

Hmm, you’re right. It does reload. And yet, if I’m clicking around in the backend when it does it, I get a 502. And if I look at the NGINX error.log at that time, I see a series of these:

```
2021/11/08 08:14:18 [error] 23955#23955: *12105796 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: <redacted>, server: <redacted>, request: "GET /example/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm-wordpress.sock:", host: "example.com", referrer: "https://example.com/example/"
```

Given what you’re saying, though, this shouldn’t happen?

---

## Post 4 by @charlestroluxe — 2021-11-08T16:59:31Z

I’m assuming that I should be increasing the `process_control_timeout` variable here. But I notice that it’s not in the `roles/wordpress_setup/templates/php-fpm.conf.j2` file by default. Obviously, I could add it in, and then define it, but before I do I’d like to know there’s not a good reason it was left out in the first instance.

---

## Post 5 by @strarsis — 2021-11-08T20:03:58Z

Good question. From what I read and understand is that `php-fpm` had this issue primarily with PHP 5.x.  
You are quite probably using `php-fpm` 7.x or even 8.x so this issue is still there.

Without bugs and unexpected side-effects, a server _reload_ should not result in terminated or failed connections.

---

## Post 6 by @charlestroluxe — 2021-11-11T23:28:43Z

I changed the `process_control_timeout` setting to 10 seconds, and this problem went away. The default is 0.

You can find this setting in `/etc/php/7.4/fpm/php-fpm.conf` (assuming you’re using 7.4; if not substitute accordingly).

The entry should look like this:

```
; Time limit for child processes to wait for a reaction on signals from master.
; Available units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
process_control_timeout = 10
```

---

## Post 7 by @strarsis — 2021-11-12T12:23:10Z

Does this improve the server performance or stability?  
If so, it should be be added to Trellis.

---

## Post 8 by @charlestroluxe — 2021-11-12T13:31:37Z

I’ve noticed no difference to the performance, although it’s early. I have noticed that it prevents users who are logged into the backend from getting 502s during deploys, which is what I was trying to achieve.

---

## Post 9 by @strarsis — 2021-11-12T13:44:06Z

Those HTTP 502s were directly shown in user browsers/clients, disrupting the experience/operations?  
If this is the case, it may make sense to increase that value from `0` in the defaults.

---

## Post 10 by @charlestroluxe — 2021-11-12T14:01:25Z

That’s correct. They also showed up in the logs at the exact same time, in this format:

```
2021/11/08 08:14:18 [error] 23955#23955: *12105796 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: <redacted>, server: <redacted>, request: "GET /example/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm-wordpress.sock:", host: "example.com", referrer: "https://example.com/example/"
```

---

## Post 11 by @strarsis — 2021-11-12T14:46:33Z

If you like, you could create a new [issue in the Trellis repository](https://github.com/roots/trellis/issues) for changing the default value to something non-zero (e.g. `10` as you ended up with) in order to fix these kinds of issues.

---

## Post 12 by @swalkinshaw — 2021-11-18T03:42:55Z

For reference, PHP-FPM needs to be reloaded so PHP recognizes the new underlying path since Trellis creates a new release folder for each deploy and updates the `current` symlink to point to that one.

---

## Post 13 by @system — 2021-12-20T13:15:41Z

This topic was automatically closed after 42 days. New replies are no longer allowed.