解决kdump的vmcore保存的目录的时间错误问题
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | |
CentOS 5.x安装新内核之后时钟混乱问题
1 2 | |
el5在调用mkinitrd命令时，会将/dev/rtc生成好，放到initrd- x.x.x.img文件中。而el6的系统在 /etc/rc.sysinit的/sbin/start_udev 之前是有这两个文件，也没找到el6的系统是在哪里加的这两句。
el5可选的一个做法是：修改/etc/rc.sysinit,在/sbin/start_udev这行之前加入两行：
1 2 | |
在/sbin/start_udev这行之后加入一行
1
| |
这样el5系统用18、32内核都没问题了。
el5试着将这两句改在/sbin/mkinitrd里修改，但不知道为什么改完后在执行到 /etc/rc.sysinit 时 /dev/rtc 这个软连接不见了。
或者直接将/dev/rtc改成254，0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | |
然后重建img
1
| |
http://www.csdn123.com/html/mycsdn20140110/59/59dd8c5f069a09bf9dc1785e19eb329f.html
CentOS在安装完新内核之后，每次重启之后时钟总是会发生一些变化，使得系统时钟不准确。在多操作系统的情况下（例如windows和 linux双系统），还可能会出现时区的偏差，而且无论如何设置，在重启之后都会恢复原样。如何解决这个问题还得从操作系统的时钟原理开始。
1. 操作系统中的时钟
操作系统为实现其功能，必须知道当前外部世界的时间（年月日时分秒等）。为实现这一目的，计算机设计者在主板上设置了一个硬件时钟，由主板上的一块纽扣电池（Cell）供电，这个硬件时钟无论计算机电源是否接通都会不停的数秒，来计算当前时间。
操作系统在启动的时候，会调用一段程序来读取主板上的硬件时钟，并记录在操作系统的一个（或一组）变量中。自此之后，操作系统的时钟便脱离主板的硬件时钟，开始单独运行（操作系统时钟的运行是由时钟中断来驱动的，不同于主板上的时钟）。
无论做工多么精细，主板硬件时钟和由时钟中断维护的操作系统内的时钟多多少少会有一些误差。所以，操作系统在每次关闭的时候会调用另一段程序，将操作系统 内的时钟写到主板硬件时钟里（这样设计是不是说明时钟中断比主板硬件时钟更准确一些呢？）。类似的，当用户在操作系统内修改时钟之后，也不会立即写入主板 时钟，而是在关机的时候写入硬件时钟。
2. 旧汤和新药的冲突
主板上的硬件时钟在Linux操作系统中呈现为一个设备，设备名称为rtc（Real Time Clock）。
使用旧的系统（如CentOS的2.6.18内核）编译新内核时，在调用mkinitrd命令时，会将/dev/rtc生成好，放到initrd- x.x.x.img文件中;而新的内核是自己生成/dev/rtc文件的，当kernel生成/dev/rtc时，发现系统内已经有了这个设备，于是就会 创建/dev/rtc0设备。这时hwclock程序仍然会读取rtc设备，就会造成设备读写失败。运行hwclock --debug命令可以看到如下输出：
1 2 3 4 5 | |
但是有的能够直接读写I/O，这样虽然/dev/rtc是错的，但还能正常运行
1 2 3 4 5 | |
其实，对应这个问题，新版的hwclock已经做出了调整。新的hwclock会主动去寻找/dev/rtc0设备，来操作主板硬件时钟。于是，解决方法就出现了。
3. 新汤配新药
既然内核这剂药已经换成了新的，那我们就把外围应用程序hwclock也换成新的。
从这里可以下载比较新的（不用最新的是因为最新的源码在旧版的CentOS上编译会出现错误）程序源码：http://now-code.com/download/util-linux-ng-2.17.tar.bz2
如果需要更多版本的程序源码，请到这里下载：ftp://ftp.kernel.org/pub/linux/utils/%E3%80%82
下载完成之后，编译该程序：
1 2 3 4 | |
编译完成之后，将生成的hwclock文件拷贝到指定位置即可：
1
| |
之后，操作系统和主板的硬件时钟就可以同步起来了。
linux系统时间和硬件时钟问题(date和hwclock)
http://rpf413.blog.163.com/blog/static/4556376020122831444674/
总结一下hwclock，这个容易晕：
1）/etc/sysconfig/clock 文件，只对 hwclock 命令有效，且只在系统启动和关闭的时候才有用（修改了其中的 UTC=true 到 UTC=false 的前后，执行 hwclock (--utc, 或 --localtime) 都没有变化，要重启系统后才生效）；
2）/etc/rc.d/rc.sysinit 文件，run once at boot time，其中有从硬件时钟同步时间到系统时间的操作；
3）hwclock --localtime 的输出，才是硬件时钟真正的时间。如果输出结果带时区（比如CST），还要看/etc/sysconfig/clock里的UTC参数，如果 UTC=false，那时区有意义；如果 UTC=true，那时区没意义，实际上是UTC时间。
4）在 /etc/sysconfig/clock 中 UTC=false 时，date、hwclock、hwclcok --localtime 输出的时间应该都一致，且此时 hwclock --utc是没有意义的；
5）在 /etc/sysconfig/clock 中 UTC=ture 时，date、hwclock 的输出是一致的，hwclock --localtime 的输出则是UTC时间；
6）如果不想在输出中带时区，则 export LANG=C ，然后再运行 hwclock 就没有什么CST了，免得时区误导你；
7）hwclock --utc 很闹腾，还是别看了，你会晕的。。。
8）系统关闭时会同步系统时间到硬件时钟，系统启动时会从硬件时钟读取时间更新到系统，这2个步骤都要根据 /etc/sysconfig/clock 文件中UTC的参数来设置时区转换。
实际案例分析
修改了 /etc/sysconfig/clock 中UTC参数但系统未正常关闭的情况
修改 /etc/sysconfig/clock 文件后，如果系统内核突然崩溃，然后直接按电源重启，则系统没有进行 系统时间到硬件时钟的 同步；但是 系统启动时，又根据 /etc/sysconfig/clock 中UTC的参数，来同步硬件时钟到系统，这时就会出现时间问题：
0）假设系统的时区为CST（UTC+8）；
1）假设原 /etc/sysconfig/clock 中 UTC=true，修改成 UTC=false；
2）如果此时系统未正常关机，系统时间未按参数 UTC=false 同步时间到硬件时钟（没有+8小时）；
3）但系统被按电源重启后，系统读取到 UTC=false，认为硬件时钟为CST时间，直接用于系统时间；
4）那么此时，系统时间将少了8小时。
http://hi.baidu.com/lujunqianglw/blog/item/bc2d9144d24fc48fb3b7dc1d.html
一、首先要弄清几个概念：
1. “系统时间”与“硬件时间”
系统时间: 一般说来就是我们执行 date 命令看到的时间，linux系统下所有的时间调用（除了直接访问硬件时间的命令）都是使用的这个时间。
硬件时间: 主板上BIOS中的时间，由主板电池供电来维持运行，系统开机时要读取这个时间，并根据它来设定系统时间（注意：系统启动时根据硬件时间设定系统时间的过程可能存在时区换算，这要视具体的系统及相关设置而定）。
2. “UTC时间”与“本地时间”
UTC时间：Coordinated Universal 8 e2 i( H7 t0 ^/ ^Time 世界协调时间（又称世界标准时间、世界统一时间），在一般精度要求下，它与GMT（Greenwich Mean Time，格林威治标准时间）是一样的，其实也就是说 GMT≈UTC，但 UTC 是以原子钟校准的，更精确。
本地时间：由于处在不同的时区，本地时间一般与UTC是不同的，换算方法就是
本地时间 = UTC + 时区 或 UTC = 本地时间 - 时区
时区东为正，西为负，例如在中国，本地时间都使用北京时间，在linux上显示就是 CST（China Standard Time，中国标准时，注意美国的中部标准时Central Standard Time也缩写为CST，与这里的CST不是一回事！），时区为东八区，也就是 +8 区，所以 CST=UTC+(+8小时) 或 UTC=CST-(+8小时)。
二、时间命令
1. 系统时间 date
直接调用 date，得到的是本地时间。如果想得到UTC时间的话，使用 date -u。
1 2 3 4 | |
2. 硬件时间 /sbin/hwclock
直接调用 /sbin/hwclock 显示的时间就是 BIOS 中的时间吗？未必！这要看 /etc/sysconfig/clock 中是否启用了UTC，如果启用了UTC（UTC=true），显示的其实是经过时区换算的时间而不是BIOS中真正的时间，如果加上 –localtime 选项，则得到的总是 BIOS 中实际的时间.
1 2 3 4 5 6 | |
3. /etc/localtime
这个文件用来设置系统的时区，将 /usr/share/zoneinfo/ 中相应文件拷贝到/etc下并重命名为 localtime 即可修改时区设置，而且这种修改对 date 命令是及时生效的。不论是 date 还是 hwclock 都会用到这个文件，会根据这个文件的时区设置来进行UTC和本地之间之间的换算。
4. /etc/sysconfig/clock
这个文件只对 hwclock 有效，而且似乎是只在系统启动和关闭的时候才有用，比如修改了其中的 UTC=true 到 UTC=false 的前后，执行 hwclock (--utc, 或 --localtime) 都没有变化，要重启系统后才生效。注：如果设置 UTC=false 并重启系统后,执行一些命令结果如下：
1 2 3 4 5 | |
可见，如果不使用UTC，BIOS时间（红色部分）就是系统本地时间，而且注意这时执行 hwclock --utc 得到的结果没有任何意义，因为这里我们已经禁用了UTC，而且也明显不符合“本地时间=UTC+时区”的关系。
三、linux与windows双系统间的时间同步
系统启动和关闭时，硬件时间与系统时间之间的同步有两种方式(假设在中国，用CST代表本地时间)：
方式A: 使用UTC（对linux就是 /etc/sysconfig/clock 中 UTC=true）
开机: BIOS——->UTC（将BIOS中的时间看成是UTC）——(时区变化)—–>CST
关机: CST ——-(时区变化)—–>UTC——-存储到——>BIOS
方式B: 不使用UTC（对linux就是 /etc/sysconfig/clock 中 UTC=false）
开机: BIOS———————>CST（将BIOS中的时间看成是CST）
关机: CST ———存储到——>BIOS
FIX:
方式A: 使用UTC（对linux就是 /etc/sysconfig/clock 中 UTC=true）
关机: CST ——-操作系统根据时区算出UTC时间——-存储到——>BIOS
开机: BIOS——->BIOS中的时间是UTC———–操作系统根据时区计算出localtime———-CST
方式B: 不使用UTC（对linux就是 /etc/sysconfig/clock 中 UTC=false）
关机: CST ——–操作系统中UTC=false，直接将localtime存储到——>BIOS
开机: BIOS——–BIOS中的时间是localtime—–操作系统中UTC=false，BIOS时间当成localtime——–>CST（将BIOS中的时间看成是CST）
通过设定 /etc/sysconfig/clock，linux可以支持这两种方式，然而windows只支持方式B（至少是默认支持B，而我不知道怎么能让它支 持A），那么在双系统情况下，如果linux设成A方式，那么在linux与windows系统切换时一定会造成时间混乱的，解决办法就是将linux中 的UTC禁用，也设成B方式就可以了。
注：可以通过 hwclock --hctosys 来利用硬件时间来设置系统时间（注意不是简单的复制BIOS中的时间为系统时间，要看是否使用UTC，如果使用的话则要做时区换算），通过 hwclock --systohc 来根据系统时间设置硬件时间（也要看是否启用UTC来决定是否做时区换算）。
总之，不论使用 --systohc 还是 --hctosys，同步后直接运行不带参数的 hwclock 得到的时间与直接运行 date 得到的时间应该一致，这个时间是否就是BIOS中的时间（hwclock --localtime)那就不一定了，如果启用了UTC就不是，没启用UTC就是。
而且还要注意：在系统中手动使用 hwclock hwclock --set --date='yyyy-mm-dd' 来设置BIOS时间只在系统运行时有效，因为当系统关闭时，还会按设定好的方式根据系统时间来重设BIOS时间的，于是手动的设置便被覆盖掉了。