After installing util-linux-2.22 and rebooting, the system showed me the UTC time instead of the timezoned one. Additionally, the system is configured to clock_systohc="YES", so it thinks the wrongly displayed time is the local time, and sets the UTC time to -2 hours (timezone Europe/Berlin). So with every reboot, it goes from 10:00 to 08:00 to 06:00. Back to the future, yeah... The link is the same bug I found for ArchLinux while googling for it. So, here is the commit, which seems to have to do something with this matter: http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=839be2ba6b44fa9dc927f081d547ebadec9de19c Maybe we need to adapt the /etc/init.d/hwclock script. Reproducible: Always
emerge --info Portage 2.2.0_alpha124 (default/linux/amd64/10.0/desktop/gnome, gcc-4.7.1, glibc-2.16.0, 3.6.0-rc4 x86_64) ================================================================= System uname: Linux-3.6.0-rc4-x86_64-AMD_Athlon-tm-_X2_Dual_Core_Processor_BE-2400-with-gentoo-2.2 Timestamp of tree: Sun, 09 Sep 2012 07:00:01 +0000 app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12 dev-lang/python: 2.7.3-r2 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.10.5 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.11.6, 1.12.3 sys-devel/binutils: 2.22.90 sys-devel/gcc: 4.7.1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.5 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo local ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA AdobeFlash-10.3 cadsoft dlj-1.1 ETQW googleearth PUEL RTCW-ETEULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /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" DISTDIR="/var/pms/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles news noinfo parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS=" ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo/ ftp://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/" LANG="de_DE.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/var/pms/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/pms/portage" PORTDIR_OVERLAY="/var/pms/overlay/local" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo caps cdda cdr cli consolekit cracklib crypt css cups curl cxx dbus dri dts dvb dvd dvdr emboss encode evo exif expat ffmpeg firefox flac fontconfig fortran gdbm gif gimp gmp gnome gnome-keyring gnome-online-accounts gstreamer gtk iconv idn jpeg lame latex lcdfilter lcms libnotify libsamplerate lzo mad mmx mmxext mng modules mp3 mp4 mpeg mplayer mudflap multilib musepack nautilus ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pppd pulseaudio qt3support raw readline sdl session sndfile socialweb spell sse sse2 sse3 ssl startup-notification svg tetex theora threads tiff truetype udev udisks unicode upower usb vdpau vorbis wavpack wma wmf wxwidgets x264 xcb xinerama xml xv xvid xvmc zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="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" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" 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 ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="de" LIRC_DEVICES="devinput inputlirc" PHP_TARGETS="php5-3" PYTHON_TARGETS="python2_7" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="gt68xx genesys" USERLAND="GNU" VIDEO_CARDS="nvidia" 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: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
hwclock is behaving correctly (see upstream URL). whether we need to adjust openrc's hwclock init.d script, i don't know -- nothing should be running hwclock before the init.d afaik. the description here needs a bit more detail.
I would propose moving the hwclock script to util-linux myself...
(In reply to comment #3) that wouldn't help, nor really make sense. util-linux isn't the only package that provides `hwclock`.
I have the same problem, but pursued a different troubleshooting path, assuming that the kernel itself was carrying out the erroneous system time setting at boot (as a result of CONFIG_RTC_HCTOSYS=y), which I believe is the case. Behavior is normal with the following: util-linux-2.22 installed /etc/conf.d/hwclock variable clock="UTC" and the rest defaults In that scenario, system time is not set at boot by the kernel, but by openrc, and everything works as it did before. Also, I notice this passage in the man page for settimeofday(), which strikes me as identical to the problem here: "Under Linux there are some peculiar "warp clock" semantics associated with the settimeofday() system call 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. No doubt it is a bad idea to use this feature." It seems to me that this is exactly what appears to be happening here. On systems with CMOS clock aligned to UTC and CONFIG_RTC_HCTOSYS=y, the kernel is assuming that the CMOS clock is aligned to local time. Therefore, the problem might be that we are providing the kernel with a non-NULL tz argument. The same man page indicates that use of tz is obsolete. I hope this is not just adding to confusion.
CORRECTION to comment #5 Behavior is normal with the following: util-linux-2.22 installed /etc/conf.d/hwclock variable clock="UTC" and the rest defaults CONFIG_RTC_HCTOSYS=n <--- omitted that
Okay, apparently it's not CONFIG_RTC_HCTOSYS. With or without it enabled, something is erroneously setting system time (and apparently doing so after CONFIG_RTC_HCTOSYS does it's thing). However, if /etc/conf.d/hwclock is not set to "NO", openrc then corrects the problem (apparently by invoking the equivalent of 'hwclock -s'). I still think the behavior sounds like the problem described in the man page, as I quoted above.
(In reply to comment #7) you mean you set clock_hctosys=yes ?
(In reply to comment #8) > (In reply to comment #7) > > you mean you set clock_hctosys=yes ? I mean OpenRC seems to correct whatever is erroneously setting the system clock, because OpenRC defaults to clock_hctosys="yes" unless, in /etc/conf.d/hwclock, one uncomments: #clock_hctosys="no" which effectively changes the variable to: clock_hctosys="no" which apparently prevents OpenRC from correcting whatever is erroneously setting the system clock. The bottom line is that, as things stand, this part of the config file is not true. # However, you can set this to "NO" ifyou are running a modern kernel # with CONFIG_RTC_HCTOSYS set to y and your hardware clock set to UTC. #clock_hctosys="YES" If one does what is suggested, one's system time will be wrong.
I second the "bottom line" just above, that you can, and indeed for at least some cases are advised to, set clock_hctosys="no" even if your rtc is in the local time. I also add a point: although /etc/init.d/hwclock is not called after resuming from s2ram or s2disk, the clock is set correctly without ntp. I don't understand the picture well, so I'd rather describe my entire situation than omitting some. My rtc is in the local timezone, and I set CONFIG_RTC_HCTOSYS=y. I used to have clock_hctosys="NO" until openrc is upgraded from 0.9.8.4 to 0.11.6. Then I commented out the option following the conf.d doc, and booted at least twice successfully after that. Then came my symptom: /etc/init.d/hwclock failed, emitting the message: select() to /dev/rtc to wait for clock tick timed out Then the Linux clock is 9 hours ahead the correct time. (My timezone is +0900.) It persists after several shutdowns. Setting clock_hctosys="no" fixes the problem. (Althouh it's not the point here, the hardware may be buggy. I've shutdown my Gentoo several times since then, but /etc/conf.d/hwclock continues to fail if I comment out "clock_hctosys". Booting MS Win possibly triggered it. I rarely use Windows on this PC.) BTW: I propose to add a line to init.d/hwclock: "# hwclock is provided by several packages, so this script is in openrc." It doesn't harm, and it'll reduce people's doubt which can be avoided. BTW2: The kernel doc may need fix, too. The description of RTC_HCTOSYS_DEVICE says "This device should record time in UTC". (I don't understand well man (2) settimeofday, though.) Regards.
I opened a kernel bugzilla entry [1] a couple of months ago asking a doc fix, but there has not been any response. Could anyone push it a bit? [1] https://bugzilla.kernel.org/show_bug.cgi?id=54571
How is this "unconfirmed" when there's a confirming comment right in the bug?
*** Bug 496024 has been marked as a duplicate of this bug. ***
The issue in this bug was that the hwclock service script did not always set the kernel's time zone. This has been fixed in commit e3bfb68 and will be included in OpenRc-0.13.
