Re: [PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't

[Trent Piepho]

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.
>