Bug 2521 - clock setting issue with systemd
Summary: clock setting issue with systemd
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
: 2742 2957 (view as bug list)
Depends on:
Blocks: 2120
  Show dependency treegraph
 
Reported: 2011-08-27 05:27 CEST by Dave Hodgins
Modified: 2011-12-09 15:54 CET (History)
4 users (show)

See Also:
Source RPM: systemd-34-1.mga2.src.rpm
CVE:
Status comment:


Attachments
/lib/systemd/system/hwclock-load.service (1.17 KB, text/plain)
2011-09-16 05:13 CEST, Dave Hodgins
Details
/lib/systemd/system/hwclock-save.service (493 bytes, application/octet-stream)
2011-09-16 05:15 CEST, Dave Hodgins
Details
RealTimeIsUniversal.reg (984 bytes, application/octet-stream)
2011-10-14 03:56 CEST, Dave Hodgins
Details

Description Dave Hodgins 2011-08-27 05:27:17 CEST
In /var/log/dmesg, I see
systemd[1]: RTC configured in localtime, applying delta of -240 minutes to system time.

but, it's actually applying a delta of +240 minutes, so the clock is set 8
hours ahead of the real localtime.

# cat /etc/sysconfig/clock
ZONE="Canada/Eastern"
UTC=false
ARC=false
Manuel Hiebel 2011-09-03 22:41:23 CEST

Assignee: bugsquad => eugeni

Comment 1 Guillaume Rousse 2011-09-14 13:03:49 CEST
/etc/sysconfig/clock seems to be only used by ntpd sysinit initscript, so it's quite normal for him to be ignored by systemd. However, I can't figure out how to configure clock usage in systemd, excepted through ntpd.

CC: (none) => guillomovitch

Comment 2 Guillaume Rousse 2011-09-14 13:04:42 CEST
*** Bug 2742 has been marked as a duplicate of this bug. ***
Comment 3 Dave Hodgins 2011-09-16 05:13:57 CEST
Created attachment 795 [details]
/lib/systemd/system/hwclock-load.service

Copied from Mandriva 2011.  After copying, ran
systemctl enable hwclock-load.service

After a reboot, time is correct.
Comment 4 Dave Hodgins 2011-09-16 05:15:38 CEST
Created attachment 796 [details]
/lib/systemd/system/hwclock-save.service

Also copied from Mandriva, but the systemctl enable fails,
so I don't think it'll update the hardware clock on shutdown/reboot.
Comment 5 Bernard MAUDRY 2011-10-07 13:28:14 CEST
*** Bug 2957 has been marked as a duplicate of this bug. ***

CC: (none) => ramaspaceship

Manuel Hiebel 2011-10-07 14:40:16 CEST

Blocks: (none) => 2120

Comment 6 Guillaume Rousse 2011-10-13 10:28:07 CEST
Interesting information: systemd doesn't support localtime for HW clock:
https://wiki.archlinux.org/index.php/Systemd#Why_does_systemd_not_support_the_RTC_being_in_localtime.3F
Comment 7 Guillaume Rousse 2011-10-13 10:41:16 CEST
According to https://bugzilla.redhat.com/show_bug.cgi?id=707877, hwclock-load.service and hwclock-save.service are deprecated in systemd. BTW, I couldn't find them in mandriva anymore.
Comment 8 Dave Hodgins 2011-10-14 03:56:49 CEST
Created attachment 957 [details]
RealTimeIsUniversal.reg

Now that I know about the reg key to have windows work with the hardware
clock set to utc, I'm changing my system.

Perhaps we should consider only supporting hardware clock with utc.

In the first boot, provide a link to the attached registry file, and an explanation that existing Mageia or Mandriva systems can be changed using
mcc/System/Manage Date and Time, Change Time zone/Select correct time zone
normally, then answer yes to the question "Is your hardware clock set to
 GMT", or by manually changing the word LOCAL to UTC in /etc/adjtime,
and changing UTC=false to UTC=true in /etc/sysconfig.clock.
Comment 9 Bernard MAUDRY 2011-10-14 23:36:50 CEST
WARNING: The attached registry file seems to be only for the EASTERN timezone, not everywhere. May-be the only helpful value inside it is '"RealTimeIsUniversal"=dword:00000001' as suggested by the Arch Linux wiki link above. I will make a try next time I use Windows.

If using UTC only is chosen (why not but a fix for systemd is needed anyway, as it is buggy here: it should detect local time for hardware clock and not assume UTC only), no manual change should be done by the user (I mean that system files must be adjusted by the install tool).

Anyway, this could be of no interest for connected computers if ntp worked (see bug 2958), and this is the reason why the hwclock-xxxx-service scripts were dropped.
Comment 10 Dave Hodgins 2011-10-15 04:01:09 CEST
(In reply to comment #9)
> WARNING: The attached registry file seems to be only for the EASTERN timezone,
> not everywhere. May-be the only helpful value inside it is
> '"RealTimeIsUniversal"=dword:00000001' as suggested by the Arch Linux wiki link
> above. I will make a try next time I use Windows.

Sorry, I didn't examine the file contents after exporting it from regedit
(after adding it as sper the Arch Linux wiki link).  I thought I had only
exported the one key, not the group of keys.
Comment 11 D Morgan 2011-10-22 23:34:05 CEST
can you test with systemd + initscripts from testing to tell if this is still valid ?

CC: (none) => dmorganec

Comment 12 Dave Hodgins 2011-10-24 02:03:29 CEST
Closer but still off.

Clock time was roughly 1930 (2330 utc).

Changed UTC to local in /etc/adjtime, and set UTC to false
in /etc/sysconfig/clock.

Rebooted, used the bios setup to set the time to 1930.

After booting into cauldron with systemd and initscritps 9.25-0.3.mga2,
the date command shows the local time as 2330.

So it is adding 4 hours to the hardware clock, as it should, to
figure out what the current utc time is, but it's using that
result as localtime, instead of as the utc time.

Btw, I figured out how to avoid the lockup at shutdown.  The
service vnstat has to be uninstalled, not just disabled.

There seems to be a problem with systemd trying to run vnstat
when eth0 is stopped, even if it's been disabled.
Comment 13 Bernard MAUDRY 2011-11-06 20:54:44 CET
Since the last update, without changing anything in the clock configuration, the loca
Comment 14 Bernard MAUDRY 2011-11-06 20:55:27 CET
Since the last update, without changing anything in the clock configuration,
the local time is now correctly displayed.
Comment 15 Manuel Hiebel 2011-11-23 18:59:34 CET
(In reply to comment #14)
> Since the last update, without changing anything in the clock configuration,
> the local time is now correctly displayed.

Same for all people here ?

Assignee: eugeni => bugsquad

Comment 16 Dave Hodgins 2011-11-23 21:29:56 CET
Looks good here.  Just to be sure it wasn't just ntpd fixing the time, I
rebooted into a cauldron install with the ethernet disconnected.  The
time was still set correctly.
Comment 17 Manuel Hiebel 2011-11-23 23:24:40 CET
Ok thanks, feel free to reopen

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 18 Doug Laidlaw 2011-11-28 21:27:04 CET
I have a similar problem with Mageia 2 Alpha.  I have installed the KDE version Live CD to my hard drive.

DMESG:      RTC time:  6:57:09, date: 11/29/11

This was correct local time, but the digital clock was showing 17:57

My timezone is Australian Eastern Daylight Saving: GMT + 11 hours. HW clock is NOT set to GMT.

If I correct the clock in Mga 2, I change the hardware clock, and it is wrong elsewhere.  I am not "techy" enough to give the same details as Dave.

Status: RESOLVED => REOPENED
CC: (none) => laidlaws
Resolution: FIXED => (none)

Comment 19 Dave Hodgins 2011-11-28 22:44:50 CET
It works properly now when systemd is used, which is what this bug report
was raised for.  There is a separate bug for getting the time correct when
using sysvinit.  See bug 3512.

Please confirm your system is using sysvinit, and if so, re-close this bug
as a duplicate of 3512.
Comment 20 Doug Laidlaw 2011-11-28 22:56:04 CET
This is over my head, but I haven't changed anything from a standard installation, so I suppose that it is still sysvinit.
Comment 21 Dave Hodgins 2011-11-28 23:37:29 CET
Easiest way to confirm which is being used is to run the command
ps 1
If it shows the command is init, then sysvinit is being used.
Otherwise, it'll show /bin/systemd.
Comment 22 Doug Laidlaw 2011-11-29 01:04:11 CET
Before I read that I checked that there is the usual /etc/init.d hierarchy.  That is a clue, I believe.  I will close this bug and do nothing until I have downloaded the DVD.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Comment 23 Doug Laidlaw 2011-11-29 05:07:32 CET
Changed status to "Duplicate of Bug 3512."

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

Resolution: FIXED => DUPLICATE

Comment 24 Guillaume Rousse 2011-12-07 09:50:31 CET
This is absolutly not a duplicate: #3512 is about problem when using sysvinit, when this is about a problem using systemd.

Status: RESOLVED => REOPENED
Resolution: DUPLICATE => (none)

Guillaume Rousse 2011-12-07 09:52:27 CET

Summary: Clock is set to utc + 4 hours when it should be utc - 4 hours. => clock setting issue with systemd

Comment 25 Guillaume Rousse 2011-12-09 15:54:19 CET
OK, I finally manage to fix the issue.

Contrarily to what is stated in the arch wiki, systemd perfectly support hardware clock in either local or universal time. /etc/adjtime content should however match the reality, otherwise systemd will apply a wrong correction.

hwclock --systohc --utc/--localtime will update /etc/adjtime, and dmeg | grep RTC will tell what systemd does at boot time.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.