LinuxQuestions.org - [SOLVED] Hardware clock being forced to UTC time

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Hardware clock being forced to UTC time (https://www.linuxquestions.org/questions/slackware-14/hardware-clock-being-forced-to-utc-time-4175477525/)

Hardware clock being forced to UTC time

I have four systems running Slackware current with the hardware clock being forced to UTC time. I'm in the eastern time zone (EDT) and the system times are being sync by NTP. If I set the hardware clock to my current system time, it drift back to the UTC time after a few hours. Even after running:

Code:

hwclock --localtime --systohc

Here is my /etc/adjtime

Code:

0.000000 1379470547 0.000000

1379470547

LOCAL

Try running timeconfig again to make sure that your /etc/localtime is correct.

Pat,
I ran 'timeconfig' and selected my timezone. However, there was no change to the /etc/hardwareclock file. Actually, the file was update, but the content is the same where my hardware clock is listed as 'localtime'. Is there anyway to read to content of '/etc/localtime'?

Just after running timeconfig on one of the systems, here is the current time shift:

Code:

hwclock -r

Wed 18 Sep 2013 02:45:50 AM EDT  -0.829614 seconds

date

Tue Sep 17 22:45:55 EDT 2013

Thanks Pat. timeconfig did the trick.

Turns out the timeconfig didn't work. localtime is set to the correct timezone, however the hardware clock is being set to UTC time. This is not an issue if the system is shutdown/restart successfully since rc.0/rc.6 sets the hardware clock. However, if I loose power, the system starts with UTC time. This is shown in the dmesg:

Code:

[ 6.239104] rtc_cmos 00:07: setting system clock to 2013-09-29 17:12:51 UTC (1380474771)

Is the UTC being used by default? How do I change this?

Quote:

Originally Posted by tux_dude (Post 5036932)

Turn out the timeconfig didn't work. localtime is set to the correct timezone, however the hardware clock is being set to UTC time. This is not an issue if the system is shutdown/restart successfully since rc.0/rc.6 sets the hardware clock. However, if I loose power, the system starts with UTC time. This is shown in the dmesg:

Code:

[ 6.239104] rtc_cmos 00:07: setting system clock to 2013-09-29 17:12:51 UTC (1380474771)

Is the UTC being used by default? How do I change this?

You can see if the hardware clock is kept in UTC or localtime by checking the contents of /etc/hardwareclock.

Mine is kept in localtime, but my dmesg also shows the time the system clock is set to in UTC. That's normal.

Contents of both hardwareclock and adjtime below. To my knowledge, everything is set to local time. I think it start doing this after the 3.9.x kernel.

Code:

cat /etc/hardwareclock 

# /etc/hardwareclock

#

# Tells how the hardware clock time is stored.

# You should run timeconfig to edit this file.



localtime

Code:

cat /etc/adjtime 

-1759.270939 1380489996 0.000000

1380489996

LOCAL

Just checked all my systems which are on kernel 3.10.12 and they all show the same time symptom. All systems are set to localtime and the timezone is correct. This could have gone unnoticed for a long time as it only occurs when system is not shutdown correctly (ie, i loose power).

Here is the senario:
1. The system boots with hardware clock in local time
2. The system time is also set to local time
3. The system time stays at local time and is updated by NTP
4. The hardware clock is pushed to UTC while the system is on (I am still unable to determine how long this takes to occur)
5. If the system shuts down/reboots normally, during the shutdown the hardware clock is set back to localtime by rc.0/rc.6.
6. If I abruptly loose power without shutting down, the hardware clock remains in UTC so at the next boot, the system is set to UTC. This cause NTP to fail since the time is too far off. Also, this causes the both the system and hardware clock to perpetually drift forward (in my case by 4 hrs) if I keep loosing power.

Sounds like you have a cron job that is periodically updating the hardware clock and forcing UTC.

Quote:

Originally Posted by rknichols (Post 5037008)

Sounds like you have a cron job that is periodically updating the hardware clock and forcing UTC.

I've got a script to update the hwclock to localtime in cron.monthly on some systems. This was to address DST issues where my clock would be an hour off if I lost power after/before DST if I didn't reboot my system within that time. There is absolutely nothing UTC related on these systems.

I rebooted one of my systems 3 hours ago and the hwclock which was fine at boot is now 4hrs ahead. This system does not have the cron.monthly script which update the time. Also, all users except for root have cron disabled.

Here is the content of the that script to rule it out:

Code:

cat /etc/cron.monthly/update_bios_clock.sh 

#!/bin/sh



# Update the System (BIOS) clock once per month

# to keep it in sync with the OS time.

/sbin/hwclock --localtime --systohc

Run a background job that reads the hardware clock every 10 minutes or so and reports when it sees a big change. Hopefully you can correlate that with activity that got logged within that interval.

I did just that and I caught when the hardware clock change (within a 10min window), but no clue as to what changed it. There is no cron, nothing in the syslog or message file. Nothing anywhere.

Code:

DATE: Mon Sep 30 16:38:51 EDT 2013

HW Clock: Mon 30 Sep 2013 04:38:52 PM EDT  -0.985661 seconds

DATE: Mon Sep 30 16:48:52 EDT 2013

HW Clock: Mon 30 Sep 2013 04:48:52 PM EDT  -0.032332 seconds

DATE: Mon Sep 30 16:58:52 EDT 2013

HW Clock: Mon 30 Sep 2013 04:58:53 PM EDT  -0.985637 seconds

DATE: Mon Sep 30 17:08:53 EDT 2013

HW Clock: Mon 30 Sep 2013 09:08:54 PM EDT  -0.719963 seconds

DATE: Mon Sep 30 17:18:54 EDT 2013

HW Clock: Mon 30 Sep 2013 09:18:54 PM EDT  -0.032511 seconds

DATE: Mon Sep 30 17:28:54 EDT 2013

HW Clock: Mon 30 Sep 2013 09:28:55 PM EDT  -0.985732 seconds

DATE: Mon Sep 30 17:38:55 EDT 2013

HW Clock: Mon 30 Sep 2013 09:38:55 PM EDT  -0.032523 seconds

DATE: Mon Sep 30 17:48:55 EDT 2013

HW Clock: Mon 30 Sep 2013 09:48:56 PM EDT  -0.985704 seconds

Code:

ls -l /usr/bin/crontab 

-rws--x--- 1 root root 12760 Sep  7  2012 /usr/bin/crontab*



crontab -l

# If you don't want the output of a cron job mailed to you, you have to direct

# any output to /dev/null.  We'll do this here since these jobs should run

# properly on a newly installed system, but if they don't the average newbie

# might get quite perplexed about getting strange mail every 5 minutes. :^)

#

# Run the hourly, daily, weekly, and monthly cron jobs.

# Jobs that need different timing may be entered into the crontab as before,

# but most really don't need greater granularity than this.  If the exact

# times of the hourly, daily, weekly, and monthly cron jobs do not suit your

# needs, feel free to adjust them.

#

# Run hourly cron jobs at 47 minutes after the hour:

47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null

#

# Run daily cron jobs at 4:40 every day:

40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null

#

# Run weekly cron jobs at 4:30 on the first day of the week:

30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null

#

# Run monthly cron jobs at 4:20 on the first day of the month:

20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null







ls -al /etc/cron.hourly

total 16

drwxr-xr-x  2 root root  4096 Sep  7  2012 ./

drwxr-xr-x 87 root root 12288 Sep 30 05:29 ../

I'm at a complete lost as to where else to look.

How about...

Code:

ps -ef | grep ntpd

...and...

Code:

grep ntp /etc/dhcpcd.conf

...? What do those two commands give?

One of the recent kernels introduced these new options, which sound as if they may be relevant.

CONFIG_RTC_HCTOSYS:
If you say yes here, the system time (wall clock) will be set using the value read from a specified RTC device. This is useful to avoid unnecessary fsck runs at boot time, and to network better.

CONFIG_RTC_SYSTOHC:
If you say yes here, the system time (wall clock) will be stored in the RTC specified by RTC_HCTOSYS_DEVICE approximately every 11 minutes if userspace reports synchronized NTP status.

Also check out the help text on CONFIG_RTC_HCTOSYS_DEVICE:
This device should record time in UTC, since the kernel won't do timezone correction

If you're running your hw_clock on localtime then you probably want to avoid these new RTC options in your kernel config (especially the second one).

P.S. Both appear to be set to Y in config-generic-3.10.12.x64