Just like the topic says. I configured my ssh to the staging server, uncommented subtree: site in the group_vars/staging file. But when it gets to
TASK: [deploy | Run post_finalize_commands] *****************************
It has the wp eval 'wp_clean_themes_cache(); command on the screen forever. So far I’ve let it sit there for 30 minutes and nothing has happened. What might I be missing?
Hi @nbyloff. Any chance you’ve set hhvm: true?
If you are using hhvm, you might need mysqlnd to facilitate wp-cli’s work with the database. See this for adding mysqlnd to your provisioning with hhvm.
If you have the default hhvm: false , could you ssh in to your server, cd to /srv/www/example.com/current and run the wp eval to see if it works, or maybe gives error info?
wp eval 'wp_clean_themes_cache();'
… and maybe…
wp eval 'wp_clean_themes_cache();' --debug
As a side note, if there were any hiccups while provisioning staging (via server.yml), you might destroy and recreate the VPS with one full/clean run of server.yml, then try the deploy again.
Thanks for the reply. I checked group_vars/all and it’s set to hhvm: false. I just ssh’d into the remote box and running those two eval commands shows nothing on the command line, it just immediately returns. wp --version returns WP-CLI 0.19.2.
On this server, I didn’t provision anything though. The server was already setup and I am just trying the deploy.sh staging example.com command. I would think this is OK, but maybe not?
As you suggested, if I can run the commands on the actual box as the user I am ssh’ing with, then it should work in Ansible.
I am very new to Ansible and Trellis, but I was using Roots & Grunt before trying to migrate over to the new Trellis setup.
It would depend on the setup, I guess. Feel free to share details about the server setup. If the deploy.yml playbook is running successfully till that final “Run post_finalize_commands” task, normally I would have thought that was a good sign that your server setup would probably work. However, at this point that seems to be the primary difference from the Trellis default, so I’d have to predict that we’ll discover it is the cause of the issue.
The wp_clean_themes_cache(); isn’t absolutely essential, so if you need to postpone debugging at some point, you could comment out the command here and after each deploy immediately visit wp-admin (and maybe re-activate theme?) to avoid a WSOD (details at roots/trellis#275).
You tried while connected as the user named web, I presume? This is the default for web_user used by deploy.yml. Even if you manually connect as web, Ansible’s connection is still slightly different than a manual ssh connection. Here’s a way to replicate it more closely (Ansible ad hoc command):
# run this in your trellis directory on local machine
ansible staging -m shell -a "cd /srv/www/example.com/current && wp eval 'wp_clean_themes_cache();' --debug" -i hosts/staging -u web -vvvv
I’d be surprised if that succeeds (gives output like success | rc=0) if the wp eval is failing via deploy.yml. Hopefully with the verbose -vvvv flag at the end it will give offer helpful debug info. You can also make the deploy.yml output more verbose with this command:
ansible-playbook deploy.yml -i hosts/staging -e "site=example.com" -vvvv
I am closer to figuring it out. Thanks for showing me how to run the debug command. It appears it isn’t the wp_clean_themes_cache() that is the problem. With the debug switch on, it shows the last REMOTE_MODULE that is executed is the sudo service php5-fpm reload command. That’s where it seems to be hanging.
At first I didn’t have a passwordless access to execute this command, but I switched that in visudo. I tested this on the remote server and was able to execute sudo service php5-fpm reload successfully without a password. However through ansible, it appears to hang. I run ps -ef|grep php on the remote machine, and it seems to send the command just fine, but it hangs.
This is that output on the remote machine when it hangs. Any thoughts why this command doesn’t seem to be working?
web@web-1:~$ ps -ef|grep php
www-data 13841 1 0 Sep18 ? 00:00:19 php-fpm: pool www
www-data 13842 1 0 Sep18 ? 00:00:19 php-fpm: pool www
www-data 14060 1 0 01:43 ? 00:00:16 php-fpm: pool www
web 17651 17650 0 16:20 pts/1 00:00:00 /bin/sh -c sudo service php5-fpm reload
root 17652 17651 0 16:20 pts/1 00:00:00 sudo service php5-fpm reload
web 17772 14994 0 16:23 pts/0 00:00:00 grep --color=auto php
I also tried using the switch --ask-sudo-password and when run the command, it asked for my password, but still when it gets to that sudo service php5-fpm reload command, it hangs.
I’ll also add, I just commented out that like for the php5-fpm reload, and ran it again, and the process finished successfully.
Ansible 1.9.3 installed on my vagrant machine.
Actually, just noticed when I log out of the shell and back in, it’s still asking me for a password. Duh! I must have not setup the passwordless sudo up correctly. Thank you so much for your help in getting me here!
I’ll report back if I have any other issues.
I’m a bit at a loss. I’m not super familiar with the sudoers stuff.
In the past when I’ve tested user connections and group memberships, I’ve noticed a strange phenomenon that a user’s new group assignments don’t seem to take effect till after 5-ish minutes of my Ansible ssh connection terminated. Changes were immediate in tests via manual ssh connection, but not for commands run via Ansible. Maybe there’s a similar thing messing with your tests. If your context permits it, you might try rebooting the server and testing again. Presumably the passwordless sudo will be in effect after the whole system reloads.
If you end up leaving the reload command commented out, you’ll probably want to ssh in and run it manually after each deploy. My memory isn’t fresh on what it prevents, but probably the possibility for WSOD or “Bad Gateway” error after deploy.
You could see if somehow the ad hoc version of the reload gives any info:
ansible staging -m shell -a "sudo service php5-fpm reload" -i hosts/staging -u web -vvvv
For anyone else, even though this isn’t related really to Trellis. I had this in my sudoers file under visudo
web ALL=NOPASSWD: /usr/sbin/service php5-fpm reload
That is supposed to allow that user to only execute the above command without a password. However, since this is a test server, I was screwing around and my web user was also in the sudo group. Because of this, this setting later in the sudoers file was overriding my passwordless command
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
My solution was to add my new rule in an override folder outside the main sudoers file like so. And now everything works
sudo visudo -f /etc/sudoers.d/myOverrides