hwclock fail with 2.22

hwclock fail with 2.22

[Dave Reisner]

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.

Any insight would be appreciated.

Cheers,
Dave

Re: hwclock fail with 2.22

[Karel Zak]

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@redhat.com>
 http://karelzak.blogspot.com