cron job执行中碰到的一个问题

项目中需要用coreseek做搜索，涉及到更新索引的问题。

由于时间紧迫，且目前数据量非常少，所以直接使用cron job定时重建索引的方法

我将重建索引的命令写在coreseekUpdate.sh文件中，如下

/usr/local/coreseek/bin/searchd --stop

/usr/local/coreseek/bin/indexer --all

/usr/local/coreseek/bin/searchd

 

然后，给这个文件加权限

sudo chmod a+x coreseekUpdate.sh

 

然后执行这个文件

./coreseekUpdate.sh

执行很成功，索引更新了，服务也起来了。

 

接下去修改crontab

sudo crontab -e

 

*/1 * * * * /home/luke/work/coreseekUpdate.sh

每一分钟执行一次，先测试一下

保存后重启cron

sudo /etc/init.d/cron restart

 

1分钟之后刷新搜索页面，页面卡住了，原来搜索服务没有起来。

尝试了很多种方法，都不行，最后发现网上找到的cron文件中每行后面都有 > /dev/null 2>&1 或者 > /dev/null

搜索后才知道这个是重定向错误输出的。

修改cron命令

*/1 * * * * /home/luke/work/coreseekUpdate.sh > /dev/null

重启cron后，居然成功了。

郁闷了我很长时间的问题居然就这么解决了。

 

以下是关于 > /dev/null 2>&1 的说明

为什么要用 /dev/null 2>&1 这样的写法.

这条命令的意思是将标准输出和错误输出全部重定向到/dev/null中,也就是将产生的所有信息丢弃.下面我就为大家来说一下,

command > file 2>file  与command > file 2>&1 有什么不同的地方.

      首先~command > file 2>file 的意思是将命令所产生的标准输出信息,和错误的输出信息送到file 中.command  > file 2>file 这样的写法,stdout和stderr都直接送到file中, file会被打开两次,这样stdout和stderr会互相覆盖,这样写相当使用了FD1和FD2两个同时去抢占file 的管道.
      而command >file 2>&1 这条命令就将stdout直接送向file, stderr 继承了FD1管道后,再被送往file,此时,file 只被打开了一次,也只使用了一个管道FD1,它包括了stdout和stderr的内容.
      从IO效率上,前一条命令的效率要比后面一条的命令效率要低,所以在编写shell脚本的时候,较多的时候我们会用command > file 2>&1 这样的写法.