# Stuck at: TASK [deploy : Reload php-fpm] on deploy

**URL:** https://discourse.roots.io/t/stuck-at-task-deploy-reload-php-fpm-on-deploy/12119
**Category:** trellis
**Created:** 2018-04-04T21:04:31Z
**Posts:** 8

## Post 1 by @joshb — 2018-04-04T21:04:31Z

Let me apologize in advance if there is an easy fix for this that I was unable to discover.

I’ve updated Trellis on one of my on going projects and everything is fine except when deploying to staging. I haven’t attempted to deploy to production yet.

I’ve been able to provision the server just fine without error but every time I attempt to deploy I get:  
`TASK [deploy : Reload php-fpm]` and it just hangs there forever.

I’ve rebuilt my droplet and started with a fresh trellis install. I’ve tried every fix I’ve been able to search for online but nothing gets me past this point.

If more information is needed I will provide.

BTW- This is a multi-site install.

---

## Post 2 by @Simeon — 2018-04-04T21:22:37Z

SSH into the server and check `sudo service --status-all`

You may have two versions of `php-fpm` installed. For example, Trellis may be trying to restart 7.1 but 7.2 is installed and running on the server. Stop them both `sudo service php-fpm7.x-fpm stop` and try the deploy again.

---

## Post 3 by @joshb — 2018-04-04T21:28:36Z

Thanks.

I checked the services and there is only one version installed and running:

`php7.2-fpm`

I stopped the service and attempted to deploy again but it still hangs.

Is there an easy way to revert back my trellis version? I need to get back to work and don’t have time for this.

---

## Post 4 by @joshb — 2018-04-04T21:43:28Z

Not sure if this helps or not but I made a backup of my local working directory before upgrading Trellis. I just now copied that OG Trellis directory back and ran another deploy. I’m still getting the same problem even with the original Trellis install that was working fine prior to updating…

---

## Post 5 by @Simeon — 2018-04-04T22:33:21Z

Just check through your Trellis files to see if the command it’s trying to run is for 7.2 or 7.1 as well. I’ve had this before where one provision on the server has added 7.2 but other installs are still back on 7.1.

---

## Post 6 by @swalkinshaw — 2018-04-04T22:43:06Z

1. ssh into your server as the `web` user
2. run `sudo service php7.2-fpm reload`

This should give you an idea of what’s going wrong since that’s what Trellis is running.

---

## Post 7 by @swalkinshaw — 2018-04-04T22:49:49Z

Also see both these related threads:

- [Trellis deploy hangs, then fails on reload php-fpm](https://discourse.roots.io/t/trellis-deploy-hangs-then-fails-on-reload-php-fpm/11629/7)
- [Deployment issues with php-fpm](https://discourse.roots.io/t/deployment-issues-with-php-fpm/5860/5)

Did you do a search for similar topics first?

---

## Post 8 by @juanmaguitar — 2018-04-23T16:46:24Z

I was having the same issue and the solution provided by @Simeon worked for me.

From the server, when i did `sudo service --status-all` i could verify that indeed, i had several versions of `php7.X-fpm` running

 ![48](https://discourse.roots.io/uploads/default/original/2X/0/0cfc90b7e82d163eb45d61882c7454bcdc00d6f6.png)

In the image it can be seen that the version started was the `php7.0-fpm` and the error referred to the `php7.2-fpm` one

```
TASK [deploy : Reload php-fpm] ***************************************************************
System info:
  Ansible 2.4.3.0; Darwin
  Trellis at "Support git url format `ssh://user@host/path/to/repo`"
---------------------------------------------------
non-zero return code
reload: Unknown instance:
fatal: [juanmaguitar.com]: FAILED! => {"changed": true, "cmd": "sudo service php7.2-fpm reload", "delta": "0:00:00.018112", "end": "2018-04-23 16:37:59.794869", "rc": 1, "start": "2018-04-23 16:37:59.776757", "stderr_lines": ["reload: Unknown instance: "], "stdout": "", "stdout_lines": []}
	to retry, use: --limit
```

So by stopping the `php7.0-fpm`

```
sudo service php7.0-fpm stop
```

and starting the right one: `php7.2-fpm`

```
sudo service php7.2-fpm start
```

the next deploy worked perfectly