Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 561948 - sys-kernel/gentoo-sources-3.18.12 with net-misc/openntpd-5.7_p4-r2: [ntpd] adjtime failed: Invalid argument
Summary: sys-kernel/gentoo-sources-3.18.12 with net-misc/openntpd-5.7_p4-r2: [ntpd] ad...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL: https://forums.gentoo.org/viewtopic-t...
Whiteboard:
Keywords:
Depends on: 580026
Blocks:
  Show dependency tree
 
Reported: 2015-10-01 08:06 UTC by sphakka
Modified: 2016-06-04 00:03 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sphakka 2015-10-01 08:06:22 UTC
Struggling with my clock out of sync since some time, I stumbled upon this post on gentoo forums

  https://forums.gentoo.org/viewtopic-t-1013204-highlight-openntpd.html

Since the issue should have been fixed in kernel v3.18.9, this might be regression or a new mutant... Here are the relevant logged symptoms:

-----------------8<------------------
Sep 30 21:23:01 [ntpd] peer 82.197.164.46 now valid
Sep 30 21:24:03 [ntpd] ntp engine exiting
Sep 30 21:24:03 [ntpd] dispatch_imsg in main: pipe closed
Sep 30 21:24:03 [ntpd] Terminating
Sep 29 19:35:45 [kernel] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes)
Sep 29 19:35:48 [/etc/init.d/ntpd] WARNING: ntpd will start when net.wlan0 has started
Sep 29 19:35:52 [ntpd] ntp engine ready
Sep 29 19:36:09 [ntpd] peer 46.22.26.12 now valid
Sep 29 19:36:09 [ntpd] peer 92.42.186.250 now valid
Sep 29 19:36:11 [ntpd] peer 195.186.1.101 now valid
Sep 29 19:36:11 [ntpd] peer 195.186.4.101 now valid
Sep 29 19:36:11 [ntpd] peer 77.109.139.83 now valid
Sep 29 19:36:12 [ntpd] peer 91.235.212.22 now valid
Sep 29 19:36:12 [ntpd] peer 195.186.4.100 now valid
Sep 29 19:36:12 [ntpd] peer 213.160.44.193 now valid
Sep 29 19:36:12 [ntpd] peer 192.33.96.102 now valid
Sep 29 19:36:12 [ntpd] peer 91.234.160.19 now valid
Sep 29 19:36:12 [ntpd] peer 82.220.2.2 now valid
Sep 29 19:36:12 [ntpd] peer 77.245.18.26 now valid
Sep 29 19:36:13 [ntpd] peer 5.148.175.134 now valid
Sep 29 19:36:15 [ntpd] peer 195.186.1.100 now valid
Sep 29 19:36:16 [ntpd] peer 81.94.123.17 now valid
Sep 29 19:36:18 [ntpd] peer 82.197.188.130 now valid
Sep 29 19:37:16 [ntpd] adjusting local clock by 135630.767628s
Sep 29 19:37:16 [ntpd] adjtime failed: Invalid argument
----------------->8------------------

I don't know if the above warning about NTPD waiting for net to be ready is relevant here...

Setting ther time by hand temporarily fixes the problem. Apparently, on shutdown, the HW clock is not synced so that time is screwed on next boot.

The same happens with stable "net-misc/openntpd-4.0_pre20080406". If I understand correctly, openNTPD cannot sync the HW clock, though the kernel should take care of it, right? Indeed, it has been working OK for quite a bit... 


Reproducible: Always

Steps to Reproduce:
1. Boot up
2. Check time and/or logs: if wrong correct by hand with 'date -s'
3. Reboot
Actual Results:  
HW clock not synced, sys time screwed again.

Expected Results:  
HW clock synced, sys time OK.

Portage 2.2.20.1 (python 2.7.10-final-0, default/linux/amd64/13.0/desktop, gcc-4.8.5, glibc-2.20-r2, 3.18.12-gentoo x86_64)
=================================================================
System uname: Linux-3.18.12-gentoo-x86_64-AMD_Turion-tm-_64_X2-with-gentoo-2.2
KiB Mem:     3920908 total,   1573876 free
KiB Swap:    3148736 total,   3148736 free
Timestamp of repository gentoo: Wed, 30 Sep 2015 13:30:01 +0000
sh bash 4.3_p39
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
app-shells/bash:          4.3_p39::gentoo
dev-java/java-config:     2.2.0::gentoo
dev-lang/perl:            5.20.2::gentoo
dev-lang/python:          2.7.10::gentoo, 3.3.5-r1::gentoo, 3.4.3::gentoo
dev-util/cmake:           3.2.2::gentoo
dev-util/pkgconfig:       0.28-r2::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.17::gentoo
sys-apps/sandbox:         2.6-r1::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69::gentoo
sys-devel/automake:       1.11.6-r1::gentoo, 1.12.6::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo
sys-devel/binutils:       2.25.1-r1::gentoo
sys-devel/gcc:            4.7.3-r1::gentoo, 4.8.5::gentoo
sys-devel/gcc-config:     1.7.3::gentoo
sys-devel/libtool:        2.4.6::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers)
sys-libs/glibc:           2.20-r2::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

unsupported
    location: /var/portage/overlay/unsupported
    masters: gentoo
    priority: 0

sunrise
    location: /var/lib/layman/sunrise
    masters: gentoo
    priority: 1

Installed sets: @audio, @dev, @emacs, @emul, @fonts, @gkrellm, @graphix, @net, @office, @utilz, @video, @xfce
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/fax /usr/share/gnupg/qualified.txt /var/spool/fax/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://mirror.switch.ch/ftp/mirror/gentoo/ ftp://mirror.switch.ch/mirror/gentoo/"
INSTALL_MASK="/usr/lib/systemd/"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
USE="3dnow 3dnowext X a52 aac acpi alsa amd64 amr apng bash-completion berkdb bittorrent bluetooth branding bzip2 cairo calendar caps cdda cddb cdparanoia cdr cleartype cli consolekit corefonts cracklib crypt cups curl cvs cxx dbus djvu dts dvd dvdr ebook emacs embedded emboss enchant encode exif fam fbcon ffmpeg firefox flac fortran gdbm gif git glamor gnutls gpm h323 http hunspell iconv icu id3tag jabber jack jp2k jpeg jpeg2k kontact kpathsea ladspa lame laptop latex lcms ldap libnotify libsamplerate lxde mad matroska mmx mmxext mng modules mp3 mp4 mpeg mplayer multilib musepack musicbrainz mysql ncurses nls nptl ntfs ntfsprogs ofx ogg opengl openmp openvg opus pam pango pcre pdf pgo png policykit ppds quicktime readline real rtmp samba sdl seamonkey seccomp session spell sql sqlite sse sse2 ssh ssl startup-notification svg system-cairo system-icu system-jpeg system-libvpx system-sqlite taglib tcpd threads thunar tiff tordns truetype udev udisks unicode upower usb v4l v4l2 video vlc vorbis wavpack wifixvfb wxwidgets x264 xcb xetex xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="hda-intel usb-audio" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext sse sse2 sse3" DRACUT_MODULES="crypt lvm" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="keyboard mouse synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" SANE_BACKENDS="epson2 epkowa" USERLAND="GNU" VIDEO_CARDS="nvidia modesetting vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Comment 1 sphakka 2015-10-09 09:27:36 UTC
Temporary fix, after setting the correct date, is to use 

  hwclock -w

to force HW clock synchronisation. Even though this prevents the adjtime errors (provided it's done every day), at boot just a day after, the hw/sys clock shows a skew of some minutes... I wonder if I have some broken HW (CMOS battery was replaced some months ago).
Comment 2 sphakka 2015-10-12 09:49:38 UTC
Further investigations. It appears that `hwclock` is unable to sync HW -> SYS clock (HW clock reset on BIOS set-up before booting):

-----------------------------------------
flexzo ~ # date
Mon Oct 12 11:30:10 CEST 2015
flexzo ~ # hwclock 
2015-10-12T11:32:33 CEST  .233537 seconds
flexzo ~ # hwclock -s
flexzo ~ # hwclock 
2015-10-12T11:32:55 CEST  .124179 seconds
flexzo ~ # date
Mon Oct 12 11:30:37 CEST 2015
...
# try again
flexzo ~ # hwclock -s -D
hwclock from util-linux 2.26.2
Using the /dev interface to the clock.
Last drift adjustment done at 1444584130 seconds after 1969
Last calibration done at 1444584130 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2015/10/12 09:43:54
Hw clock time : 2015/10/12 09:43:54 = 1444643034 seconds since 1969
Time since last adjustment is 58904 seconds
Calculated Hardware Clock drift is -143.637851 seconds
Calling settimeofday:
	tv.tv_sec = 1444642891, tv.tv_usec = 637851
	tz.tz_minuteswest = -120
flexzo ~ # date
Mon Oct 12 11:42:12 CEST 2015
-----------------------------------------

That ~2' skew is not corrected, and, I guess, it cumulates across reboots... to the point that `adjtime` fails!?

For information, `/etc/init.d/hwclock` is configured with two sync -- provided that the default values are honoured:

--------------------
#clock_hctosys="YES"
#clock_systohc="YES"
--------------------


The funny point is that SYS -> HW clock sync actually works:

-------------------------------------
flexzo ~ # date
Mon Oct 12 11:45:41 CEST 2015
flexzo ~ # date -s "2015-10-12 11:47"
Mon Oct 12 11:47:00 CEST 2015
flexzo ~ # 
flexzo ~ # date
Mon Oct 12 11:47:03 CEST 2015
flexzo ~ # hwclock 
2015-10-12T11:48:32 CEST  .592900 seconds
flexzo ~ # hwclock -w
flexzo ~ # hwclock 
2015-10-12T11:47:16 CEST  .953904 seconds
flexzo ~ # date
Mon Oct 12 11:47:19 CEST 2015
-------------------------------------
Comment 3 Paul B. Henson 2015-10-20 01:37:59 UTC
Hmm, if I understand this right your hardware clock drifts, and is not being set to the system clock on shutdown/reboot, resulting in a massive time skew when the system comes up.

First, I believe the hwclock init script does *not* sync unless you explicitly uncomment the line in the conf.d file, it's not a default but an example. So if you want to sync the hw clock at shutdown, you should uncomment the line in the config.

Second, I'd recommend adding the -s option to NTPD_OPTS in /etc/conf.d/ntpd, that way if the time is too far off at startup it will just set it rather than try to tweak the clock rate to slowly approach it.

Arguably, there might still be a bug here; looks like ntpd might be trying to adjust the time beyond the allowed range. However, from a practical perspective, if the time is that far off, it will probably never reach the right value, so generating an error rather than capping the delta is possibly a better outcome from a communication perspective anyway :).
Comment 4 sphakka 2015-11-09 10:34:03 UTC
Thanks for the tips, Paul.

(In reply to Paul B. Henson from comment #3)
> Hmm, if I understand this right your hardware clock drifts, and is not being
> set to the system clock on shutdown/reboot, resulting in a massive time skew
> when the system comes up.

Correct.

> 
> First, I believe the hwclock init script does *not* sync unless you
> explicitly uncomment the line in the conf.d file, it's not a default but an
> example. So if you want to sync the hw clock at shutdown, you should
> uncomment the line in the config.

Gotcha! Indeed, that wasn't clear to me. Explicitly setting them does change the game. My set-up is now:

  clock_hctosys="NO"
  clock_systohc="YES"

> Second, I'd recommend adding the -s option to NTPD_OPTS in /etc/conf.d/ntpd,
> that way if the time is too far off at startup it will just set it rather
> than try to tweak the clock rate to slowly approach it.

I did this also and now my system is properly synchronized :-)

However, reading again here,

  https://wiki.gentoo.org/wiki/System_time#OpenRC

I understand that OpenRC's "hwclock" should be *disabled*. Thus, I'll do further testing...
Comment 5 Paul B. Henson 2015-12-06 00:39:20 UTC
Hmm, per the wiki entry the openrc hwclock init script should be disabled if you're using a kernel that both includes the feature for dealing with the hardware clock directly and has that feature enabled.

It seems it would be better for the kernel to set the system clock from the hardware clock rather than an init script, as it will occur much earlier in the boot process.

However, it doesn't look like the kernel sets the hardware clock from the system clock on shutdown; rather, it seems some ntp clients when running under linux support setting the hardware clock themselves. The wiki says openntpd isn't one of them, and I think that's correct, I don't recall seeing that feature.

So, if you want to completely get rid of the openrc init script, you'd need to use a different ntp client that supported setting the hardware clock. Alternatively, you could configure the kernel to take care of hw-to-sys at boot, and have the init script just do the sys-to-hw at shutdown. That's probably what I'm going to do, I like openntpd :).

I'll take a look when I get a chance at what would be involved in adding the ability to set the hw clock to openntpd, but dunno how long that would take.
Comment 6 sphakka 2015-12-09 16:22:24 UTC
(In reply to Paul B. Henson from comment #5)
> So, if you want to completely get rid of the openrc init script, you'd need
> to use a different ntp client that supported setting the hardware clock.
> Alternatively, you could configure the kernel to take care of hw-to-sys at
> boot, and have the init script just do the sys-to-hw at shutdown. That's
> probably what I'm going to do, I like openntpd :).
> 

Indeed, I configured my kernel as explained in the wiki and also removed the 'hwclock' init script, but I kept openntpd. Interestingly, what I see now is that the system time is mostly OK, there's just a small skew between sys and HW (not critical for now as this is just on a laptop):

  # date 
  Wed Dec  9 17:08:41 CET 2015
  # hwclock 
  2015-12-09T17:09:24 CET  .201991 seconds

I guess that's because no sys-to-hw is actually done on shutdown: that would indeed fulfil the missing openntpd feature. Meanwhile, I'll try chrony.
Comment 7 Paul B. Henson 2016-04-15 03:39:11 UTC
(In reply to sphakka from comment #6)
> 
> I guess that's because no sys-to-hw is actually done on shutdown: that would
> indeed fulfil the missing openntpd feature. Meanwhile, I'll try chrony.

OpenNTPD 5.9 added the ability to sync the hardware clock on linux. Bug 580026 has an updated ebuild for it that will hopefully get commited soon if you want to try it out.
Comment 8 sphakka 2016-04-15 08:56:44 UTC
(In reply to Paul B. Henson from comment #7)
> OpenNTPD 5.9 added the ability to sync the hardware clock on linux. Bug
> 580026 has an updated ebuild for it that will hopefully get commited soon if
> you want to try it out.

Thanks for the news. Actually I'm with chrony on kernel 4.x (full RTC <-> SYS sync support) since last December and observed no problem -- drift management seems to handle well disconnection periods. I guess this is a really good setup for a laptop...