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
import MySQLdb
File
"build/bdist.linux-x86_64/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.linux-x86_64/egg/_mysql.py", line 7, in
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的缺点：（参考）
"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中查找。
不过还是猛烈批判了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://hi.baidu.com/huangboxiang/blog/item/f798a7dc3eb096e877c63833.html
