我有一个PHP脚本，我需要每分钟运行一次。我确保脚本在命令行中运行，并且我使用绝对路径来避免任何环境问题：
/usr/bin/php -q /var/www/myapp/services/myservice.php
从命令行以root身份手动运行它可以正常工作，正如我从脚本写入的日志文件中看到的那样。可以肯定的是，该脚本也具有执行权限。
但是，在cron中放置相同的命令时：
* * * * * /usr/bin/php -q /var/www/myapp/services/myservice.php
它没有运行，或者至少看起来如此。我也尝试将输出重定向到另一个日志文件：
* * * * * /usr/bin/php -q /var/www/myapp/services/myservice.php >> /mylog.log 2>&1
仍然没有。我没有任何迹象表明正在运行的脚本。我想它没有，但我不知道还有什么要寻找的。我甚至重新启动了cron守护进程。
我知道StackOverflow上有类似的问题，但没有一个答案对我来说是一个解决方案。这实际上让我发疯，我将非常感谢任何帮助。
答案 0 :(得分：2)
我找到了解决问题的方法：
https://serverfault.com/questions/97828/php-from-command-line-path-problems/97881#97881
事实证明我需要cd（更改目录）到脚本目录然后调用它。令人惊讶的是，因为我使用绝对路径，但它有效。感谢那些花时间回应的人。
答案 1 :(得分：1)
您错过了running user部分：
* * * * * nobody /usr/bin/php -q /var/www/myapp/services/myservice.php >> /mylog.log 2>&1
答案 2 :(得分：1)
将可执行文件从命令行移动到cron作业时，通常需要执行大量操作。
默认情况下，cron作业获得的环境最小，几乎肯定没有登录会话所具有的完整路径（以及许多其他环境变量）。您也可能不在同一目录中（如您所发现的那样）。
我倾向于执行：
env | sed 's/^/export /' >$HOME/cron.env
从登录会话中获取完整环境，然后确保我的cron作业在尝试执行实际工作之前执行该脚本。生成的脚本可能需要进行少量整理（引用，删除瞬态环境变量，如_和PWD等等。）
这样我可以确定登录和cron环境是相同的。
答案 3 :(得分：0)
这可能被视为“不良做法”，但它对我有用。
使用curl
运行它* * * * * curl -s http://www.domain.com/services/myservice.php