SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
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'?
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?
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.
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.
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 ../
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.