Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 496024 - sys-apps/openrc clock="local" setting is ignored
Summary: sys-apps/openrc clock="local" setting is ignored
Status: RESOLVED DUPLICATE of bug 434410
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: OpenRC Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-25 20:18 UTC by mateakos
Modified: 2014-07-24 22:29 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Proposed patch (0001-hwclock-Always-call-hwclock-systz-when-the-clock-is-.patch,934 bytes, patch)
2014-07-22 01:22 UTC, Mike Gilbert
Details | Diff
Revised patch (0001-hwclock-Always-call-hwclock-systz-when-the-clock-is-.patch,934 bytes, patch)
2014-07-22 01:25 UTC, Mike Gilbert
Details | Diff
0001-hwclock-always-set-timezone.patch (0001-hwclock-always-set-timezone.patch,1.11 KB, patch)
2014-07-23 21:21 UTC, William Hubbs
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mateakos 2013-12-25 20:18:49 UTC
At startup, when ntpd starts and after that on every 11 minutes, the kernel sets the hwclock (RTC) to UTC time, regardless of the clock="local" setting in the /etc/conf.d/hwclock configuration file.
Comment 1 mateakos 2013-12-25 20:44:25 UTC
The 11 minutes RTC update is enabled in the kernel config, by CONFIG_GENERIC_CMOS_UPDATE || CONFIG_RTC_SYSTOHC.
CONFIG_GENERIC_CMOS_UPDATE has no entry in menuconfig, and is dependency of CONFIG_X86 so it can't be disabled simply.

The problem can be solved by calling the "settimeofday" system call after bootup in a special way, here is the relevant portion of man 2 settimeofday:

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

I wrote a small C program to solve the program:
//setrtclocal.c
//=======
#include <sys/time.h>
int main(int argc,char** argv) {
	struct timezone tz;
	tz.tz_minuteswest=1;
	tz.tz_dsttime=0;
	settimeofday(0,&tz);
	return 0;
}
//=======
And executed it from /etc/init.d/hwclock, before anything, if clock="local".

That solved the prbolem.
I'm reporting the bug, because it can be usefull for somebody else.
Comment 2 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2014-04-02 15:52:27 UTC
Not sure what this has to do with the kernel, especially since writing a C program to resolve it works; I therefore think this is an user space problem.
Comment 3 William Hubbs gentoo-dev 2014-07-20 22:55:03 UTC
(In reply to mateakos from comment #1)
> The 11 minutes RTC update is enabled in the kernel config, by
> CONFIG_GENERIC_CMOS_UPDATE || CONFIG_RTC_SYSTOHC.

Did you try disabling CONFIG_RTC_SYSTOHC? I ask because, based on what I read in make menuconfig,  disabling that option should take care of this.

Thanks,

William
Comment 4 mateakos 2014-07-21 00:25:30 UTC
(In reply to William Hubbs from comment #3)
> Did you try disabling CONFIG_RTC_SYSTOHC? I ask because, based on what I
> read in make menuconfig,  disabling that option should take care of this.

Yes, I tried, but I can't disable CONFIG_GENERIC_CMOS_UPDATE because it has no menu entry and it is the dependency of CONFIG_X86, so the OR-ed expression is still true.
There is two problem.
1) Can't disable the 11 minutes RTC update on X86.
2) clock="local" does not set the persistent_clock_is_local variable in the kernel.

The 2nd problem is solved by my small C program and Script modification.

Best regards,
Akos
Comment 5 William Hubbs gentoo-dev 2014-07-21 04:31:03 UTC
(In reply to mateakos from comment #4)
> (In reply to William Hubbs from comment #3)
> > Did you try disabling CONFIG_RTC_SYSTOHC? I ask because, based on what I
> > read in make menuconfig,  disabling that option should take care of this.
> 
> Yes, I tried, but I can't disable CONFIG_GENERIC_CMOS_UPDATE because it has
> no menu entry and it is the dependency of CONFIG_X86, so the OR-ed
> expression is still true.
> There is two problem.
> 1) Can't disable the 11 minutes RTC update on X86.

This piece is a kernel issue.

> 2) clock="local" does not set the persistent_clock_is_local variable in the
> kernel.

I have one more thing I would like you to try for this, if you haven't already.

If you can try this, please do the following.

In /etc/conf.d/hwclock, change the line that reads:

#clock_hctosys="YES"

to:

clock_hctosys="NO"

Then, reboot without running your c program or your script modification and let me know if that fixes your issue.

Thanks very much for your help.
Comment 6 mateakos 2014-07-21 22:43:44 UTC
(In reply to William Hubbs from comment #5)
> If you can try this, please do the following.
> 
> In /etc/conf.d/hwclock, change the line that reads:
> 
> #clock_hctosys="YES"
> 
> to:
> 
> clock_hctosys="NO"
> 
> Then, reboot without running your c program or your script modification and
> let me know if that fixes your issue.
> 
> Thanks very much for your help.

With
clock="local"
clock_systohc="YES"
clock_hctosys="NO"
the issue is fixed, without my c program, but i can't tell, exactly, why this setting fixes the issue.
Comment 7 Mike Gilbert gentoo-dev 2014-07-22 00:17:51 UTC
(In reply to mateakos from comment #6)

My theory: clock_hctosys="NO" causes the hwclock init script to run "hwclock --systz --localtime", which does basically does the same thing as your simple program.

When clock_hctosys="YES", the init script runs "hwclock --hctosys --localtime", which does something a little different. This might be a bug in hwclock; the manpage says it is supposed to set the "kernel timezone" in addition to adjusting the system time, but this might be incorrect.
Comment 8 Mike Gilbert gentoo-dev 2014-07-22 01:16:30 UTC
Looking at the kernel source, it appears that the kernel only utilizes the kernel timezone for the 11-minute ntp updates if the very first call to settimeofday has a NULL tv value, thus invoking the "warp clock" behavior.

See the following kernel functions:

kernel/time.c: do_sys_settimeofday(): calls warp_clock
kernel/time.c: warp_clock(): sets persistent_clock_is_local
kernel/time/ntp.c sync_cmos_clock(): reads persistent_clock_is_local

Given the kernel behavior, I would suggest we change /etc/init.d/hwclock to always call hwclock --systz when the hardware clock is in local time, regardless of how clock_hctosys is set.
Comment 9 Mike Gilbert gentoo-dev 2014-07-22 01:22:06 UTC
Created attachment 381308 [details, diff]
Proposed patch
Comment 10 Mike Gilbert gentoo-dev 2014-07-22 01:25:58 UTC
Created attachment 381310 [details, diff]
Revised patch
Comment 11 mateakos 2014-07-22 11:15:58 UTC
(In reply to Mike Gilbert from comment #7)
> (In reply to mateakos from comment #6)
> 
> My theory: clock_hctosys="NO" causes the hwclock init script to run "hwclock
> --systz --localtime", which does basically does the same thing as your
> simple program.
> 
> When clock_hctosys="YES", the init script runs "hwclock --hctosys
> --localtime", which does something a little different. This might be a bug
> in hwclock; the manpage says it is supposed to set the "kernel timezone" in
> addition to adjusting the system time, but this might be incorrect.

Checked with strace.

========

# strace hwclock --systz --localtime 2>&1 | grep timeof
settimeofday(NULL, {4294967176, 0})     = 0

4294967176 = -120 (-120 minutes west)
It sets the timezone, and warp clock behavior. (If it's the very first call of settimeofday)

=========

# strace hwclock --hctosys --localtime 2>&1 | grep timeof
settimeofday({1406027117, 0}, {4294967176, 1406027117}) = 0

It sets the timezone, but not the warp clock behavior, because the first parameter is not NULL.

=========

So basically: "hwclock --systz --localtime" can be used instead of my C program.
Comment 12 mateakos 2014-07-22 11:43:41 UTC
(In reply to Mike Gilbert from comment #10)
> Created attachment 381310 [details, diff] [details, diff]
> Revised patch

Will this patch work correctly, if clock_args is not empty? In that case, I think it might call hwclock with --systz argument even if RTC runs on UTC time.
Comment 13 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2014-07-22 19:17:50 UTC
FYI:
net-misc/adjtimex allows viewing and tuning of the kernel time parameters.

The trick is that the 11-minute-mode is toggled under certain circumstances by ntpd and calls to hwclock.

I mention adjtimex because it allows you to view the status bit for 11-minute-mode (bit 6, value 64):
http://serverfault.com/questions/337930/what-is-the-largest-hardware-clock-update-the-linux-kernel-11-minute-mode-can

There also used to be a sysctl at one point, but I'm not sure what happened to it: /proc/sys/kernel/time/rtc_update
Comment 14 Mike Gilbert gentoo-dev 2014-07-22 20:57:25 UTC
(In reply to mateakos from comment #12)
> Will this patch work correctly, if clock_args is not empty? In that case, I
> think it might call hwclock with --systz argument even if RTC runs on UTC
> time.

You're right, that patch needs a little tweaking. Feel free to propose a revision!
Comment 15 mateakos 2014-07-22 22:18:52 UTC
(In reply to Mike Gilbert from comment #14)
> (In reply to mateakos from comment #12)
> > Will this patch work correctly, if clock_args is not empty? In that case, I
> > think it might call hwclock with --systz argument even if RTC runs on UTC
> > time.
> 
> You're right, that patch needs a little tweaking. Feel free to propose a
> revision!

I was wrong. It's right that it will run hwclock with --systz, but it will run as
"hwclock --systz --utc" which is not a problem, because there is the --utc argument.

# strace hwclock --systz --utc 2>&1 | grep timeof
settimeofday(NULL, {0, 66985616})       = 0
settimeofday(NULL, {4294967176, 0})     = 0

At the first settimeofday call, the minuteswest field is zero, the warp_clock function will run, but won't set the persistent_clock_is_local variable, so no problem. The patch works well in all tested cases.
Comment 16 William Hubbs gentoo-dev 2014-07-23 21:21:20 UTC
Created attachment 381458 [details, diff]
0001-hwclock-always-set-timezone.patch

My understanding of this issue is that we should always set the
kernel's timezone, so this is the patch I propose.

Thoughts?

William
Comment 17 mateakos 2014-07-23 22:28:00 UTC
(In reply to William Hubbs from comment #16)
> Created attachment 381458 [details, diff] [details, diff]
> 0001-hwclock-always-set-timezone.patch
> 
> My understanding of this issue is that we should always set the
> kernel's timezone, so this is the patch I propose.
> 
> Thoughts?
> 
> William

Now I'm using Mike Gilbert's patch, but I think, this should work too.
It's cleaner to always set the kernel's timezone with a separate hwclock run, and then set the time, when it's neccessary with another hwclock run. So I propose this new patch to use by everyone.
Comment 18 Mike Gilbert gentoo-dev 2014-07-23 22:29:22 UTC
(In reply to William Hubbs from comment #16)

Looks good. +1 from me.
Comment 19 William Hubbs gentoo-dev 2014-07-24 22:29:55 UTC
The issue is that OpenRc's hwclock service script only sets the
kernel's timezone when clock_hctosys is set to "NO". This should be done
regardless of the clock_hctosys setting.

I found an older bug for the same issue, so I am closing this bug as a
duplicate.

*** This bug has been marked as a duplicate of bug 434410 ***