Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 671574

Summary: sys-apps/openrc: Have hwclock started earlier in boot process
Product: Gentoo Linux Reporter: Raymond Jennings <shentino>
Component: Current packagesAssignee: OpenRC Team <openrc>
Status: RESOLVED INVALID    
Severity: enhancement CC: teika
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Raymond Jennings 2018-11-20 16:12:51 UTC
I have the misfortune of having to store my computer's CMOS clock in local time instead of UTC.

Unfortunately this causes some skewed timestamps when my system loads, and I get warnings during openrc about it.

My guess is that since the kernel is booting in UTC and setting itself by the CMOS clock which it also assumes is in UTC, the boot process's view of the system time is skewed until hwclock executes.

However, it doesn't start hwclock soon enough to avoid trouble as I still get warnings.  Even moving hwclock to the sysinit runlevel doesn't start it soon enough.

My suggestion:

Have hwclock started as soon as possible, at least before it does any dependency caching of init scripts or checking of mtimes.
Comment 1 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2018-11-20 16:19:45 UTC
# qfile -C /etc/init.d/hwclock 
sys-apps/openrc (/etc/init.d/hwclock)
Comment 2 Raymond Jennings 2018-11-20 21:30:43 UTC
Sorry about that I ran qfile on /sbin/hwclock instead of /etc/init.d/hwclock

Though on that note why is /etc/init.d/hwclock part of sys-apps/openrc instead of the same package as /sbin/hwclock?
Comment 3 William Hubbs gentoo-dev 2018-12-05 23:49:03 UTC
(In reply to Raymond Jennings from comment #0)
> I have the misfortune of having to store my computer's CMOS clock in local
> time instead of UTC.
> 
> Unfortunately this causes some skewed timestamps when my system loads, and I
> get warnings during openrc about it.
> 
> My guess is that since the kernel is booting in UTC and setting itself by
> the CMOS clock which it also assumes is in UTC, the boot process's view of
> the system time is skewed until hwclock executes.
> 
> However, it doesn't start hwclock soon enough to avoid trouble as I still
> get warnings.  Even moving hwclock to the sysinit runlevel doesn't start it
> soon enough.
> 
> My suggestion:
> 
> Have hwclock started as soon as possible, at least before it does any
> dependency caching of init scripts or checking of mtimes.

The issue is that the dependency tree has to be generated before the first service script is run to make sure everything runs in the correct order.

Do you know how other init systems handle this? I'm definitely willing to look at fixing it but I need some ideas. :-)
Comment 4 Raymond Jennings 2018-12-06 01:06:12 UTC
My best guess is that other init systems don't have sophisticated dependency tree caching in the first place.  It's just a symlink farm showing in sequence what services to start and which services to stop.

Honestly, I would consider dependency caching to be an extra feature, and if it depends on hwclock to get set properly, then it has a cyclic dependency, so it falls on openrc to properly calibrate itself before it starts caching possibly bogus timestamps.

I would suggest that perhaps hwclock be marked as a "no-cache" script or something, or amend the hwclock script to invalidate the cache after it sets the clock.

In my opinion though?

The REAL solution is to be able to specify the time zone at boot via a kernel argument.  I very much disagree with the kernel presuming the RTC is set in UTC in the first place, and if I had my way, the system time would be already set properly by the kernel before init even launches.  I know that the kernel itself can read the CMOS clock, but I think it errs in presuming the time zone.
Comment 5 Raymond Jennings 2018-12-06 01:09:48 UTC
Basically, have openrc treat the hwclock script as "special" since it directly affects the system time.  Maybe mark it (and probably ntp-client as well) such that running the script invalidates the cache.
Comment 6 Raymond Jennings 2018-12-06 04:36:30 UTC
It's also possible that time zone handling is hard coded in other init systems.
Comment 7 William Hubbs gentoo-dev 2018-12-12 17:46:56 UTC
It turns out there are a couple of fixes for this.

1. You can use an initramfs to set the time before OpenRC takes over
(sys-kernel/dracut has a module for this).

2. Another possible fix that might work is on this wiki page.

https://wiki.archlinux.org/index.php/System_time#UTC_in_Windows

Also, if you look at the HCTOSYS documentation in the kernel, it has a
very strong preference for the hardware clock being in UTC.
Comment 8 William Hubbs gentoo-dev 2018-12-12 18:04:10 UTC
I'm marking this invalid, but that's only because I don't think there is
anything for me to do in OpenRC about this.

If you try the things I've mentioned above and nothing works for you,
Please feel free to update the bug and re-open it and I'll attempt to
find something else.
Comment 9 Raymond Jennings 2018-12-13 02:50:47 UTC
(In reply to William Hubbs from comment #7)
> It turns out there are a couple of fixes for this.
> 
> 1. You can use an initramfs to set the time before OpenRC takes over
> (sys-kernel/dracut has a module for this).
> 
> 2. Another possible fix that might work is on this wiki page.
> 
> https://wiki.archlinux.org/index.php/System_time#UTC_in_Windows
> 
> Also, if you look at the HCTOSYS documentation in the kernel, it has a
> very strong preference for the hardware clock being in UTC.

For option 1, wouldn't it be possible to reassign this part of the bug to genkernel?

as for 2, that's putting policy where it doesn't belong.

"Very strong preference" doesn't mean that it's forbidden to deviate.  If that were the case then hwclock's own config file shouldn't give you the choice to begin with.

I'm not sure closing this bug is the right move.  What about simply reassigning it elsewhere?
Comment 10 William Hubbs gentoo-dev 2018-12-15 16:42:13 UTC
(In reply to Raymond Jennings from comment #9)
> (In reply to William Hubbs from comment #7)
> > It turns out there are a couple of fixes for this.
> > 
> > 1. You can use an initramfs to set the time before OpenRC takes over
> > (sys-kernel/dracut has a module for this).
> > 
> > 2. Another possible fix that might work is on this wiki page.
> > 
> > https://wiki.archlinux.org/index.php/System_time#UTC_in_Windows
> > 
> > Also, if you look at the HCTOSYS documentation in the kernel, it has a
> > very strong preference for the hardware clock being in UTC.
> 
> For option 1, wouldn't it be possible to reassign this part of the bug to
> genkernel?

They might not see it as a bug, especially since there is a fix on the windows side and all other OS's work fine with the hw clock in UTC (google windows utc to see that there are multiple results about this issue).

> as for 2, that's putting policy where it doesn't belong.
> 
> "Very strong preference" doesn't mean that it's forbidden to deviate.  If
> that were the case then hwclock's own config file shouldn't give you the
> choice to begin with.

Sure, but that runs the risk of a breaking change.
I will bring it up as an issue for discussion however.
Comment 11 Raymond Jennings 2018-12-15 20:51:50 UTC
I really don't think "if you're not in UTC then screw you anyway" is a valid stance to have.

Even my system BIOS interprets the clock in localtime.