mirrors 再次修复缓存不一致问题

前一段时间发现 mirrors 缓存不一致的报警又开始增多了,发现是从一开始就有的一个 bug:更新 incrontab 的脚本没有在缓存文件列表更新后执行,这是因为主控脚本中用了 ./update-incrontab.sh … 的写法,而 crontab 执行时的当前目录(pwd)并非脚本所在目录,因此这些命令从来就没有成功执行过。由于之前测试时都是在脚本所在目录中执行的,测试并未发现 bug。这样,缓存文件列表中新增的文件就不受 incrontab 监控,需要等整个源同步完成后再删除,因此会出现较长时间的缓存不一致。

解决方法:改成

$(dirname $0)/update-incrontab.sh ...

顺便解决了 syslog 一直写入 /var/log/syslog.1 的问题,现在这个文件已经长到 18G 了。做法很简单(但没人管的话永远也不会被解决):

sudo service rsyslogd rotate

《mirrors 再次修复缓存不一致问题》上有3条评论

  1. 脚本路径的问题,建议不要对调用者进行要求,而是尽量让脚本自己解决。
    一般我的脚本开头都是这样的:

    __script_dir=$(dirname $(readlink -f $(which $0)))
    pushd $__script_dir

    这里:
    * which $0 的目的是得到$0的真实位置,例如某个脚本被软链到$PATH中,调用时没有写路径。
    * $readlink -f xx 的目的是得到脚本的绝对路径。
    * $dirname xxx 的目的是从绝对路径得到脚本所在目录。
    不过这种代码在某些情况下会挂掉,例如bash test.sh,这里test.sh在当前目录下,which test.sh会输出空(which ./test.sh可以正常输出)。

  2. syslog的问题,最好看一看为何之前的rotate失败了。我之前碰到过一些logrotate失败的情况,主要是postrotate脚本挂了,或者其他一些问题,例如我们公司有一段时间线上的nginx打包有问题,提供的logrotate配置文件中写的是create 0640 nginx adm,但是系统里没有nginx这个账户,于是logrotate跑了一般失败了,于是就一直往access.log.1中写东西。

    1. 果然今天没有 rotate 成功,原因是 /etc/init.d/rsyslog 已经不支持 reload 参数,而 /etc/logrotate.d/rsyslog 中写的仍然是 reload,执行失败了。把 reload 改成 rotate 就行了。其实 rotate 就是给 rsyslog daemon 发 SIGHUP,不知道为什么不用 reload 这个通用参数。

评论已关闭。