On Fri, Sep 07, 2012 at 11:56:00PM -0400, Dave Reisner wrote: > I'm trying to figure out a bug report that I received the other day with > hwclock, and I'm curious if anyone else has seen the behavior. I'm not > able to reproduce reliably as the user is: > > https://bugs.archlinux.org/task/31416 > > The bits about fsck can be ignored, they're merely a symptom. I was able > to trace this behavior with an educated guess back to 839be2ba6. > > I suppose part of the issue is that I'm fairly oblivious about how the > hwclock works, and the interaction with the timezone, particularly when > the clock is set to UTC. The reporter is using sysvinit with Arch > Linux's initscripts. hwclock's involvement in his case boils down to the > following call on bootup: > > hwclock --systz --utc --noadjfile > > Of course, the --systz flag in there won't work as it used to anymore, > but the commit message I've picked out doesn't seem to match the > behavior it changes. The command hwclock --systz has to be the *first* place where system uses settimeofday() after reboot, otherwise it will do nothing. Only very first settimeofday() call modify the kernel timezone and warp the system clocks. The timezone setting in userspace have to be done before you call hwclock to make localtime() usable. (TZ=...) The reason for the 839be2ba6b44fa9dc is that sometimes people randomly use hwclock --systz more than once on already running system and then every hwclock --systz modifies warp the system clocks. BTW, systemd uses the same solution. (settimeofday) with NULL tv). See kernel kernel/time.c: do_sys_settimeofday() for more details. Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
