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
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,
/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
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.
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