一个诡异的crontab执行提示1045错误码的MySQL问题定位

问题描述

今天遇到一个诡异的MySQL问题，在命令行手动跑一个脚本可以执行成功，但是放到crontab执行时报下面的错误：

ERROR 1045 (28000): Access denied for user 'vtest'@'localhost' (using password: YES)

太诡异了，同一份代码，不同的执行方式，为什么执行结果会不一样呢。

定位过程一:权限问题

初步定位是用户权限问题，查看了用户权限都有

+-----------+-----------+| HOST      | USER      |+-----------+-----------+| %         | root      || %         | vtest     |+-----------+-----------+

而且在命令行也能连上：

mysql -uvtest -pxxxxType 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql>

定位过程二：网上查找

http://blog.csdn.net/nel0511/article/details/13091163
http://stackoverflow.com/questions/20353402/access-denied-for-user-testlocalhost-using-password-yes-except-root-user

都是说账号权限问题，试了也都不行。

定位过程三：日志定位

没有办法，最后只能通过加log来定位了。现在唯一确定的点是，对于同一份代码，命令行执行是正常的，crontab执行会提示失败，那把连接对象打印输出两者比较
crontab可以重定向输出：

* * * * * php /data/home/test.php >/u01/crontab.log 2>&1

两个对象打印出来仔细比对后发现用户的密码不一样，为什么同一份代码最后连接的密码会不一样呢，结合代码发现，mysql的账号密码是取环境变量值来判断要获取哪个环境的mysql连接配置。
通过crontab执行不会自动加载环境变量，而命令行在登陆时会默认读取了环境变量

解决改进

读取一下环境变量再执行：source /etc/profile;

* * * * * source /etc/profile; php /data/home/test.php >/u01/crontab.log 2>&1

总结

• 问题表象很诡异: 同样一份代码在命令行执行正常，但是到了crontab就提示错误
• 通过网上搜索的原因大多是权限和账号问题，感觉都不太靠谱，如果是账号问题为什么一个能执行成功，一个不行呢，花在账号权限配置和验证上
• 最后通过加日志的方式定位问题，每次验证都得等crontab日志，耗时较久。
• 一开始也感觉是环境变量的问题，但是只是不知道是怎么影响和导致结果的。