Deployment issues with php-fpm

The reload php task is the very last step. If the task hangs/fails, you can do the reload manually, as above. Then you should have your site up for your interview.

However, you’ve since pointed out a couple problems (dict object has no attribute x, invalid repo) that should have caused the playbooks to fail sooner. It leaves me uncertain about how completely your server is provisioned.

You could try to use the server you’ve been working with. You could ssh into your remote, then cd /srv/www/ and work with wp-cli to complete your WordPress setup, if necessary. You may need to rsync/scp/ftp your theme files into place.

Otherwise, if you have your theme files ready but just need a server, you could try the DigitalOcean one-click WordPress install. I’ve never used it. Of course, you could also just use any other host and standard method of installing WordPress and your custom theme.

I’m having this same issue with [deploy : Reload php-fpm] hanging.

I’ve tried changing those three lines but got this error instead:

reload: Rejected send message, 1 matched rules; type="method_call", sender=":1.5050" (uid=1000 pid=32337 comm="reload php7.0-fpm ") interface="com.ubuntu.Upstart0_6.Instance" member="Reload" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init") fatal: []: FAILED! => {"changed": false, "failed": true}

If I SSH into the server as web user and try to reload php-fpm it prompts me for a password. (You mentioned this is bad). If I SSH in as root I can reload it.

I tried both those adhoc commands mentioned above and got errors as well.

The ansible-playbook works fine to completion, but I can’t run the deploy. It hangs every time at this same point.

@Simeon I see from other threads that you’ve been working on getting your first successful provision and deploy. It sounds like you have your setup and config all working now but the deploy is just hanging on this final task Reload php-fpm.

If you haven’t tried it already, I’d recommend running server.yml and deploy.yml on a completely fresh VPS/server now that your configs are sorted out. When users have various failed iterations on a given server then encounter an obscure problem (like this thread), the problem is often absent when the users just run their latest setup on a fresh server.

If that doesn’t resolve it, I also noticed this…

Could you tell us whether you have the Reload php-fpm problem on a fresh DO droplet? Could you also tell us if this is Ubuntu 14.04 or something else?

You’re right! I’m learning plenty and trying to get this going…

This is a completely fresh Trellis/Bedrock setup, and I just destroyed and rebuilt my Binary Lane server.

I’ve been able to get Trellis going on DO once before, but it’s imperative I get this working on Binary Lane as DO don’t have an Australian server…

Currently installed: Ubuntu 14.04 LTS (64bit)


ansible "web:&production" -m service -a "name=php7.0-fpm state=reloaded" -u web


ansible "web:&production" -m service -a "name=php7.0-fpm state=reloaded" -u root


Could you confirm that you have web_user: web?

Also, on the remote server…

Contents should look like this:

web ALL=(root) NOPASSWD: /usr/sbin/service php7.0-fpm *

group_vars/all/users.yml contains web_user: web

Also the web-services file exists and only contains

web ALL=(root) NOPASSWD: /usr/sbin/service php7.0-fpm *

I’m not familiar with sudoers beyond what has been addressed above. When I start a google search on the topic, the first few results are instances of the NOPASSWD entry being overridden by subsequent matching sudoer entries. You might check your /etc/sudoers and ensure that the last line is the include statement #includedir /etc/sudoers.d and that there aren’t somehow other files in /etc/sudoers.d that could have competing entries.

Perhaps someone more familiar with sudoer issues will comment, but you may have to become that sudoer expert, coming to understand it well enough to diagnose and debug.

I just added web ALL=(root) NOPASSWD: /usr/sbin/service php7.0-fpm * directly to the visudo file and deploying worked. Not sure why the host is ignoring the web-services file.

Proper fix, noted here for prosperity :smiley:

My /etc/sudoers was missing this line:

#includedir /etc/sudoers.d

Make sure there’s no space between # and includedir otherwise it will be treated like a comment.

Also ensure files in /etc/sudoers.d/ have the permissions 0440.


i had some similar issues, deploy failed after trellis update

Sorry, user web is not allowed to execute '/usr/sbin/service php7.1-fpm
reload' as root on servername.
fatal: [xxx.xx.xx.x]: FAILED! => {"changed": true, "cmd": "sudo service php7.1-fpm reload", "delta": "0:00:00.035018", "end": "2017-06-01 14:40:51.216976", "failed": true, "rc": 1, "start": "2017-06-01 14:40:51.181958", "stderr": "Sorry, user web is not allowed to execute '/usr/sbin/service php7.1-fpm reload' as root on servername.", "stdout": "", "stdout_lines": [], "warnings": []}

If you are getting the above error when updating to php 7.1 from 7.0, make sure you update the group_vars/all/users.yml

change the last line to

- "/usr/sbin/service php7.1-fpm *" from - "/usr/sbin/service php7.0-fpm *" and provision the remote server again, then deploy :slight_smile:


Hello mate I have been facing the same issues and turn to various forums but didn’t got any satisfying answer. Instead of trying it again and again I launch DigitalOcean WordPress on managed platform which eventually help me solve this issues. Cheers

Same here. No fix as of yet either

If you’re getting this error after updating Trellis, SSH into your server and check sudo service --status-all, you may have two versions of php-fpm installed. Disable both and try provisioning and deploying again.


Nope, only one php7.1-fpm running

System info:
Ansible; Linux
Trellis at “Fix failed_when in template_root check with wp-cli 1.5.0”

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/tackettz/.ssh/config
debug1: /home/tackettz/.ssh/config line 1: Applying options for *
debug1: /home/tackettz/.ssh/config line 17: Applying options for www-test
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: auto-mux: Trying existing master
debug2: fd 3 setting O_NONBLOCK
debug2: mux_client_hello_exchange: master version 4
debug3: mux_client_forwards: request forwardings: 0 local, 0 remote
debug3: mux_client_request_session: entering
debug3: mux_client_request_alive: entering
debug3: mux_client_request_alive: done pid = 11127
debug3: mux_client_request_session: session request sent
debug1: mux_client_request_session: master session id: 2
debug3: mux_client_read_packet: read header failed: Broken pipe
debug2: Received exit status from master 0
Shared connection to lib-web-lp001.mgt.private closed.

[sudo] password for tackettz:

{“changed”: true, “end”: “2018-02-15 14:27:04.711012”, “stdout”: “”, “cmd”:
“sudo service php7.1-fpm reload”, “failed”: true, “delta”: “0:05:00.289022”,
“stderr”: “”, “rc”: 1, “invocation”: {“module_args”: {“warn”: false,
“executable”: null, “_uses_shell”: true, “_raw_params”: “sudo service
php7.1-fpm reload”, “removes”: null, “creates”: null, “chdir”: null, “stdin”:
null}}, “start”: “2018-02-15 14:22:04.421990”, “msg”: “non-zero return code”}

fatal: [www-test]: FAILED! => {
“changed”: false,
“failed”: true,
“rc”: 0
to retry, use: --limit @/home/tackettz/environments/trellis-rc2/deploy.retry

PLAY RECAP *************************************************************************************************************************************************************************************************
localhost : ok=0 changed=0 unreachable=0 failed=0
www-test : ok=38 changed=15 unreachable=0 failed=1

That is the error I am getting when trying to deploy

Oh you just saved my butt, @Simeon.

Is this a worthy bug fix to Trellis, to stop previously running versions of php-fpm when provisioning? This happened to me when jumping from php-fpm7.0 to php-fpm7.2.

1 Like

I think the latest version of Trellis checks if 7.1 is running…

1 Like

Yeah. The times I’ve run into this error have been when I’ve updated Trellis and not the server, and they disagree on which version of PHP to check/reload.

We never did this before, but yeah the update to 7.2 specifically checks for existing 7.1 and deals with it. But that’s only for going from 7.1 -> 7.2

Got the same error with timeouts on service php7.4-fpm reload or restart.

My problem wasn’t the sudoers file, but the wrong user for that command inside the playbook.

  • playbook had a become_user: www-data

  • task failed

  • added become_user: deploy-bot to task (replace with your management user)

  • task run successfully