Summary: | sys-apps/openrc: Have hwclock started earlier in boot process | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Raymond Jennings <shentino> |
Component: | Current packages | Assignee: | 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
# qfile -C /etc/init.d/hwclock sys-apps/openrc (/etc/init.d/hwclock) 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? (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. :-) 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. 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. It's also possible that time zone handling is hard coded in other init systems. 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. 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. (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? (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. 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. |