背景
最近公司项目在进行架构升级，硬件环境也由原来的AIX迁移到了Linux，硬件环境的不同也导致了较多问题。其中之一就是，crontab调用脚本监控系统运行情况，然而用户执行脚本与crontab执行产生了一定的差异。
排查
- 首先，脚本内容并没有太大改动，仅仅是将一些变量取值的写法更新的更为准确。
- 其次，脚本中的第三方命令均使用全路径引用，不存在找不到命令的问题。
- 然后，我又比对了crontab与手工执行脚本的运行日志。crontab运行日志的时间戳全部为数字与英文结合，而手工执行的运行日志中的时间戳则是数字与汉字相结合；crontab的运行日志显示连接数据库查询数据失败了，而手工执行的运行日志则显示一切正常。
经过排查，结果显而易见，crontab执行脚本时缺少用户手工执行脚本时的一些环境变量。用户在登录服务器时，会默认加载当前用户的环境变量（用户环境变量的配置以及加载不在此做过多赘述）。而crontab就不一定了，以老的AIX环境为例，crontab是会拥有当前用户的环境变量的，这也是为什么之前都是正常运行的；而新的Linux环境，明显就是必须要显示地引入当前用户的环境变量，否则会出现一系列问题。
实际上，一开始我是不建议将当前用户的所有环境变量都引入的，毕竟权限大了，谁也控制不住。我的想法是引入部分必要的环境变量就好，其他的环境变量，要用时再说。但是作为一名开发人员，我对Linux运维这块并不是过多了解，于是就找了公司里相关的运维老师。然而，在重试多次后，那位运维老师直接将当前用户的所有环境变量都引入了，简单粗暴。然后我就在嘀咕“问题原因我早就找到了，我只是想要一个最优解，然而你却把我最初的想法告诉了我，那我岂不是舍近求远？？？”。最后在项目组成员都本着“能正常运行就行”的基本原则，还是采用了全量引入当前用户环境变量的方法。
解决
有两种引入方式：
1.在crontab中引用当前用户环境变量
# 在引入环境变量的同时，也可以指定脚本的解释器
20 03 * * * (. /etc/profile;/bin/sh /var/test.sh)
20 03 * * * (. ~/.profile;/bin/sh /var/test.sh)
2.在脚本中引用当前用户环境变量
source /etc/profile
