crontab如果不注意的话早晚会出问题，而且这种问题一旦出一次，就会永远记得，因为这种问题很折腾人。
——某前辈
设置了一个crontab
30 0 * * * cd /home/work/user/huangbx/research/getfeature/data/current; sh resample.sh &>/dev/null
$sh resample.sh是可以运行的
$head -5 resample.sh
##对事实数据进行采样
set -x
g_date=`date -d "3 days ago " +%Y%m%d`
可是放到crontab里面就无法运行了。
从网上了解到一般crontab无法运行的问题都是由环境变量在crontab中不一定可识别引起的。可是resample.sh中并没有涉及环境变量的使用。
经过多番尝试，终于发现是代码的第一行的中文注释引起的问题，添加上#!/bin/sh后就可以运行了。
总结了一下：
crontab中必须十分注意环境变量的使用
#!/bin/sh并不是必须，只是当没有sha-bang的时候，也不要在第一行有"#"后带的中文注释！！
最好当然是加上sha-bang啦 #!/bin/sh
2008-11-3补充：
之前没有特别注意环境变量引起的crontab失败，今天果然就遇到了。
问题描述：cron了某sh文件，里面执行多个操作，既调用了外部的shell脚本，也调用了外部的python脚本。从运行日志看，发现部分脚本被调用，而部分python脚本没有被调用。没有被调用的均是python脚本，而且均使用了MySQLdb模块（第三方模块）。
该脚本在平时直接使用sh命令均可以正常执行。
出错信息：
Traceback (most recent call last):
File "areafile.py", line 2, in <module>
import MySQLdb
File "build/bdist.linux-x86_64/egg/MySQLdb/__init__.py", line 19, in <module>
File "build/bdist.linux-x86_64/egg/_mysql.py", line 7, in <module>
File "build/bdist.linux-x86_64/egg/_mysql.py", line 6, in __bootstrap__
ImportError: libmysqlclient.so.15: cannot open shared object file: No such file or directory
MySQLdb需要调用mysql这个库，可是系统并不知道你的mysql安装在哪里 : (
问题解决：
在总控的shell脚本中添加一句话
export LD_LIBRARY_PATH=/home/work/local/mysql5/lib/mysql
（也就是来自~/.bash_profile中的LD_LIBRARY_PATH字段）后程序终于可以在crontab中正常启动。
解释：
1) ~/.bash_profile && ~/.bashrc
用户登陆Linux操作系统的时候，"/etc/profile", "~/.bash_profile"等配置文件会被自动执行。执行过程是这样的：登陆Linux系统时，首先启动"/etc/profile"，然后启动用户目录下的"~/.bash_profile"，如果"~/.bash_login"和"~/.profile"文件存在的时候也会在执行"~/.bash_profile"后被依次调用。
下面看看"~/.bash_profile"文件里面有什么东西
$cat ~/.bash_profile
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin:/home/work/local/python/lib/python2.5/site-packages/django/bin/:$HOME/bin:/home/work/local/mysql5/bin/;
LD_LIBRARY_PATH=/home/work/local/mysql5/lib/mysql
alias py='/home/work/local/python/bin/python'
export PATH LD_LIBRARY_PATH
unset USERNAME
可以看到~/.bash_profile文件先调用~/.bashrc，然后再把PATH和LD_LIBRARY_PATH加载。
.bash_profile和.bashrc的差别
/etc/profile:此文件为系统的每个用户设置环境信息,当用户第一次登录时,该文件被执行.
并从/etc/profile.d目录的设置文件中搜集shell的设置.
/etc/bashrc:为每一个运行bash shell的用户执行此文件.当bash shell被打开时,该文件被读取.
~/.bash_profile:每个用户都可使用该文件输入专用于自己使用的shell信息,当用户登录时,该
文件仅仅执行一次!默认情况下,他设置一些环境变量,执行用户的.bashrc文件.
~/.bashrc:该文件包含专用于你的bash shell的bash信息,当登录时及每次打开新的shell时,该
该文件被读取.
~/.bash_logout:当每次退出系统(退出bash shell)时,执行该文件.
/etc/profile是全局性的功能，其中设置的变量作用于所有用户，~/.bash_profile中设置的变量能继承/etc/profile中的变量并作用于用户。
~/.bash_profile 是交互式、login 方式进入 bash 运行的
~/.bashrc 是交互式 non-login 方式进入 bash 运行的
通常二者设置大致相同，所以通常前者会调用后者。(http://blog.chinaunix.net/u2/63775/showart_527708.html )
可是在运行crontab的时候，是non_login方式调用程序的，此时~/.bash_profile并不会被提前调用。所以，crontab的运行环境相对于login方式进入bash运行的环境来说小得多。如果程序涉及~/.bash_profile使用的环境变量，那么，部分在login方式可以正常运行的程序在crontab下就无法运行。
在我的程序中，系统无法识别MySQLdb，于是解决方案就是在总控的shell脚本中添加这样一句：
export LD_LIBRARY_PATH=/home/work/local/mysql5/lib/mysql
更加推荐的解决方案：
在cron中加入
LD_LIBRARY_PATH=/home/work/local/mysql5/lib/mysql
这样cron中所有使用mysql的东东都可以顺利运行了 : ) 而且这样可以使得操作更加清晰。
终极推荐解决方案：
30 12 * * * source ~/.bashrc && cd /home/work/mydir && ./myproj
2) LD_LIBRARY_PATH
Linux运行时有一套共享库(*.so)。共享库的寻找和加载是通过/lib/ld.so (RunTime Shared Library Loader)完成的。ld.so在标准路径(/lib, /usr/lib)下寻找共享库。可是如果第三方库并非安装在标准路径下，程序运行的时候就会出现无法找到库的错误，类似于下面这个报错
ld.so.1: curl: fatal: libgcc_s.so.1: open failed: No such file or directory
通过设置环境变量LD_LIBRARY_PATH可以让ld.so寻找非标准路径的共享库。LD_LIBRARY_PATH中可以设置多个路径，路径之间通过冒号":"分割。LD_LIBRARY_PATH中的路径先于标准路径的查找。
在~/.bash_profile中添加如下代码（比如把mysql的so文件添加进LD_LIBRARY_PATH）
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/work/local/mysql5/lib/mysql
export LD_LIBRARY_PATH
由于~/.bash_profile在用户登陆时会加载（而且仅加载）一次，然后ld.so就会在标准路径和LD_LIBRARY_PATH中自动寻找和加载共享库。
LD_LIBRARY_PATH的缺点：（参考http://xahlee.org/UnixResource_dir/_/ldpath.html）
"For security reasons, LD_LIBRARY_PATH is ignored at runtime for executables that have their setuid or setgid bit set. This severely limits the usefulness of LD_LIBRARY_PATH." ... .... ....."LD_LIBRARY_PATH is one of those insidious things that once it gets set globally for a user, things tend to happen which cause people to rely on it being set. Eventually when LD_LIBRARY_PATH needs to be changed or removed, mass breakage will occur!" ... ... ......"Nowadays you specify the run-time path for an executable at link stage with the -R (or sometimes -rpath) flag to ld. There's also LD_RUN_PATH which is an environment variable which acts to ld just like specifying -R. Before all this you had only -L, which applied not only during compile-time, but during run time as well. There was no way to say “use this directory during compile time” but “use this other directory at run time”. There were some rather spectacular failure modes that one could get in to because of this. "
文中同时给出了如何合理使用LD_LIBRARY_PATH：（虽然没有完全看懂，还是贴一下，期待不久的将来能看懂）
1) Never ever set LD_LIBRARY_PATH globally.
If you must ship binaries that use shared libraries and want to allow your clients to install the program outside a 'standard' location, do one of the following:
Ship your binaries as .o files, and as part of the install process relink them with the correct installation library path.
Ship executables with a very long “dummy” run-time library path, and as part of the install process use a binary editor to substitute the correct install library path in the executable.
2) If you are forced to set LD_LIBRARY_PATH, do so only as part of a wrapper.
3). Remove the link-time aspect of LD_LIBRARY_PATH.....It would be much cleaner if LD_LIBRARY_PATH only had influence at run-time. If necessary, invent some other environment variable for the job (LD_LINK_PATH).
3) ld.so.conf
除了设置LD_LIBRARY_PATH外，还可以设置/etc/ld.so.conf。然后运行ldconfig生成ld.so.cache。ld.so查找公共库的时候也会从ld.so.cache中查找。
不过http://xahlee.org/UnixResource_dir/_/ldpath.html还是猛烈批判了ld.so.conf的设置。
"Some OS's (e.g. Linux) have a configurable loader. You can configure what run-time paths to look in by modifying /etc/ld.so.conf. This is almost as bad a LD_LIBRARY_PATH! Install scripts should never modify this file! This file should contain only the standard library locations as shipped with the OS. "
LD_LIBRARY_PATH的runtime Linker详细行为可以参考http://docs.sun.com/app/docs/doc/819-0690/chapter6-63352?a=view
转自：http://hi.baidu.com/huangboxiang/blog/item/f798a7dc3eb096e877c63833.html
大家都知道crontab是个好东东，可以定时执行一些任务，帮助你监控系统状况，帮助你每天重复的做一些机械的事情。但是crontab有一个坏毛病，就是它总是不会缺省的从用户profile文件中读取环境变量参数，经常导致在手工执行某个脚本时是成功的，但是到crontab中试图让它定期执行时就是会出错
原先我用一个很傻的办法，就是在脚本中直接指定所有的环境变量参数，每次写脚本都要写好多好多PATH啦，LD_LIBRARY_PATH之类的环境变量参数
后来发现其实可以直接在脚本里先执行一下用户的profile文件，就OK了
如果是Linux环境下的脚本，脚本的头上用缺省的#!/bin/sh就可以了，如果是Solaris环境下的脚本，脚本头上用#!/bin/ksh
然后第一个部分先写这些：
###################
. /etc/profile
. ~/.bash_profile
##################
这样，crontab在执行脚本的时候，就能够读到用户的环境变量参数啦。。。一点儿小技巧而已 ^_^
附：
如果你是在cron里提交的,请注意:
不要假定c r o n知道所需要的特殊环境，它其实并不知道。所以你要保证在s h e l l脚本中提供所有必要的路径和环境变量，除了一些自动设置的全局变量。
如果c r o n不能运行相应的脚本，用户将会收到一个邮件说明其中的原因。
——某前辈
设置了一个crontab
30 0 * * * cd /home/work/user/huangbx/research/getfeature/data/current; sh resample.sh &>/dev/null
$sh resample.sh是可以运行的
$head -5 resample.sh
##对事实数据进行采样
set -x
g_date=`date -d "3 days ago " +%Y%m%d`
可是放到crontab里面就无法运行了。
从网上了解到一般crontab无法运行的问题都是由环境变量在crontab中不一定可识别引起的。可是resample.sh中并没有涉及环境变量的使用。
经过多番尝试，终于发现是代码的第一行的中文注释引起的问题，添加上#!/bin/sh后就可以运行了。
总结了一下：
crontab中必须十分注意环境变量的使用
#!/bin/sh并不是必须，只是当没有sha-bang的时候，也不要在第一行有"#"后带的中文注释！！
最好当然是加上sha-bang啦 #!/bin/sh
2008-11-3补充：
之前没有特别注意环境变量引起的crontab失败，今天果然就遇到了。
问题描述：cron了某sh文件，里面执行多个操作，既调用了外部的shell脚本，也调用了外部的python脚本。从运行日志看，发现部分脚本被调用，而部分python脚本没有被调用。没有被调用的均是python脚本，而且均使用了MySQLdb模块（第三方模块）。
该脚本在平时直接使用sh命令均可以正常执行。
出错信息：
Traceback (most recent call last):
File "areafile.py", line 2, in <module>
import MySQLdb
File "build/bdist.linux-x86_64/egg/MySQLdb/__init__.py", line 19, in <module>
File "build/bdist.linux-x86_64/egg/_mysql.py", line 7, in <module>
File "build/bdist.linux-x86_64/egg/_mysql.py", line 6, in __bootstrap__
ImportError: libmysqlclient.so.15: cannot open shared object file: No such file or directory
MySQLdb需要调用mysql这个库，可是系统并不知道你的mysql安装在哪里 : (
问题解决：
在总控的shell脚本中添加一句话
export LD_LIBRARY_PATH=/home/work/local/mysql5/lib/mysql
（也就是来自~/.bash_profile中的LD_LIBRARY_PATH字段）后程序终于可以在crontab中正常启动。
解释：
1) ~/.bash_profile && ~/.bashrc
用户登陆Linux操作系统的时候，"/etc/profile", "~/.bash_profile"等配置文件会被自动执行。执行过程是这样的：登陆Linux系统时，首先启动"/etc/profile"，然后启动用户目录下的"~/.bash_profile"，如果"~/.bash_login"和"~/.profile"文件存在的时候也会在执行"~/.bash_profile"后被依次调用。
下面看看"~/.bash_profile"文件里面有什么东西
$cat ~/.bash_profile
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin:/home/work/local/python/lib/python2.5/site-packages/django/bin/:$HOME/bin:/home/work/local/mysql5/bin/;
LD_LIBRARY_PATH=/home/work/local/mysql5/lib/mysql
alias py='/home/work/local/python/bin/python'
export PATH LD_LIBRARY_PATH
unset USERNAME
可以看到~/.bash_profile文件先调用~/.bashrc，然后再把PATH和LD_LIBRARY_PATH加载。
.bash_profile和.bashrc的差别
/etc/profile:此文件为系统的每个用户设置环境信息,当用户第一次登录时,该文件被执行.
并从/etc/profile.d目录的设置文件中搜集shell的设置.
/etc/bashrc:为每一个运行bash shell的用户执行此文件.当bash shell被打开时,该文件被读取.
~/.bash_profile:每个用户都可使用该文件输入专用于自己使用的shell信息,当用户登录时,该
文件仅仅执行一次!默认情况下,他设置一些环境变量,执行用户的.bashrc文件.
~/.bashrc:该文件包含专用于你的bash shell的bash信息,当登录时及每次打开新的shell时,该
该文件被读取.
~/.bash_logout:当每次退出系统(退出bash shell)时,执行该文件.
/etc/profile是全局性的功能，其中设置的变量作用于所有用户，~/.bash_profile中设置的变量能继承/etc/profile中的变量并作用于用户。
~/.bash_profile 是交互式、login 方式进入 bash 运行的
~/.bashrc 是交互式 non-login 方式进入 bash 运行的
通常二者设置大致相同，所以通常前者会调用后者。(http://blog.chinaunix.net/u2/63775/showart_527708.html )
可是在运行crontab的时候，是non_login方式调用程序的，此时~/.bash_profile并不会被提前调用。所以，crontab的运行环境相对于login方式进入bash运行的环境来说小得多。如果程序涉及~/.bash_profile使用的环境变量，那么，部分在login方式可以正常运行的程序在crontab下就无法运行。
在我的程序中，系统无法识别MySQLdb，于是解决方案就是在总控的shell脚本中添加这样一句：
export LD_LIBRARY_PATH=/home/work/local/mysql5/lib/mysql
更加推荐的解决方案：
在cron中加入
LD_LIBRARY_PATH=/home/work/local/mysql5/lib/mysql
这样cron中所有使用mysql的东东都可以顺利运行了 : ) 而且这样可以使得操作更加清晰。
终极推荐解决方案：
30 12 * * * source ~/.bashrc && cd /home/work/mydir && ./myproj
2) LD_LIBRARY_PATH
Linux运行时有一套共享库(*.so)。共享库的寻找和加载是通过/lib/ld.so (RunTime Shared Library Loader)完成的。ld.so在标准路径(/lib, /usr/lib)下寻找共享库。可是如果第三方库并非安装在标准路径下，程序运行的时候就会出现无法找到库的错误，类似于下面这个报错
ld.so.1: curl: fatal: libgcc_s.so.1: open failed: No such file or directory
通过设置环境变量LD_LIBRARY_PATH可以让ld.so寻找非标准路径的共享库。LD_LIBRARY_PATH中可以设置多个路径，路径之间通过冒号":"分割。LD_LIBRARY_PATH中的路径先于标准路径的查找。
在~/.bash_profile中添加如下代码（比如把mysql的so文件添加进LD_LIBRARY_PATH）
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/work/local/mysql5/lib/mysql
export LD_LIBRARY_PATH
由于~/.bash_profile在用户登陆时会加载（而且仅加载）一次，然后ld.so就会在标准路径和LD_LIBRARY_PATH中自动寻找和加载共享库。
LD_LIBRARY_PATH的缺点：（参考http://xahlee.org/UnixResource_dir/_/ldpath.html）
"For security reasons, LD_LIBRARY_PATH is ignored at runtime for executables that have their setuid or setgid bit set. This severely limits the usefulness of LD_LIBRARY_PATH." ... .... ....."LD_LIBRARY_PATH is one of those insidious things that once it gets set globally for a user, things tend to happen which cause people to rely on it being set. Eventually when LD_LIBRARY_PATH needs to be changed or removed, mass breakage will occur!" ... ... ......"Nowadays you specify the run-time path for an executable at link stage with the -R (or sometimes -rpath) flag to ld. There's also LD_RUN_PATH which is an environment variable which acts to ld just like specifying -R. Before all this you had only -L, which applied not only during compile-time, but during run time as well. There was no way to say “use this directory during compile time” but “use this other directory at run time”. There were some rather spectacular failure modes that one could get in to because of this. "
文中同时给出了如何合理使用LD_LIBRARY_PATH：（虽然没有完全看懂，还是贴一下，期待不久的将来能看懂）
1) Never ever set LD_LIBRARY_PATH globally.
If you must ship binaries that use shared libraries and want to allow your clients to install the program outside a 'standard' location, do one of the following:
Ship your binaries as .o files, and as part of the install process relink them with the correct installation library path.
Ship executables with a very long “dummy” run-time library path, and as part of the install process use a binary editor to substitute the correct install library path in the executable.
2) If you are forced to set LD_LIBRARY_PATH, do so only as part of a wrapper.
3). Remove the link-time aspect of LD_LIBRARY_PATH.....It would be much cleaner if LD_LIBRARY_PATH only had influence at run-time. If necessary, invent some other environment variable for the job (LD_LINK_PATH).
3) ld.so.conf
除了设置LD_LIBRARY_PATH外，还可以设置/etc/ld.so.conf。然后运行ldconfig生成ld.so.cache。ld.so查找公共库的时候也会从ld.so.cache中查找。
不过http://xahlee.org/UnixResource_dir/_/ldpath.html还是猛烈批判了ld.so.conf的设置。
"Some OS's (e.g. Linux) have a configurable loader. You can configure what run-time paths to look in by modifying /etc/ld.so.conf. This is almost as bad a LD_LIBRARY_PATH! Install scripts should never modify this file! This file should contain only the standard library locations as shipped with the OS. "
LD_LIBRARY_PATH的runtime Linker详细行为可以参考http://docs.sun.com/app/docs/doc/819-0690/chapter6-63352?a=view
转自：http://hi.baidu.com/huangboxiang/blog/item/f798a7dc3eb096e877c63833.html
大家都知道crontab是个好东东，可以定时执行一些任务，帮助你监控系统状况，帮助你每天重复的做一些机械的事情。但是crontab有一个坏毛病，就是它总是不会缺省的从用户profile文件中读取环境变量参数，经常导致在手工执行某个脚本时是成功的，但是到crontab中试图让它定期执行时就是会出错
原先我用一个很傻的办法，就是在脚本中直接指定所有的环境变量参数，每次写脚本都要写好多好多PATH啦，LD_LIBRARY_PATH之类的环境变量参数
后来发现其实可以直接在脚本里先执行一下用户的profile文件，就OK了
如果是Linux环境下的脚本，脚本的头上用缺省的#!/bin/sh就可以了，如果是Solaris环境下的脚本，脚本头上用#!/bin/ksh
然后第一个部分先写这些：
###################
. /etc/profile
. ~/.bash_profile
##################
这样，crontab在执行脚本的时候，就能够读到用户的环境变量参数啦。。。一点儿小技巧而已 ^_^
附：
如果你是在cron里提交的,请注意:
不要假定c r o n知道所需要的特殊环境，它其实并不知道。所以你要保证在s h e l l脚本中提供所有必要的路径和环境变量，除了一些自动设置的全局变量。
如果c r o n不能运行相应的脚本，用户将会收到一个邮件说明其中的原因。
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/3377/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
PHP生成图文报表
去除Bo-Blog底部版权
问题终于解决了，非常感谢
但排版有些混乱哦，因为想说的东西太多:)