Problem with wp-cli and setting up cron in CiviCRM
After much research and getting expert ideas...

(I'm sure this is known to many people here, but I'm posting here to hopefully help others who don't know this.)

TLDR; in Cron jobs, you should fully specify the path to the PHP binary as well as wp-cli.

=======================================

Cron runs in its own minimal environment. It does run as the relevant user, but it does not load most of the user environment info. This post was helpful for me to understand some of this:

https://serverfault.com/questions/337631/crontab-execution-doesnt-have-the-same-environment-variables-as-executing-user

I am running cPanel which does some of its own management of php. The cPanel support people were very helpful in helping me understand more.

What is not obvious is that when you login to a shell, various paths are added, even ones that are NOT in the user's .bash_profile. Cron does not necessarily do the same thing.

One that is added with a shell login is /usr/local/bin/

So typing "which php" in a shell gives /usr/local/bin/php, but in cron it gives /usr/bin/php

In cPanel, or indeed other tools I expect, this contains references to specific php binaries that can change depending on what user you are. 

I don't pretend to understand the underlying mechanism.

But the upshot is that the php command points to a different binary in the shell or via cron.

So in the cron job, you ALSO have to point at the specific php binary with a command like:

/usr/local/bin/php /usr/local/bin/wp --info (etc)


Or even a FULL path to the desired php binary:

/opt/cpanel/ea-php56/root/usr/bin/php /usr/local/bin/wp --info (etc)


In cPanel there is also a known problem when using PHP-FPM for a site where the automatic PHP detection doesn't work, so it falls back to the cPanel PHP default. They are working on fixing that. If this is a problem, then setting the full path to the desired PHP binary will work.