~alpine/devel

4 3

[alpine-devel] hwclock restoring time wrong

Isaac Dunham <ibid.ag@gmail.com>
Details
Message ID
<20140716111243.GA2021@newbook>
Sender timestamp
1405509164
DKIM signature
missing
Download raw message
Hello,
I've encountered a problem that seems to throw cron for a loop:
hwclock is saving the UTC time, but restoring it as if it were localtime.

I determined this by setting the date manually, then running:
for d in stop start; do date; hwclock -r; service hwclock $d; date; hwclock -r; done
The status changes as follows:

-manual localtime
-real UTC hwclock
hwclock stop
-manual localtime
-manual UTC hwclock
hwclock start
-localtime = manual UTC hwclock, but with the right timezone reported.

I'm not sure if this is a bug in the init script or in busybox.
What would be a good way to check that?

Thanks,
Isaac Dunham



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20140716091505.21a8c1f7@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20140716111243.GA2021@newbook> (view parent)
Sender timestamp
1405494905
DKIM signature
missing
Download raw message
On Wed, 16 Jul 2014 04:12:44 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> Hello,
> I've encountered a problem that seems to throw cron for a loop:
> hwclock is saving the UTC time, but restoring it as if it were localtime.
> 
> I determined this by setting the date manually, then running:
> for d in stop start; do date; hwclock -r; service hwclock $d; date; hwclock -r; done
> The status changes as follows:
> 
> -manual localtime
> -real UTC hwclock
> hwclock stop
> -manual localtime
> -manual UTC hwclock
> hwclock start
> -localtime = manual UTC hwclock, but with the right timezone reported.
> 
> I'm not sure if this is a bug in the init script or in busybox.
> What would be a good way to check that?

I think the hwclock 'service' has a related configuration in /etc/conf.d/hwclock.

I don't know if the default config is sane though.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Isaac Dunham <ibid.ag@gmail.com>
Details
Message ID
<20140719141340.GA2042@newbook>
In-Reply-To
<20140716091505.21a8c1f7@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1405779221
DKIM signature
missing
Download raw message
On Wed, Jul 16, 2014 at 09:15:05AM +0200, Natanael Copa wrote:
> On Wed, 16 Jul 2014 04:12:44 -0700
> Isaac Dunham <ibid.ag@gmail.com> wrote:
> 
> > Hello,
> > I've encountered a problem that seems to throw cron for a loop:
> > hwclock is saving the UTC time, but restoring it as if it were localtime.
> > 
> > I determined this by setting the date manually, then running:
> > for d in stop start; do date; hwclock -r; service hwclock $d; date; hwclock -r; done
> > The status changes as follows:
> > 
> > -manual localtime
> > -real UTC hwclock
> > hwclock stop
> > -manual localtime
> > -manual UTC hwclock
> > hwclock start
> > -localtime = manual UTC hwclock, but with the right timezone reported.
> > 
> > I'm not sure if this is a bug in the init script or in busybox.
> > What would be a good way to check that?
> 
> I think the hwclock 'service' has a related configuration in /etc/conf.d/hwclock.
> 
> I don't know if the default config is sane though.
It seems to be sane.

Per my reading, hwclock thinks it's setting UTC, so it's a bug in busybox.
At init the boot messages say it's using UTC.

Thanks,
Isaac Dunham


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Igor Falcomata' <lists@cioccolatai.it>
Details
Message ID
<20140730075945.GJ27179@127.0.0.1>
In-Reply-To
<20140719141340.GA2042@newbook> (view parent)
Sender timestamp
1406707186
DKIM signature
missing
Download raw message
On Sat, Jul 19, 2014 at 07:13:41AM -0700, Isaac Dunham wrote:

> > > I determined this by setting the date manually, then running:
> > > for d in stop start; do date; hwclock -r; service hwclock $d; date; hwclock -r; done
> > > The status changes as follows:
> > > 
> > > -manual localtime
> > > -real UTC hwclock
> > > hwclock stop
> > > -manual localtime
> > > -manual UTC hwclock
> > > hwclock start
> > > -localtime = manual UTC hwclock, but with the right timezone reported.
> > > 
> > > I'm not sure if this is a bug in the init script or in busybox.
> > > What would be a good way to check that?
> > 
> > I think the hwclock 'service' has a related configuration in /etc/conf.d/hwclock.
> > 
> > I don't know if the default config is sane though.
> It seems to be sane.
> 
> Per my reading, hwclock thinks it's setting UTC, so it's a bug in busybox.
> At init the boot messages say it's using UTC.

Same for me; i had to set clock="local" in /etc/conf.d/hwclock and then
works.

Of course this is a problem if the other osses you use on the same
workstations wants/are configured for the hwclock to be in UTC.

cheers,
I.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20140730165818.6f5e3688@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20140719141340.GA2042@newbook> (view parent)
Sender timestamp
1406732298
DKIM signature
missing
Download raw message
On Sat, 19 Jul 2014 07:13:41 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> On Wed, Jul 16, 2014 at 09:15:05AM +0200, Natanael Copa wrote:
> > On Wed, 16 Jul 2014 04:12:44 -0700
> > Isaac Dunham <ibid.ag@gmail.com> wrote:
> > 
> > > Hello,
> > > I've encountered a problem that seems to throw cron for a loop:
> > > hwclock is saving the UTC time, but restoring it as if it were localtime.
> > > 
> > > I determined this by setting the date manually, then running:
> > > for d in stop start; do date; hwclock -r; service hwclock $d; date; hwclock -r; done
> > > The status changes as follows:
> > > 
> > > -manual localtime
> > > -real UTC hwclock
> > > hwclock stop
> > > -manual localtime
> > > -manual UTC hwclock
> > > hwclock start
> > > -localtime = manual UTC hwclock, but with the right timezone reported.
> > > 
> > > I'm not sure if this is a bug in the init script or in busybox.
> > > What would be a good way to check that?
> > 
> > I think the hwclock 'service' has a related configuration in /etc/conf.d/hwclock.
> > 
> > I don't know if the default config is sane though.
> It seems to be sane.
> 
> Per my reading, hwclock thinks it's setting UTC, so it's a bug in busybox.
> At init the boot messages say it's using UTC.

There are some special magic happening first time settimeofday(2) is
called after boot:

>       Under Linux, there are some peculiar "warp clock" semantics
>       associated with the settimeofday() system call if on the very first
>       call (after booting) that has a non-NULL tz argument, the tv argument
>       is NULL and the tz_minuteswest field is nonzero.  (The tz_dsttime
>       field should be zero for this case.)  In such a case it is assumed
>       that the CMOS clock is on local time, and that it has to be
>       incremented by this amount to get UTC system time.  No doubt it is a
>       bad idea to use this feature.

(from http://man7.org/linux/man-pages/man2/settimeofday.2.html)


I don't know if that has any relevance. I have not yet bothered to dig
up what is actually going on... It would be nice if someone could
investigate what is actually happening here. Apparently different
things happens with you call it first time after boot and call it later
again - makes my head hurt...

> Thanks,
> Isaac Dunham



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)