1、背景
前几天新同学入职，一不小心将跳板机上的 crontab 清空了，导致凌晨一大批任务异常，同事问了运维同学也没有备份，这一百多个任务要是恢复起来可不是件容易的事儿。还好我去年某天开始做了定时备份，每分钟一次 backup 到本地磁盘，最后很容易的将 crontab 给恢复了。
这件事情过后我也在想，一台跳板机整个部门都共用一个账号， Linux 水平和安全意识又参差不齐，其实很难避免以后还会误操作，比如一下子将 home 目录全干掉。所以我想 backup 最好不要保存在本地，于是想一条命令将其备份到 hadoop 集群上去。
2、问题
当时觉得这个问题很简单，于是随手写了一条类似这样的命令：
*/1 * * * * /bin/cat > /root/a.log 2>&1
本地测试了没问题，但是 crontab 怎么都不成功，也看不到错误日志，a.log 一直是空的。
这个我就比较好奇了，按理说 a.log 应该是能拿到所有的标准输出和标准错误的，究竟什么原因导致 crontab 既不执行又不报错呢？
3、分析
debug 终极大法还是得看日志，本 case 最让人疑惑的在于没有日志，如果能找到日志所有的迷雾应该都能烟消云散。
于是，我尝试看看 /var/log 下有没有 crontab 的执行日志，看了下服务器居然没开启 cron.log，由于非管理员没权限修改任何配置或设置，于是我在本地 WSL 里用 Ubuntu 把问题复现了下。
3.1 开启 cron.log
sudo vim /etc/rsyslog.d/50-default.confcron.* /var/log/cron.log #将cron前面的注释符去掉#重启rsyslog#sudo /etc/init.d/rsyslog restartsudo service rsyslog restartsudo service cron restart
虽然能看到 crontab 执行日志了，但全都是一些没意义的日志或 info 提示：
Mar 31 20:58:20 Surface-Pro5 crontab[223]: (root) BEGIN EDIT (root)Mar 31 20:58:53 Surface-Pro5 crontab[223]: (root) REPLACE (root)Mar 31 20:58:53 Surface-Pro5 crontab[223]: (root) END EDIT (root)...Mar 31 21:13:01 Surface-Pro5 CRON[451]: (CRON) info (No MTA installed, discarding output)Mar 31 21:14:01 Surface-Pro5 CRON[471]: (CRON) info (No MTA installed, discarding output)...
仔细观察日志发现貌似在提示我们 MTA 没装，crontab 输出被丢弃了。同时查看 sudo tail -f /var/mail/
3.2 安装 postfix
由于 crontab 通知机制是将错误会以邮件形式发给所属登录账号或者系统管理员，如果没有安装邮件管理服务，那么这部分信息会被系统丢弃。那咱们安装 postfix 即可：
sudo apt-get install postfixsudo service postfix start
再次查看日志发现了报错日志：
1 From [email protected] Sat Mar 31 21:33:38 2018 2 Return-Path:3 X-Original-To: root 4 Delivered-To: [email protected] 5 Received: by Surface-Pro5.localdomain (Postfix, from userid 0) 6 id CCE42300000000E229; Sat, 31 Mar 2018 21:25:02 +0800 (DST) 7 From: [email protected] (Cron Daemon) 8 To: [email protected] 9 Subject: Cron /bin/ls > /root/a.log 2>&110 MIME-Version: 1.011 Content-Type: text/plain; charset=UTF-812 Content-Transfer-Encoding: 8bit 13 X-Cron-Env: 14 X-Cron-Env: 15 X-Cron-Env: 16 X-Cron-Env: 17 Message-Id: <[email protected]> 18 Date: Sat, 31 Mar 2018 21:25:02 +0800 (DST) 1920 /bin/sh: 1: Syntax error: "(" unexpected
3.3 如何修复
看到邮件里的错误提示咱们立马就能明白 crontab 之所以无法执行，是因为 crontab 环境变量默认加载的是 sh，而非 bash，不支持进程代换这种语法，咱们有两种办法避免：
3.3.1 crontab 开头指定 shell 类型
完整的 crontab 格式如下：
SHELL=/bin/bashPATH=/sbin:/bin:/usr/sbin:/usr/binMAILTO=rootHOME=/# .---------------- minute (0 - 59) # | .------------- hour (0 - 23)# | | .---------- day of month (1 - 31)# | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | |# * * * * * command to be executed
也就是说，咱们可以在 crontab 文件的开头指定 shell 类型这样就不会有问题了。
3.3.2 封装成脚本
其实不建议在 crontab 里执行复杂逻辑，最好封装成脚本，这样好控制，比如：
*/1 * * * * bash a.sh >> /root/a.log 2>&1
3.4 重定向无法获取错误的原因
虽然咱们根据错误日志知道怎样修改让命令正常执行，但是我们并未回答文章开头的疑问：究竟为何 2>&1 无法重定向拿到所有的标准输出和标准错误？有点违反常理了。这个还和 shell 解释器类型无关，比如下面这条命令，在 bash 下也是只能拿到标准输出，无法拿到标准错误：
ls debuglog/a.log 2>&1
这个问题的深层次原因得追溯到 shell 的一个概念：子进程
其实上图中的命令这样改也行：
ls > debuglog/b.log 2>&1) >> debuglog/a.log 2>&1
因为 debuglog/a.log 2>&1 只能拿到当前进程的标准输出与标准错误。
另外需要注意的是通过()或管道fork出来的子进程，继承了父进程的所有环境变量，和平时bash xxx.sh或者./xxx.sh起的不同的, 而$$是一起继承的，但$BASHPID继承后重新赋值了，这和新开个bash的方式是不同的。
除了上面的写法，如果要深究茴字还有几种写法，那么还有如下两种写法：
bash a.sh > debuglog/a.log 2>&1bash -c "ls debuglog/a.log 2>&1
至此，从文章开头的问题，咱们从如何让日志输出以及代码如何改写，到最后的 root cause 都分析了一遍，希望能对大家有所启发和参考。
閱讀更多 燈塔大數據 的文章
