| View previous topic :: View next topic |
| Author |
Message |
cgmoller
n00b
Joined: 21 Sep 2006
Posts: 56
Location: Boston, MA, USA
|
 Posted: Thu Apr 21, 2011 11:39 pm Post subject: Time is off by UTC offset |
 |
|
Hi -
I am having a similar problem to that discussed here: https://forums.gentoo.org/viewtopic-t-870979-highlight-ntp.html including the link on HOWTO: Clock, Time, UTC Dual boot with Windows.
Yet I am still unable to resolve the issue.
Some details:
The systems is Linux only - does not dual boot Windows.
Hardware clock is set to Tokyo local time
/etc/localtime = Asia/tokyo (copied not symlinked)
The active / enabled parts of /etc/conf.d/clock are:
| Code: | CLOCK="local"
TIMEZONE="Asia/Tokyo"
CLOCK_OPTS=""
CLOCK_SYSTOHC="no"
|
similarly, the active / enabled parts of /etc/ntp.conf are:
| Code: | server 10.224.49.180
server 10.224.193.147
server 10.240.226.207
server 10.232.71.196
driftfile /var/lib/ntp/ntp.drift
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
logfile /var/log/ntp.log
|
and for /etc/conf.d/ntp-client:
| Code: | NTPCLIENT_CMD="sntp"
NTPCLIENT_OPTS="-P no -r 10.224.49.180 10.224.193.147 10.240.226.207 10.232.71.196"
|
The output of "date" is correct including the timezone = "JST" i.e. "Thu Apr 21 09:30:24 JST 2011" (only after manually setting the time)
The timeserver is in a Sydney Australia data center that is 1 hour ahead of me. There are no firewalls between the two. Note the very large offset
| Code: |
# ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
aoauspnt02a.sta 10.224.49.181 2 u 20 64 1 145.049 -323942 0.001
aoauswnt02a.sta 10.224.49.181 2 u 19 64 1 135.214 -323942 0.001
aojptsnt02a.sta 192.250.xxx.xxx 2 u 18 64 1 1.771 -323942 0.001
aohkshnt02a.sta 192.250.xxx.xxx 2 u 17 64 1 59.992 -323942 0.001
# ntpq -c readvar
assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.4p7@1.1607-o Thu Sep 30 10:18:44 UTC 2010 (1)",
processor="x86_64", system="Linux/2.6.37-gentoo-r4", leap=11,
stratum=16, precision=-20, rootdelay=0.000, rootdispersion=1.200,
peer=0, refid=INIT,
reftime=00000000.00000000 Thu, Feb 7 2036 6:28:16.000, poll=6,
clock=d15bbb60.14bceed2 Fri, Apr 22 2011 8:31:28.081, state=1,
offset=0.000, frequency=-9.734, jitter=0.001, noise=0.001,
stability=0.000, tai=0
|
| Code: |
# sntp -r 10.224.49.180
The time correction is -32451.039 +/- 0.051+0.002 seconds
Do you want to correct the time anyway? n
OK - quitting
|
It is saying that it is off by 9 hours (the delta between here and GMT)
help |
|
| Back to top |
|
 |
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2038
Location: United Kingdom
|
| Posted: Fri Apr 22, 2011 12:34 am Post subject: |
|
|
If you have CLOCK_SYSTOHC="no", is your hardware clock being updated to the current local time? If you are not updating the hardware clock to local time, the next time you boot it will still have an offset. Try making CLOCK_SYSTOHC="yes" to see if that solves your problem.
A few other things to consider:
Are you sure your PC is using /etc/init.d/clock, or is it actually using /etc/init.d/hwclock?
| Code: | rc-update show -v | grep clock
rc-status boot | grep clock |
I never got sntp to work, so I use either ntpdate or ntpd (either works) in /etc/conf.d/ntp-client:
| Code: | # /etc/conf.d/ntp-client
# Command to run to set the clock initially
# Most people should just leave this line alone ...
# however, if you know what you're doing, and you
# want to use ntpd to set the clock, change this to 'ntpd'
#NTPCLIENT_CMD="ntpdate"
#NTPCLIENT_CMD="sntp"
NTPCLIENT_CMD="ntpd"
# Options to pass to the above command
# This default setting should work fine but you should
# change the default 'pool.ntp.org' to something closer
# to your machine. See http://www.pool.ntp.org/ or
# try running `netselect -s 3 pool.ntp.org`.
#NTPCLIENT_OPTS="-s -b -u \
# 0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org \
# 2.gentoo.pool.ntp.org 3.gentoo.pool.ntp.org"
# Following is for sntp (but does not work for some reason):
#NTPCLIENT_OPTS="-s \
# 0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org \
# 2.gentoo.pool.ntp.org 3.gentoo.pool.ntp.org"
# Following is for ntpd:
NTPCLIENT_OPTS="-g -q" |
If not already installed, install the NTP daemon and client software:
| Code: | | emerge -1v net-misc/ntp |
Add the NTP daemon to the default runlevel so that it is started automatically every time you start your PC:
| Code: | | rc-update add ntpd default |
If not already done, check that /etc/conf.d/clock (hwclock if using Baselayout-2/OpenRC) is configured to set the hardware clock every time you shut down your PC.
Note that, by default, the NTP daemon won't correct all in one go a time difference between your system clock and the remote NTP server if that difference is above a certain size. If you want to override the default behaviour, i.e. allow the NTP daemon to make a large first adjustment to the system clock, you can set the environment variable NTPD_OPTS in the /etc/conf.d/ntpd file as follows:
Alternatively (or as well as), you could run the init script ntp-client at start up, which would synchronise your system clock with the remote NTP server once only:
| Code: | | /etc/init.d/ntp-client start |
You could also add ntp-client to the default runlevel so that it is run automatically every time you start up your PC, to do a single synchronisation at start-up. The problem with automatically running ntp-client at start up, though, is that ntp-client may run before your network connection is established, in which case ntp-client would not have been able to synchronise your system clock with the remote NTP server. One way is to start the ntp-client initscript from /etc/conf.d/local (or /etc/local.d/ntp-client.start if you're using OpenRC 0.8.0 or later) after a time delay to allow the network to come up, which is a kludge but works fine for a wired network connection; another way if you're using NetworkManager is to use NetworkManagerDispatcher to start the ntp-client initscript every time a network comes up, which is a nifty way of doing it.
(I've updated that 'How To', to add <<make CLOCK_SYSTOHC="yes">> for /etc/conf.d/clock because, unlike /etc/conf.d/hwclock, it's not the default.)
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
| Back to top |
|
|
cgmoller
n00b
Joined: 21 Sep 2006
Posts: 56
Location: Boston, MA, USA
|
| Posted: Fri Apr 22, 2011 6:22 am Post subject: |
|
|
[*]I set CLOCK_SYSTOHC="yes" - no help.
[*]There is no /etc/init.d/hwclock
[*]Clock is set at Boot and started.
| Code: | # rc-update show -v | egrep "ntp|clock"
clock | boot
ntp-client | default
ntpd | default |
# /etc/conf.d/ntp-client
| Code: | NTPCLIENT_CMD="ntpd"
NTPCLIENT_OPTS="-g" |
results of date and hwclock commands after restarting ntpd and ntp-client
| Code: | # date
Fri Apr 22 05:40:38 JST 2011
# hwclock
Fri Apr 22 14:40:41 2011 -0.281396 seconds
|
ntpq results
| Code: | # ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
aoauspnt02a.sta 10.224.49.181 2 u 27 64 1 134.431 0.738 0.001
aoauswnt02a.sta 10.224.49.181 2 u 26 64 1 135.215 -0.404 0.001
aojptsnt02a.sta 192.250.123.30 2 u 25 64 1 1.670 -2.688 0.001
aohkshnt02a.sta 10.232.71.195 2 u 24 64 1 60.353 -3.127 0.001
# ntpq -c readvar
assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.4p7@1.1607-o Thu Sep 30 10:18:44 UTC 2010 (1)",
processor="x86_64", system="Linux/2.6.37-gentoo-r4", leap=11,
stratum=16, precision=-20, rootdelay=0.000, rootdispersion=0.585,
peer=0, refid=INIT,
reftime=00000000.00000000 Thu, Feb 7 2036 6:28:16.000, poll=6,
clock=d15b942c.e88bc273 Fri, Apr 22 2011 5:44:12.908, state=1,
offset=0.000, frequency=-13.652, jitter=0.001, noise=0.001,
stability=0.000, tai=0 |
The offset from last time is no longer 9 hours (getting closer) but when I restart ntpd or ntp-client it still sets it back to GMT. So now it seems it is not using the timezone properly. Does this reqruie a reboot? I should think not, but to be clear I have only been doing /etc/init.d/ntpd restart |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2026
|
| Posted: Fri Apr 22, 2011 9:14 am Post subject: |
|
|
| Quote: | The systems is Linux only - does not dual boot Windows.
Hardware clock is set to Tokyo local time |
You would do MUCH better if you set the hardware clock to UTC. Linux supports "local" for compatibility with Windows in dual-boot systems, but you don't have that. The only time using UTC might be an issue is if you have a habit of looking at the clock on the BIOS panels 
_________________
Greybeard |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2038
Location: United Kingdom
|
| Posted: Fri Apr 22, 2011 12:05 pm Post subject: |
|
|
I don't find having the hardware clock containing local time any more hassle or more complicated than having it contain UTC. Two of my machines are Linux-only machines and have local time in the hardware clock. In fact, one of those is my media centre which can show live TV (DVB-T), and it is actually easier to have the hardware clock using local time: no messing around with offsets from UTC or configuring applications to show my timezone's time instead of 'local time' (which would be UTC).
cgmoller, just on the off chance you have not seen the thread ntpd & hwclock mess?, it appears his problem was similar, if not identical, to yours, except his timezone is Asia/Hong_Kong instead of Asia/Tokyo. Perhaps you'll spot something you're missing if you read through that.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
| Back to top |
|
|
cgmoller
n00b
Joined: 21 Sep 2006
Posts: 56
Location: Boston, MA, USA
|
| Posted: Tue Apr 26, 2011 11:54 pm Post subject: |
|
|
Well I am absolutely baffled. I have tried a number of strategies. From setting the hwclock to UTC and back to local and updating the settings in /etc/conf.d/clock. There is some new information but still confused.
Current Status:
hwclock is set to Tokyo local time.
# cat /etc/conf.d/clock | egrep -v "^#|^$"
| Code: | CLOCK="local"
TIMEZONE="Asia/Tokyo"
CLOCK_OPTS=""
CLOCK_SYSTOHC="yes"
CLOCK_ADJTIME=""
|
# cat /etc/conf.d/ntp-client | egrep -v "^#|^$"
| Code: | NTPCLIENT_CMD="ntpd"
NTPCLIENT_OPTS="-g -q" |
# cat /etc/conf.d/ntpd | egrep -v "^#|^$"
| Code: | | NTPD_OPTS="-u ntp:ntp" |
# ntpq -c peers
| Code: | remote refid st t when poll reach delay offset jitter
==============================================================================
-aoauspnt02a.sta 10.224.49.181 2 u 60 64 377 134.578 1.941 1.033
*aoauswnt02a.sta 10.224.49.181 2 u 54 64 377 135.157 1.196 1.352
+aojptsnt02a.sta 192.250.123.30 2 u 54 64 377 1.638 -2.337 0.883
+aohkshnt02a.sta 10.232.71.195 2 u 58 64 377 59.869 -2.557 0.979 |
Note: offset is minimal
# ntpq -c readvar
| Code: | assID=0 status=0694 leap_none, sync_ntp, 9 events, event_peer/strat_chg,
version="ntpd 4.2.4p7@1.1607-o Thu Sep 30 10:18:44 UTC 2010 (1)",
processor="x86_64", system="Linux/2.6.37-gentoo-r4", leap=00, stratum=3,
precision=-20, rootdelay=61.257, rootdispersion=52.431, peer=42624,
refid=10.232.71.196,
reftime=d160a4c9.e65a3006 Tue, Apr 26 2011 1:56:25.899, poll=6,
clock=d160a508.fcf28866 Tue, Apr 26 2011 1:57:28.988, state=4,
offset=-1.155, frequency=-16.943, jitter=2.474, noise=1.828,
stability=0.236, tai=0 |
Note that it is now synchronized and is a stratum 3
Output of date and hwclock commands
| Code: | # date
Tue Apr 26 01:53:59 JST 2011 <-- Incorrect - this is showing UTC time
# hwclock -ur
Tue Apr 26 10:56:43 2011 -0.796982 seconds <-- Incorrect - IF this is supposed to be UTC
# hwclock -r --localtime
Tue Apr 26 10:56:55 2011 -0.171976 seconds <-- Correct as it is reading localtime
|
The hwclock -ru is supposed to be reporting UTC correct?
# tail -f /var/log/ntp.log
| Code: | 26 Apr 10:28:48 ntpd[18807]: synchronized to 10.224.49.180, stratum 2
26 Apr 10:28:48 ntpd[18807]: kernel time sync status change 2001
26 Apr 10:31:02 ntpd[18807]: synchronized to 10.232.71.196, stratum 2
26 Apr 10:33:10 ntpd[18807]: synchronized to 10.224.49.180, stratum 2
26 Apr 10:34:09 ntpd[18807]: synchronized to 10.232.71.196, stratum 2
26 Apr 10:38:31 ntpd[18807]: synchronized to 10.224.193.147, stratum 2
26 Apr 19:39:34 ntpd[18807]: no servers reachable <-- start of testing
26 Apr 19:40:26 ntpd[18807]: ntpd exiting on signal 15
26 Apr 19:40:47 ntpd[19062]: synchronized to 10.224.49.180, stratum 2
26 Apr 10:40:57 ntpd[19062]: time reset -32389.642373 s
26 Apr 10:45:42 ntpd[19121]: synchronized to 10.224.49.180, stratum 2
26 Apr 10:45:42 ntpd[19121]: kernel time sync status change 2001
26 Apr 10:50:02 ntpd[19121]: synchronized to 10.232.71.196, stratum 2
26 Apr 10:51:07 ntpd[19121]: synchronized to 10.224.49.180, stratum 2
26 Apr 10:52:07 ntpd[19121]: synchronized to 10.232.71.196, stratum 2
26 Apr 10:53:15 ntpd[19121]: synchronized to 10.224.193.147, stratum 2
...
26 Apr 13:12:19 ntpd[19121]: synchronized to 10.232.71.196, stratum 2
26 Apr 13:29:36 ntpd[19121]: synchronized to 10.224.193.147, stratum 2
# ls -l /var/log/ntp.log
-rw-r--r-- 1 root root 1417302 Apr 26 04:29 /var/log/ntp.log
|
This output shows when I was switching between UTC and Asia/Tokyo
Note that the time stamp IN the ntp.log file is actually correct, but the timestamp ON the file is incorrect.
More testing - setting hwclock to localtime
| Code: | # date
Tue Apr 26 01:38:10 JST 2011
# hwclock
Tue Apr 26 01:38:21 2011 -0.640766 seconds
# date 04261038
Tue Apr 26 10:38:00 JST 2011
# hwclock -w --systohc
# date
Tue Apr 26 10:39:56 JST 2011
# hwclock
Tue Apr 26 10:40:02 2011 -0.656389 seconds
# /etc/init.d/ntpd stop
* Stopping ntpd ... [ ok ]
# /etc/init.d/ntp-client start
* Setting clock via the NTP client 'ntpd' ...
ntpd: time set -32389.642373s [ ok ]
# date
Tue Apr 26 01:41:00 JST 2011
# /etc/init.d/ntpd restart
* One of the files in /etc/{conf.d,init.d} or /etc/rc.conf
* has a modification time in the future!
* Starting ntpd ... [ ok ]
|
looks like ntp-client does not like the settings and adjusts back to UTC so I have to manullay set the time back to Tokyo.
grep ntp /var/log/everything/current
| Quote: | ...
Apr 26 10:41:26 [ntpd] ntpd 4.2.4p7@1.1607-o Thu Sep 30 10:18:44 UTC 2010 (1)
Apr 26 10:41:26 [ntpd] precision = 1.000 usec
Apr 26 10:41:26 [ntpd] Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Apr 26 10:41:26 [ntpd] Listening on interface #1 lo, 127.0.0.1#123 Enabled
Apr 26 10:41:26 [ntpd] Listening on interface #2 eth0, 10.240.67.221#123 Enabled
Apr 26 10:41:26 [ntpd] kernel time sync status 2040
Apr 26 10:41:26 [ntpd] frequency initialized -16.089 PPM from /var/lib/ntp/ntp.drift
|
This continues to baffle. Perhaps ntpd has it right and ntp-client is having the problem. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2038
Location: United Kingdom
|
| Posted: Wed Apr 27, 2011 9:18 am Post subject: |
|
|
| cgmoller wrote: | | The hwclock -ru is supposed to be reporting UTC correct? |
This is what happens (correctly) on my main laptop when the local time shown on my wristwatch is circa 09:43 BST (which is the same as 10:43 UTC):
| Code: | # hwclock -r
Wed 27 Apr 2011 09:42:32 BST -0.763420 seconds
# hwclock -ru
Wed 27 Apr 2011 10:42:38 BST -0.156559 seconds
# hwclock -r --localtime
Wed 27 Apr 2011 09:42:58 BST -0.844134 seconds
# date
Wed Apr 27 09:43:11 BST 2011
# |
The hwclock -ru command told me the time was 10:42:38 BST because I wrongly told it that the hwclock contains time in UTC. It doesn't, it contains local time, because CLOCK="local" and CLOCK_SYSTOHC="yes".
| cgmoller wrote: | # cat /etc/conf.d/ntpd | egrep -v "^#|^$"
| Code: | | NTPD_OPTS="-u ntp:ntp" |
|
Do you actually need that? Are you trying to run a NTP server? I have NTPD_OPTS="". Have you tried that instead?
Here's what I would try at this point, to see if the basic system clock and hardware clock mechanism is working through a reboot when no NTP daemon is running:
1. Stop the NTP daemon and remove the initscript from any runlevel:
| Code: | /etc/init.d/ntpd stop
rc-update del ntpd default |
If you are using NetworkManagerDispatcher to one-shot ntp-client at boot once the network comes up (starting the initscript before the network comes up is useless, as ntp-client is a one-shot deal) then stop NetworkManagerDispatcher and remove the initscript from the default runlevel:
| Code: | /etc/init.d/NetworkManagerDispatcher stop
rc-update del NetworkManagerDispatcher default |
2. Remove the ntp-client initscript from any runlevel:
| Code: | /etc/init.d/ntp-client stop
rc-update del ntp-client default |
3. Reboot the PC.
4. Set the system clock manually to the current local date and time, using the date command.
5. Write the time in the system clock to the hardware clock:
6. Edit the file /etc/conf.d/clock to contain the following:
| Code: | # /etc/conf.d/clock
# Set CLOCK to "UTC" if your system clock is set to UTC (also known as
# Greenwich Mean Time). If your clock is set to the local time, then
# set CLOCK to "local". Note that if you dual boot with Windows, then
# you should set it to "local".
CLOCK="local"
# Select the proper timezone. For valid values, peek inside of the
# /usr/share/zoneinfo/ directory. For example, some common values are
# "America/New_York" or "EST5EDT" or "Europe/Berlin".
TIMEZONE="Asia/Tokyo"
# If you wish to pass any other arguments to hwclock during bootup,
# you may do so here.
CLOCK_OPTS=""
# If you want to set the Hardware Clock to the current System Time
# during shutdown, then say "yes" here.
CLOCK_SYSTOHC="yes"
# Newer FHS specs say this file should live in /var/lib rather than
# /etc. If you care about such things, feel free to change this value.
# Note that a blank value means that you do not wish to even use the
# adjtime facility. This is the default behavior as adjtime can be
# very fragile. If the clock is updated without updating the adjtime
# file (which is common when using services such as ntp), then the
# clock can be screwed up when it gets updated at next boot.
#CLOCK_ADJTIME="/var/lib/adjtime"
#CLOCK_ADJTIME="/etc/adjtime"
CLOCK_ADJTIME="" |
7. Check if the file /usr/share/zoneinfo/Asia/Tokyo exists and, if it does, do the following:
| Code: | | rm /etc/localtime && cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime |
If the file /usr/share/zoneinfo/Asia/Tokyo doesn't exist, find the name of the file in /usr/share/zoneinfo/ that does contain the time zone info for Tokyo, and modify the above command accordingly (applies to TIMEZONE in /etc/conf.d/clock too).
8. Reboot the PC.
9. Enter the date command and the hwclock -r command to see what they return.
If that works, then edit /etc/conf.d/ntpd and make NTPD_OPTS="-g", add the initscript to the default runlevel and start it to keep the system clock in sync whilst the PC remains in use:
| Code: | rc-update add ntpd default
/etc/init.d/ntpd start |
and see if the output of the date command remains correct.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
| Back to top |
|
|
cgmoller
n00b
Joined: 21 Sep 2006
Posts: 56
Location: Boston, MA, USA
|
| Posted: Fri May 06, 2011 6:46 am Post subject: |
|
|
Fitzcaraldo
I have done what you recommend to the letter. But it simply does not work.
| Code: | # date
Fri May 6 14:36:15 JST 2011
# ntpq -c peers
ntpq: read: Connection refused
# /etc/init.d/ntpd status
* Caching service dependencies ... [ ok ]
* status: stopped
# /etc/init.d/ntpd start
* Starting ntpd ... [ ok ]
# ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
aoauspnt02a.sta 10.224.49.181 2 u 2 64 1 134.506 -324007 0.000
aoauswnt02a.sta 10.224.49.181 2 u 1 64 1 135.296 -324007 0.000
aojptsnt02a.sta 192.250.123.30 2 u - 64 1 1.673 -324007 0.000
aohkshnt02a.sta .INIT. 16 u - 64 0 0.000 0.000 0.000
# ntpq -c readvar
associd=0 status=c012 leap_alarm, sync_unspec, 1 event, freq_set,
version="ntpd 4.2.6p3@1.2290-o Mon May 2 12:05:00 UTC 2011 (1)",
processor="x86_64", system="Linux/2.6.37-gentoo-r4", leap=11, stratum=16,
precision=-21, rootdelay=0.000, rootdisp=0.120, refid=INIT,
reftime=00000000.00000000 Mon, Jan 1 1900 0:00:00.000,
clock=d16e861c.3703139a Fri, May 6 2011 14:37:16.214, peer=0, tc=3,
mintc=3, offset=0.000, frequency=-17.344, sys_jitter=0.000,
clk_jitter=0.000, clk_wander=0.000
#
|
Later - it synchronizes back to UTC
| Code: | # date
Fri May 6 06:31:29 JST 2011
# ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
-aoauspnt02a.sta 10.224.49.181 2 u 108 128 377 134.162 5.389 0.893
+aoauswnt02a.sta 10.224.49.181 2 u 79 128 377 135.271 4.074 0.670
+aojptsnt02a.sta 192.250.123.30 2 u 123 128 377 1.661 -0.192 0.137
*aohkshnt02a.sta 10.232.71.195 2 u 121 128 377 59.706 0.500 1.093
jptkis999 ~ # ntpq -c readvar
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.6p3@1.2290-o Mon May 2 12:05:00 UTC 2011 (1)",
processor="x86_64", system="Linux/2.6.37-gentoo-r4", leap=00, stratum=3,
precision=-21, rootdelay=60.972, rootdisp=41.744, refid=10.232.71.196,
reftime=d16e13d5.6fbfaeca Fri, May 6 2011 6:29:41.436,
clock=d16e1457.7d878ddd Fri, May 6 2011 6:31:51.490, peer=41725, tc=7,
mintc=3, offset=1.321, frequency=-18.770, sys_jitter=2.198,
clk_jitter=1.724, clk_wander=0.220
#
|
So I manually set the time again.
| Code: | # date
Fri May 6 06:37:37 JST 2011
# date 05061538
Fri May 6 15:38:00 JST 2011
# hwclock
Fri May 6 15:38:06 2011 -0.754542 seconds
# ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
-aoauspnt02a.sta 10.224.49.181 2 u 1 128 377 134.427 5.657 1224610
+aoauswnt02a.sta 10.224.49.181 2 u 9h 128 377 135.214 4.258 0.880
+aojptsnt02a.sta 192.250.123.30 2 u 16 128 377 1.661 -0.192 1224610
*aohkshnt02a.sta 10.232.71.195 2 u 18 128 377 59.706 0.500 1224610
# ntpq -c readvar
associd=0 status=0018 leap_none, sync_unspec, 1 event, no_sys_peer,
version="ntpd 4.2.6p3@1.2290-o Mon May 2 12:05:00 UTC 2011 (1)",
processor="x86_64", system="Linux/2.6.37-gentoo-r4", leap=00, stratum=3,
precision=-21, rootdelay=60.972, rootdisp=53.249, refid=10.232.71.196,
reftime=d16e13d5.6fbfaeca Fri, May 6 2011 6:29:41.436,
clock=d16e95e7.404c66dc Fri, May 6 2011 15:44:39.251, peer=0, tc=7,
mintc=3, offset=1.321, frequency=-18.770, sys_jitter=2.357,
clk_jitter=1.724, clk_wander=0.220
|
Perhaps I am missing something in the Kernel. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2038
Location: United Kingdom
|
| Posted: Fri May 06, 2011 11:08 pm Post subject: |
|
|
If I read you correctly, nothing untoward happens to the time in the system clock if you don't have the NTP daemon running. If you boot your machine (and you do not start the NTP daemon) and you use the date command to set the time in the system clock to Tokyo time then the system clock stays as Tokyo time. If you then reboot your machine (and you do not start the NTP daemon) then the time in the system clock after booting remains as Tokyo time. Is my understanding correct?
After a fresh boot, if you have /etc/conf.d/ntp-client containing only the following uncommented lines precisely:
| Code: | NTPCLIENT_CMD="ntpd"
NTPCLIENT_OPTS="-g -q" |
and Tokyo time is in the system clock, and you have neither the ntp-client nor the ntpd initscripts in any runlevel, what happens to the time in the system clock after you one-shot ntpd?:
| Code: | date
/etc/init.d/ntp-client start
date |
After a fresh boot, if you have /etc/conf.d/ntp-client containing only the following uncommented lines precisely:
| Code: | NTPCLIENT_CMD="ntpdate"
NTPCLIENT_OPTS="-s -b -u \
0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org \
2.gentoo.pool.ntp.org 3.gentoo.pool.ntp.org" |
and Tokyo time is in the system clock, and you have neither the ntp-client nor the ntpd initscripts in any runlevel, what happens to the time in the system clock after you one-shot ntpdate?:
| Code: | date
/etc/init.d/ntp-client start
date |
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
| Back to top |
|
|
kimmie
Guru
Joined: 08 Sep 2004
Posts: 531
Location: Australia
|
| Posted: Tue May 17, 2011 11:32 pm Post subject: |
|
|
Have you recently upgraded to OpenRC? If you did, and made the same mistake I did, you get an offset problem. Apologies if this is irrelevant to your problem, I just saw TIMEZONE= and I'm too lazy to read the entire thread.
You do not need to set the TIMEZONE variable... just put it's contents (ie. the line Asia/Tokyo) in /etc/timezone, rm /etc/localtime, and remerge timezone data (to repopulate /etc/localtime for you) emerge -1 timezone-data.
See https://forums.gentoo.org/viewtopic-t-861872.html |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
