debian启动时创建的/dev下的文件时间有的是UTC时区的，有的是CST时区的，为什么？

jqq850226

编译内核时提示：
make[2]: warning:  Clock skew detected.  Your build may be incomplete.
make[2]: Warning: File `/dev/null' has modification time 2.9e+04 s in the future

运行:
#ls -l /dev
...
drwxr-xr-x 2 root root          60 2007-10-18 14:27 mapper
crw-r----- 1 root kmem      1,   1 2007-10-18 22:27 mem
crw-rw---- 1 root audio    14,   0 2007-10-18 22:27 mixer
drwxr-xr-x 2 root root          60 2007-10-18 22:27 net
crw-rw-rw- 1 root root      1,   3 2007-10-18 22:27 null
crw-rw-rw- 1 root root    195,   0 2007-10-18 14:28 nvidia0
crw-rw-rw- 1 root root    195, 255 2007-10-18 14:28 nvidiactl
crw-r----- 1 root kmem      1,   4 2007-10-18 22:27 port
crw------- 1 root root    108,   0 2007-10-18 22:27 ppp
crw-rw---- 1 root root     10,   1 2007-10-18 22:27 psaux
crw-rw-rw- 1 root root      5,   2 2007-10-18 14:49 ptmx
.....

看上面的时间，有的是14:28，有的是22:27，差了8个小时。我touch /dev/null后又编译内核没有上面的警告，但是这个问题怎么彻底解决呀？

bufferfly

以前从没注意到这个现象, 刚发现我的系统也是这样.

但我用 ls -l -t --full-time 按照时间顺序出 /dev 目录后, 发现了一个规律: 相差8个小时的文件, 和启动时的顺序有关, 某些后启动的设备, 时间就正确.

于是我怀疑 /etc/rcS.d 下面的某个启动脚本起到了关键性作用. 后来发现是 hwclock

查看 hwclock 的 手册, 其中有一段话:

       [color="Red"]A Linux kernel maintains a concept of a local timezone for the  system.
       But  don't  be  misled  -- almost nobody cares what timezone the kernel
       thinks it is in.  Instead, programs that care about the timezone  (per-
       haps  because  they want to display a local time for you) almost always
       use a more traditional method of determining the timezone: They use the
       TZ  environment  variable  and/or the /usr/share/zoneinfo directory, as
       explained in the man page for tzset(3).   [color="Red"]However,  some  programs  and
       fringe  parts  of  the  Linux kernel such as filesystems use the kernel
       timezone value. An example is the  vfat  filesystem.   If  the  kernel
       timezone  value  is  wrong, the vfat filesystem will report and set the
       wrong timestamps on files.

原来内核自己默认了一个内部时区(一般是UTC), 这个内部时区和安装系统时的选项无关, 用户也无法通过文件配置改变. 而 hwclock 通过系统函数调用可以根据用户配置来改变这个默认的内核时区. 所以在 hwclock 被执行前, 系统的时区是错误的.

这也是为什么 /dev 目录下的文件大部分时间不对的原因, 因为 udev 的执行在 hwclock 之前(看 /etc/rcS.d 就明白了).

现在才明白, 为什么大部分 Linux 安装手册都推荐大家把 BIOS 时间设置成 UTC 时间, 原来道理在这里. :eek: :eek:

zengshibin

但是多系统的用户BIOS又选择CST时间。岂不是只能一直郁闷下去。

bufferfly

uname -v 可以看到内核编译时的时区, 自己编译后的内核, 是不是就会按照编译时机器的时间来设定这个"默认"时区呢?

d00m3d

没记错的话，自己编译的内核是根据 /etc/localtime 的时区及时间作记录的