Bug 932863

Summary:	ntp client does not sync the machine clock
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Chris Ward <tjcw>
Component:	Basesystem	Assignee:	E-mail List <bnc-team-screening>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	bwiedemann
Version:	Current
Target Milestone:	---
Hardware:	x86-64
OS:	SUSE Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Chris Ward 2015-05-29 15:52:52 UTC

On my machine, I set up NTP through yast, but it left the machine clock 1 hour slow. I have checked 'date' and 'date -u'; timezone is correct but the clock is off. I think OpenSuSE 13.2 has the same problem as tumbleweed.

Comment 1 Chris Ward 2015-05-29 15:54:10 UTC

I am running tumbleweed current as of 2015-05-29

Comment 2 Bernhard Wiedemann 2015-05-29 16:26:24 UTC

The typical workaround is calling once manually
hwclock -w

normally, if NTPd is running, the 11-minute-sync of the kernel
should update the RTC to the correct time.

Is ntp properly synchronized? check 
ntpq -pn

Is there a MS Windows installed (and sometimes running) on the same machine?
That can cause trouble because it only supports local time
and systemd mostly supports UTC.

Comment 3 Chris Ward 2015-05-29 16:39:20 UTC

I ran 'ntpd -d -g uk.pool.ntp.org' and it synced the clock. I may not be able to reproduce the problem.
The machine is dual-boot with Windows, but I think the time shift is in the opposite direction for that problem. 
There were some error messages with IPv6 addresses in the NTPD log. Is this to be expected ?

Comment 4 Chris Ward 2015-05-29 18:49:41 UTC

I tried setting the clock back with the 'date' command and then rebooting, but ntp then synchronised the time correctly. So I'm closing this bug as 'not reprodicible'.

Comment 5 Bernhard Wiedemann 2015-06-13 18:34:53 UTC

(In reply to Chris Ward from comment #4)
> I tried setting the clock back with the 'date' command and then rebooting,
> but ntp then synchronised the time correctly. So I'm closing this bug as
> 'not reprodicible'.

if you want to do real testing, you also need to call hwclock -w
after changing the clock to an incorrect time.