Some machines store local time in the Real Time Clock. The hard-coded
"UTC" string is wrong on those machines so just omit that string.
Update the log parser so it doesn't require the string "UTC".
Signed-off-by: Finn Thain <[email protected]>
---
drivers/rtc/hctosys.c | 2 +-
tools/power/pm-graph/bootgraph.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
index ff2092a0d38c..2270eca23203 100644
--- a/drivers/rtc/hctosys.c
+++ b/drivers/rtc/hctosys.c
@@ -58,7 +58,7 @@ static int __init rtc_hctosys(void)
err = do_settimeofday64(&tv64);
- dev_info(rtc->dev.parent, "setting system clock to %ptR UTC (%lld)\n",
+ dev_info(rtc->dev.parent, "setting system clock to %ptR (%lld)\n",
&tm, (long long)tv64.tv_sec);
err_read:
diff --git a/tools/power/pm-graph/bootgraph.py b/tools/power/pm-graph/bootgraph.py
index 6dae57041537..5a045d1cb879 100755
--- a/tools/power/pm-graph/bootgraph.py
+++ b/tools/power/pm-graph/bootgraph.py
@@ -333,7 +333,7 @@ def parseKernelLog():
if(not sysvals.stamp['kernel']):
sysvals.stamp['kernel'] = sysvals.kernelVersion(msg)
continue
- m = re.match('.* setting system clock to (?P<t>.*) UTC.*', msg)
+ m = re.match('.* setting system clock to (?P<t>.*) (?:UTC )?\(.*', msg)
if(m):
bt = datetime.strptime(m.group('t'), '%Y-%m-%d %H:%M:%S')
bt = bt - timedelta(seconds=int(ktime))
--
2.21.0
On 21/06/2019 11:51:26+1000, Finn Thain wrote:
> Some machines store local time in the Real Time Clock. The hard-coded
> "UTC" string is wrong on those machines so just omit that string.
> Update the log parser so it doesn't require the string "UTC".
>
I don't agree, hctossys will always think the RTC is in UTC. If you
store local time in the RTC, then you are probably not using hctosys
because it definitively doesn't know about the timezone and will
incorrectly set the system time. That information is usually kept in
/etc/adjtime.
> Signed-off-by: Finn Thain <[email protected]>
> ---
> drivers/rtc/hctosys.c | 2 +-
> tools/power/pm-graph/bootgraph.py | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
> index ff2092a0d38c..2270eca23203 100644
> --- a/drivers/rtc/hctosys.c
> +++ b/drivers/rtc/hctosys.c
> @@ -58,7 +58,7 @@ static int __init rtc_hctosys(void)
>
> err = do_settimeofday64(&tv64);
>
> - dev_info(rtc->dev.parent, "setting system clock to %ptR UTC (%lld)\n",
> + dev_info(rtc->dev.parent, "setting system clock to %ptR (%lld)\n",
> &tm, (long long)tv64.tv_sec);
>
> err_read:
> diff --git a/tools/power/pm-graph/bootgraph.py b/tools/power/pm-graph/bootgraph.py
> index 6dae57041537..5a045d1cb879 100755
> --- a/tools/power/pm-graph/bootgraph.py
> +++ b/tools/power/pm-graph/bootgraph.py
> @@ -333,7 +333,7 @@ def parseKernelLog():
> if(not sysvals.stamp['kernel']):
> sysvals.stamp['kernel'] = sysvals.kernelVersion(msg)
> continue
> - m = re.match('.* setting system clock to (?P<t>.*) UTC.*', msg)
> + m = re.match('.* setting system clock to (?P<t>.*) (?:UTC )?\(.*', msg)
> if(m):
> bt = datetime.strptime(m.group('t'), '%Y-%m-%d %H:%M:%S')
> bt = bt - timedelta(seconds=int(ktime))
> --
> 2.21.0
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Mon, 24 Jun 2019, Alexandre Belloni wrote:
> On 21/06/2019 11:51:26+1000, Finn Thain wrote:
> > Some machines store local time in the Real Time Clock. The hard-coded
> > "UTC" string is wrong on those machines so just omit that string.
> > Update the log parser so it doesn't require the string "UTC".
> >
>
> I don't agree, hctossys will always think the RTC is in UTC.
Well, I wasn't speculating about a theoretical problem. This is a bug that
was reported to me by a user of Debian/powerpc system.
I was able to confirm that the bug also affects dual-boot Windows/Linux on
x86 with CONFIG_RTC_HCTOSYS=y.
> If you store local time in the RTC, then you are probably not using
> hctosys because it definitively doesn't know about the timezone and will
> incorrectly set the system time. That information is usually kept in
> /etc/adjtime.
>
In the Debian/powerpc bug report, the timezone is obtained from the NVRAM:
[ 0.000000] PowerMac motherboard: PowerBook Wallstreet
...
[ 0.000000] GMT Delta read from XPRAM: -360 minutes, DST: on
...
[ 37.605859] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
...
[ 40.346255] rtc-generic rtc-generic: setting system clock to 2019-06-19 15:17:35 UTC (1560957455)
...
Though I don't know whether the sys_tz value is relevant here.
Anyway, here's the bug reproduced on x86 --
# dmesg | grep rtc_cmos
[ 0.543878] rtc_cmos 00:02: RTC can wake from S4
[ 0.544090] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[ 0.544090] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[ 0.545807] rtc_cmos 00:02: setting system clock to 2019-06-25 11:24:14 UTC (1561461854)
# grep . /etc/adjtime /etc/timezone
/etc/adjtime:0.000120 1550184138 0.000000
/etc/adjtime:1550184138
/etc/adjtime:LOCAL
/etc/timezone:Australia/Melbourne
# hwclock --show
2019-06-25 11:47:49.702660+10:00
# date --iso-8601=s
2019-06-25T11:48:01+10:00
#
Looks wrong to me. What am I missing?
--
> > Signed-off-by: Finn Thain <[email protected]>
> > ---
> > drivers/rtc/hctosys.c | 2 +-
> > tools/power/pm-graph/bootgraph.py | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
> > index ff2092a0d38c..2270eca23203 100644
> > --- a/drivers/rtc/hctosys.c
> > +++ b/drivers/rtc/hctosys.c
> > @@ -58,7 +58,7 @@ static int __init rtc_hctosys(void)
> >
> > err = do_settimeofday64(&tv64);
> >
> > - dev_info(rtc->dev.parent, "setting system clock to %ptR UTC (%lld)\n",
> > + dev_info(rtc->dev.parent, "setting system clock to %ptR (%lld)\n",
> > &tm, (long long)tv64.tv_sec);
> >
> > err_read:
> > diff --git a/tools/power/pm-graph/bootgraph.py b/tools/power/pm-graph/bootgraph.py
> > index 6dae57041537..5a045d1cb879 100755
> > --- a/tools/power/pm-graph/bootgraph.py
> > +++ b/tools/power/pm-graph/bootgraph.py
> > @@ -333,7 +333,7 @@ def parseKernelLog():
> > if(not sysvals.stamp['kernel']):
> > sysvals.stamp['kernel'] = sysvals.kernelVersion(msg)
> > continue
> > - m = re.match('.* setting system clock to (?P<t>.*) UTC.*', msg)
> > + m = re.match('.* setting system clock to (?P<t>.*) (?:UTC )?\(.*', msg)
> > if(m):
> > bt = datetime.strptime(m.group('t'), '%Y-%m-%d %H:%M:%S')
> > bt = bt - timedelta(seconds=int(ktime))
> > --
> > 2.21.0
> >
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
On 25/06/2019 11:53:49+1000, Finn Thain wrote:
> On Mon, 24 Jun 2019, Alexandre Belloni wrote:
>
> > On 21/06/2019 11:51:26+1000, Finn Thain wrote:
> > > Some machines store local time in the Real Time Clock. The hard-coded
> > > "UTC" string is wrong on those machines so just omit that string.
> > > Update the log parser so it doesn't require the string "UTC".
> > >
> >
> > I don't agree, hctossys will always think the RTC is in UTC.
>
> Well, I wasn't speculating about a theoretical problem. This is a bug that
> was reported to me by a user of Debian/powerpc system.
>
> I was able to confirm that the bug also affects dual-boot Windows/Linux on
> x86 with CONFIG_RTC_HCTOSYS=y.
>
> > If you store local time in the RTC, then you are probably not using
> > hctosys because it definitively doesn't know about the timezone and will
> > incorrectly set the system time. That information is usually kept in
> > /etc/adjtime.
> >
>
> In the Debian/powerpc bug report, the timezone is obtained from the NVRAM:
>
> [ 0.000000] PowerMac motherboard: PowerBook Wallstreet
> ...
> [ 0.000000] GMT Delta read from XPRAM: -360 minutes, DST: on
> ...
> [ 37.605859] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
> ...
> [ 40.346255] rtc-generic rtc-generic: setting system clock to 2019-06-19 15:17:35 UTC (1560957455)
> ...
>
> Though I don't know whether the sys_tz value is relevant here.
>
> Anyway, here's the bug reproduced on x86 --
>
> # dmesg | grep rtc_cmos
> [ 0.543878] rtc_cmos 00:02: RTC can wake from S4
> [ 0.544090] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
> [ 0.544090] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
> [ 0.545807] rtc_cmos 00:02: setting system clock to 2019-06-25 11:24:14 UTC (1561461854)
> # grep . /etc/adjtime /etc/timezone
> /etc/adjtime:0.000120 1550184138 0.000000
> /etc/adjtime:1550184138
> /etc/adjtime:LOCAL
> /etc/timezone:Australia/Melbourne
> # hwclock --show
> 2019-06-25 11:47:49.702660+10:00
> # date --iso-8601=s
> 2019-06-25T11:48:01+10:00
> #
>
> Looks wrong to me. What am I missing?
>
Userspace is certainly adjusting the timezone after the kernel did. Can
you run the same commands without running your init?
On stable, you have /etc/init.d/hwclock.sh that still runs and does the
correct thing. My understanding is that systemd also handles the TZ
properly after hctosys (see clock_is_localtime()).
Seriously, hctosys does a really bad job at setting the system time, it
is guaranteed to be always wrong on most platforms. My plan is still to
try to get distros to stop enabling it and do that properly in
userspace. This is already ok when using sysV but systemd would need a
few changes to stop relying on it when then is no hwclock initscript.
Unfortunately, I didn't have time to work on that yet.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Tue, 2019-06-25 at 11:29 +0200, Alexandre Belloni wrote:
>
>
> Userspace is certainly adjusting the timezone after the kernel did. Can
> you run the same commands without running your init?
>
> On stable, you have /etc/init.d/hwclock.sh that still runs and does the
> correct thing. My understanding is that systemd also handles the TZ
> properly after hctosys (see clock_is_localtime()).
>
> Seriously, hctosys does a really bad job at setting the system time, it
> is guaranteed to be always wrong on most platforms. My plan is still to
> try to get distros to stop enabling it and do that properly in
> userspace. This is already ok when using sysV but systemd would need a
> few changes to stop relying on it when then is no hwclock initscript.
> Unfortunately, I didn't have time to work on that yet.
hctosys is very handy in that it sets the system time before any log
messages are generated. Either in a main boot or in an initramfs.
Having property time-stamped log messages is very important for
managing a large deployment.
If the system time is set by some script or systemd unit, then there
will always be all the things that need to run before that script or
unit can work. E.g., udev creating rtc device nodes, mounting /sys and
/proc, systemd generator for local file system unis, the other parts of
systemd to do that, etc. All this won't be able to log with correct
system time.
On 25/06/2019 17:16:52+0000, Trent Piepho wrote:
> On Tue, 2019-06-25 at 11:29 +0200, Alexandre Belloni wrote:
> > Userspace is certainly adjusting the timezone after the kernel did. Can
> > you run the same commands without running your init?
> >
> > On stable, you have /etc/init.d/hwclock.sh that still runs and does the
> > correct thing. My understanding is that systemd also handles the TZ
> > properly after hctosys (see clock_is_localtime()).
> >
> > Seriously, hctosys does a really bad job at setting the system time, it
> > is guaranteed to be always wrong on most platforms. My plan is still to
> > try to get distros to stop enabling it and do that properly in
> > userspace. This is already ok when using sysV but systemd would need a
> > few changes to stop relying on it when then is no hwclock initscript.
> > Unfortunately, I didn't have time to work on that yet.
>
> hctosys is very handy in that it sets the system time before any log
> messages are generated. Either in a main boot or in an initramfs.
> Having property time-stamped log messages is very important for
> managing a large deployment.
>
> If the system time is set by some script or systemd unit, then there
> will always be all the things that need to run before that script or
> unit can work. E.g., udev creating rtc device nodes, mounting /sys and
> /proc, systemd generator for local file system unis, the other parts of
> systemd to do that, etc. All this won't be able to log with correct
> system time.
>
I'd argue that this system time is not correct anyway and hence is not
that useful. Especially since the boot time to anything reading the RTC
will still be smaller than the maximum error hctosys can have (that is
up to two seconds). This is even worse if the RTC sotres local time.
Instead of using a systemd unit, we could make systemd read the RTC as
soon as possible and set the system time correctly (at least, that is my
plan). This would be especially useful when using NTP because as already
reported, it may take a few hours to actually synchronize because
hctosys didn't set the correct time.
I would agree that there are remaining use cases for hctosys, e.g. when
wanting to boot a rootfs over a network filesystem and without an
initramfs.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Tue, 2019-06-25 at 21:19 +0200, Alexandre Belloni wrote:
> On 25/06/2019 17:16:52+0000, Trent Piepho wrote:
> > On Tue, 2019-06-25 at 11:29 +0200, Alexandre Belloni wrote:
> > > Userspace is certainly adjusting the timezone after the kernel did. Can
> > > you run the same commands without running your init?
> > >
> > > On stable, you have /etc/init.d/hwclock.sh that still runs and does the
> > > correct thing. My understanding is that systemd also handles the TZ
> > > properly after hctosys (see clock_is_localtime()).
> > >
> > > Seriously, hctosys does a really bad job at setting the system time, it
> > > is guaranteed to be always wrong on most platforms. My plan is still to
> > > try to get distros to stop enabling it and do that properly in
> > > userspace. This is already ok when using sysV but systemd would need a
> > > few changes to stop relying on it when then is no hwclock initscript.
> > > Unfortunately, I didn't have time to work on that yet.
> >
> > hctosys is very handy in that it sets the system time before any log
> > messages are generated. Either in a main boot or in an initramfs.
> > Having property time-stamped log messages is very important for
> > managing a large deployment.
> >
> > If the system time is set by some script or systemd unit, then there
> > will always be all the things that need to run before that script or
> > unit can work. E.g., udev creating rtc device nodes, mounting /sys and
> > /proc, systemd generator for local file system unis, the other parts of
> > systemd to do that, etc. All this won't be able to log with correct
> > system time.
> >
>
> I'd argue that this system time is not correct anyway and hence is not
> that useful. Especially since the boot time to anything reading the RTC
> will still be smaller than the maximum error hctosys can have (that is
> up to two seconds). This is even worse if the RTC sotres local time.
Why would the system time be incorrect by more than +- 500 ms plus
whatever the drift the RTC since the last time it was correctly set?
Is there another source of error?
The +-500 ms error could be reduced by using an update interrupt in
hctosys.
If one were to not set the RTC to UTC, then yes there is a problem.
But it's manageable. Don't do that. I've got large numbers of
embedded devices I've designed. Why would I design them to use local
time in the RTC?
If one does set the RTC to local time, then it's bad, but not
impossible to deal with. The log messages that have timestamps between
boot and when the timezone is set will be in the wrong zone. The
necessary information to correct this error exists. It's far better
than all timestamps as Jan 1st 1970.
> Instead of using a systemd unit, we could make systemd read the RTC as
> soon as possible and set the system time correctly (at least, that is my
But what is as soon as possible? Doesn't it need /dev/rtc or maybe
/sys/class/rtc to exist? That doesn't happen for a while after boot.
> plan). This would be especially useful when using NTP because as already
> reported, it may take a few hours to actually synchronize because
> hctosys didn't set the correct time.
Is that really a problem in hctosys? Usually one always does some sort
of makestep option in ntp to set rather than skew the clock on start,
perhaps only if the error is too great, to avoid synchronizing taking
an exceeding long time.
I see this as two blatant system misconfigurations. One, telling the
kernel to set the time based on a RTC set to UTC and then not setting
the RTC to UTC. And two, setting ntp to not step the clock and giving
it a huge initial error to deal with.
>
> I would agree that there are remaining use cases for hctosys, e.g. when
> wanting to boot a rootfs over a network filesystem and without an
> initramfs.
>
On Tue, 25 Jun 2019, Alexandre Belloni wrote:
> On 25/06/2019 11:53:49+1000, Finn Thain wrote:
> > On Mon, 24 Jun 2019, Alexandre Belloni wrote:
> >
> > > On 21/06/2019 11:51:26+1000, Finn Thain wrote:
> > > > Some machines store local time in the Real Time Clock. The
> > > > hard-coded "UTC" string is wrong on those machines so just omit
> > > > that string. Update the log parser so it doesn't require the
> > > > string "UTC".
> > > >
> > >
> > > I don't agree, hctossys will always think the RTC is in UTC.
> >
> > Well, I wasn't speculating about a theoretical problem. This is a bug
> > that was reported to me by a user of Debian/powerpc system.
> >
> > I was able to confirm that the bug also affects dual-boot
> > Windows/Linux on x86 with CONFIG_RTC_HCTOSYS=y.
> >
> > > If you store local time in the RTC, then you are probably not using
> > > hctosys because it definitively doesn't know about the timezone and
> > > will incorrectly set the system time. That information is usually
> > > kept in /etc/adjtime.
> > >
> >
> > In the Debian/powerpc bug report, the timezone is obtained from the NVRAM:
> >
> > [ 0.000000] PowerMac motherboard: PowerBook Wallstreet
> > ...
> > [ 0.000000] GMT Delta read from XPRAM: -360 minutes, DST: on
> > ...
> > [ 37.605859] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
> > ...
> > [ 40.346255] rtc-generic rtc-generic: setting system clock to 2019-06-19 15:17:35 UTC (1560957455)
> > ...
> >
> > Though I don't know whether the sys_tz value is relevant here.
> >
> > Anyway, here's the bug reproduced on x86 --
> >
> > # dmesg | grep rtc_cmos
> > [ 0.543878] rtc_cmos 00:02: RTC can wake from S4
> > [ 0.544090] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
> > [ 0.544090] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
> > [ 0.545807] rtc_cmos 00:02: setting system clock to 2019-06-25 11:24:14 UTC (1561461854)
> > # grep . /etc/adjtime /etc/timezone
> > /etc/adjtime:0.000120 1550184138 0.000000
> > /etc/adjtime:1550184138
> > /etc/adjtime:LOCAL
> > /etc/timezone:Australia/Melbourne
> > # hwclock --show
> > 2019-06-25 11:47:49.702660+10:00
> > # date --iso-8601=s
> > 2019-06-25T11:48:01+10:00
> > #
> >
> > Looks wrong to me. What am I missing?
> >
>
> Userspace is certainly adjusting the timezone after the kernel did. Can
> you run the same commands without running your init?
>
Sure. I booted into /bin/sh instead of /sbin/init then mounted /proc and
/dev, and got this:
# dmesg | grep rtc_cmos
[ 0.544046] rtc_cmos 00:02: RTC can wake from S4
[ 0.544246] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[ 0.544246] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[ 0.545514] rtc_cmos 00:02: setting system clock to 2019-06-26 14:19:40 UTC (1561558780)
# grep . /etc/adjtime /etc/timezone
/etc/adjtime:0.000120 1550184138 0.000000
/etc/adjtime:1550184138
/etc/adjtime:LOCAL
/etc/timezone:Australia/Melbourne
# hwclock --show
2019-06-26 14:22:25.437089+10:00
# date --iso-8601=s
2019-06-27T00:22:45+10:00
As expected, the kernel message still agrees with the output from hwclock.
> On stable, you have /etc/init.d/hwclock.sh that still runs and does the
> correct thing. My understanding is that systemd also handles the TZ
> properly after hctosys (see clock_is_localtime()).
>
This was Gentoo/x86 with openrc. The Debian/powerpc problem is exactly the
same: the kernel messages report local time whilst claiming that it's UTC.
> Seriously, hctosys does a really bad job at setting the system time, it
> is guaranteed to be always wrong on most platforms. My plan is still to
> try to get distros to stop enabling it and do that properly in
> userspace. This is already ok when using sysV but systemd would need a
> few changes to stop relying on it when then is no hwclock initscript.
> Unfortunately, I didn't have time to work on that yet.
>
It doesn't help if you are able to change all of the future distros. If
you remove hctosys you will break some distros which have already shipped.
For example, I've seen a Debian release that will force a fsck of the root
filesystem without CONFIG_RTC_HCTOSYS. This is a temporary denial of
service not a failure, but in general a backward jump by a few hours can
have bad consequences, such as services that refuse to start.
Anyway, this bug is about a misleading printk, it isn't about removing
functionality. Why conflate these two issues?
--
On 26/06/2019 14:42:31+1000, Finn Thain wrote:
> > Userspace is certainly adjusting the timezone after the kernel did. Can
> > you run the same commands without running your init?
> >
>
> Sure. I booted into /bin/sh instead of /sbin/init then mounted /proc and
> /dev, and got this:
>
> # dmesg | grep rtc_cmos
> [ 0.544046] rtc_cmos 00:02: RTC can wake from S4
> [ 0.544246] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
> [ 0.544246] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
> [ 0.545514] rtc_cmos 00:02: setting system clock to 2019-06-26 14:19:40 UTC (1561558780)
> # grep . /etc/adjtime /etc/timezone
> /etc/adjtime:0.000120 1550184138 0.000000
> /etc/adjtime:1550184138
> /etc/adjtime:LOCAL
> /etc/timezone:Australia/Melbourne
> # hwclock --show
> 2019-06-26 14:22:25.437089+10:00
> # date --iso-8601=s
> 2019-06-27T00:22:45+10:00
>
> As expected, the kernel message still agrees with the output from hwclock.
>
hwclock has the information that the RTC is in localtime but hctosys
correctly set the system time to 2019-06-26T14:19:40+00:00, that is
2019-06-27T00:19:40+10:00 so the kernel message is right and the system
time is wrong, unless you invoke hwclock -s
> > On stable, you have /etc/init.d/hwclock.sh that still runs and does the
> > correct thing. My understanding is that systemd also handles the TZ
> > properly after hctosys (see clock_is_localtime()).
> >
>
> This was Gentoo/x86 with openrc. The Debian/powerpc problem is exactly the
> same: the kernel messages report local time whilst claiming that it's UTC.
>
That is not what it is reporting, it is reporting that it is setting the
system time, thinking that the RTC is in UTC time. Your test shows that
this is what happens on x86.
> > Seriously, hctosys does a really bad job at setting the system time, it
> > is guaranteed to be always wrong on most platforms. My plan is still to
> > try to get distros to stop enabling it and do that properly in
> > userspace. This is already ok when using sysV but systemd would need a
> > few changes to stop relying on it when then is no hwclock initscript.
> > Unfortunately, I didn't have time to work on that yet.
> >
>
> It doesn't help if you are able to change all of the future distros. If
> you remove hctosys you will break some distros which have already shipped.
>
> For example, I've seen a Debian release that will force a fsck of the root
> filesystem without CONFIG_RTC_HCTOSYS. This is a temporary denial of
> service not a failure, but in general a backward jump by a few hours can
> have bad consequences, such as services that refuse to start.
>
> Anyway, this bug is about a misleading printk, it isn't about removing
> functionality. Why conflate these two issues?
Again, your test shows that I'm correct and hctosys is setting the
system time using the RTC time as UTC time. This gets fixed later by
userspace.
PowerPC is the only different platform because it is able to set sys_tz.
It is the only platform doing so. What you can do is check
sys_tz.tz_minuteswest, keep UTC if it is 0 and print the timezone if it
is not.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On Sat, 13 Jul 2019, Alexandre Belloni wrote:
> On 26/06/2019 14:42:31+1000, Finn Thain wrote:
> > > Userspace is certainly adjusting the timezone after the kernel did.
> > > Can you run the same commands without running your init?
> > >
> >
> > Sure. I booted into /bin/sh instead of /sbin/init then mounted /proc
> > and /dev, and got this:
> >
> > # dmesg | grep rtc_cmos
> > [ 0.544046] rtc_cmos 00:02: RTC can wake from S4
> > [ 0.544246] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
> > [ 0.544246] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
> > [ 0.545514] rtc_cmos 00:02: setting system clock to 2019-06-26 14:19:40 UTC (1561558780)
> > # grep . /etc/adjtime /etc/timezone
> > /etc/adjtime:0.000120 1550184138 0.000000
> > /etc/adjtime:1550184138
> > /etc/adjtime:LOCAL
> > /etc/timezone:Australia/Melbourne
> > # hwclock --show
> > 2019-06-26 14:22:25.437089+10:00
> > # date --iso-8601=s
> > 2019-06-27T00:22:45+10:00
> >
> > As expected, the kernel message still agrees with the output from
> > hwclock.
> >
>
> hwclock has the information that the RTC is in localtime
Right. From the man page:
The time shown is always in local time, even if you keep your
Hardware Clock in UTC.
The output from hwclock is fine, the output from the kernel is confusing.
> but hctosys correctly set the system time to 2019-06-26T14:19:40+00:00,
> that is 2019-06-27T00:19:40+10:00 so the kernel message is right and the
> system time is wrong, unless you invoke hwclock -s
>
I would not say, "correctly set". The system time is wrong here.
> > > On stable, you have /etc/init.d/hwclock.sh that still runs and does
> > > the correct thing. My understanding is that systemd also handles the
> > > TZ properly after hctosys (see clock_is_localtime()).
> > >
> >
> > This was Gentoo/x86 with openrc. The Debian/powerpc problem is exactly
> > the same: the kernel messages report local time whilst claiming that
> > it's UTC.
> >
>
> That is not what it is reporting, it is reporting that it is setting the
> system time, thinking that the RTC is in UTC time. Your test shows that
> this is what happens on x86.
>
Thanks for your explanation. Please disregard my patch. I see that the
printk is sensible (i.e. the system clock value is printed in UTC) even
though the system clock value itself is bogus (up until the init scripts
fix it).
> > > Seriously, hctosys does a really bad job at setting the system time,
> > > it is guaranteed to be always wrong on most platforms. My plan is
> > > still to try to get distros to stop enabling it and do that properly
> > > in userspace. This is already ok when using sysV but systemd would
> > > need a few changes to stop relying on it when then is no hwclock
> > > initscript. Unfortunately, I didn't have time to work on that yet.
> > >
> >
> > It doesn't help if you are able to change all of the future distros.
> > If you remove hctosys you will break some distros which have already
> > shipped.
> >
> > For example, I've seen a Debian release that will force a fsck of the
> > root filesystem without CONFIG_RTC_HCTOSYS. This is a temporary denial
> > of service not a failure, but in general a backward jump by a few
> > hours can have bad consequences, such as services that refuse to
> > start.
> >
> > Anyway, this bug is about a misleading printk, it isn't about removing
> > functionality. Why conflate these two issues?
>
> Again, your test shows that I'm correct and hctosys is setting the
> system time using the RTC time as UTC time. This gets fixed later by
> userspace.
>
> PowerPC is the only different platform because it is able to set sys_tz.
> It is the only platform doing so. What you can do is check
> sys_tz.tz_minuteswest, keep UTC if it is 0 and print the timezone if it
> is not.
>
If userland is responsible for setting sys_tz.tz_minuteswest then we
probably should not rely on it here.
PowerMacs may set sys_tz.tz_minuteswest because the NVRAM on that platform
contains the GMT Bias, thanks to Mac OS. Linux never sets this value in
NVRAM, AFAIK, and Windows doesn't make this value available either.
On PowerMacs, this value already gets logged by the kernel. So I don't
think any logging change is needed here.
--