遇到一个Linux系统时间突变问题

最近遇到一个Linux系统时间无法更改小于某个固定时间的问题。

有关部门反馈，一旦将设备的时间设置小于2012年11月3号4点34分，复位设备后，系统时间就会变成2012年11月3号4点后的时间。此问题十分诡异。负责业务的同志无法排查，于是安排我——或许天生注定，我这里，所有和Linux有关，所有“底层问题”，都可以找到我。

首先重现问题，拿到设备，用上位机设置时间，结果和反馈的一样。仔细分析，uboot时间和内核时间是一致的，但到了系统里面，时间就变了。再用nfs启动来测试就没问题，一切正常，date时间和内核时间一致。和硬件的同志交流了，虽然他们以前也发现了这个现象，但没什么头绪。甚至一度怀疑RTC电池的问题，但如果这样，RTC时间会变成2000年，而不是一个奇怪的时间。交流的结果是从系统启动脚本入手。

由于脚本较多，首先想到的是在内核RTC驱动中打印设置、读取时间，以便观察是在何处操作了RTC。然后跟踪了脚本，从rc.d目录看，发现几个和时间有关脚本，查看了一下，里面调用hwclock来读取、设置时间。最终确定了问题所在，而当我刚刚整理好思绪想在部门群里汇报的时候，那位负责业务的同志已经把问题脚本截图出来了。为了表现出自己的工作量，我还是把我的结论汇报一下。

问题是这样的。

我们使用的那套rootfs，是代号为“踢啊”公司所开发的，对于系统启动时的时间管理有一个机制，就是在启动脚本中判断当前的时间比上一次的时间戳，如果小于超过一天的时候，就会使用上一次的时间戳，如果不是，则不使用。脚本大概是这样的：

# Set the system clock from hardware clock
# If the timestamp is 1 day or more recent than the current time,
# use the timestamp instead.
test -x /etc/init.d/hwclock.sh && /etc/init.d/hwclock.sh start

if test -e /etc/timestamp // ！～～～～～
then
SYSTEMDATE=`date "+%Y%m%d"`
TIMESTAMP=`cat /etc/timestamp | awk '{ print substr($0,9,4) substr($0,1,4);}'`
NEEDUPDATE=`expr \( $TIMESTAMP \> $SYSTEMDATE \)`
if [ $NEEDUPDATE -eq 1 ]; then
date `cat /etc/timestamp`
/etc/init.d/hwclock.sh stop
fi
fi

在/etc/init.d目录里有脚本读取RTC时间和保存timestamp。在每次启动时，都会如此。

我们所用的是UBI文件系统，是只读的(先前是可读可写的，但发现flash损坏事件而改为只读)。timestamp是我之前使用rootfs时所留下的时间。因此，当设置的时候小于这个值时，就会出现上文的时间了。而我的NFS是可读可写的，所以使用NFS无问题。

——但是想想，即使是可读可写的，只要时间误差太离谱，系统都会强行改为上一启动的时间。

为此再深入研究发现，这个问题本身就是“踢啊”提供的rootfs的问题，上述分析也变得是一厢情愿了。不知何故，这个rootfs里已经没有调用保存rtc的脚本了，但判断时间戳的语句还在，/etc/timestamp文件还在，所以，无论怎样，问题还是存在的。

对于这个“bug”，我个人认为没有必要修改，我相信现在不会有人把设备时间改为几年了，我不知道某些部门是如何想的。当今的RTC芯片，为了方便(如计算闰年)，把年份限制到00~99，即2000年开始的百年时间，在系统中设置时间小于2000年没问题，但写到RTC就会报错。估计这一点要向大家说明才行，不然又因认知问题导致误解。

但从电子邮件来，从测试部门的bug登记来看，这个bug很严重。由于是“在用品bug”，需要给出流出原因的预防措施，我参考前一时间发生的事件，给出原因：

应该是我没有了解到“踢啊”的rootfs有timestamp的机制，我在这方面还需要多加改进。

李迟，2015年6月19日 周五 中午