LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 04-13-2014, 12:03 PM   #1
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Rep: Reputation: 15
14.1: ntpd not keeping local time; hwclock changes.


On a Sony Vaio laptop running 14.1/x86_64 the system time display keeps moving 7 hours ahead; sometimes 14 hours ahead. We're in the PDT timezone.

'date' shows the date and time 7 hours ahead, but indicates PDT time zone. As root, I set date to the current time, then set the hardware clock to the system clock using 'hwclock -w --localtime' (and localtime is the default for the hardware clock, but I specify it anyway). Within a few hours the time has moved ahead again.

In /etc/ntp.conf I set
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
but this does not keep the time correct any longer, either.

Suggestions and fixes are needed.

TIA,

Rich
 
Old 04-13-2014, 01:48 PM   #2
sgosnell
Member
 
Registered: Jan 2008
Location: Baja Oklahoma
Distribution: Debian
Posts: 359

Rep: Reputation: 61
Don't change the system time, leave it set to GMT. What you want to change is the displayed timezone. That can be set several ways, and one is to run
Code:
dpkg-reconfigure tzdata
. I don't know what GUI tools are available in Slackware.
 
Old 04-13-2014, 01:55 PM   #3
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,037

Rep: Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756
Seven hours ahead is UTC (for your time zone) as you probably already know.

Do you have logging turned on; e.g., in /etc/ntp.conf
Code:
# modifications are in use and declare an unsynchronized condition.
#
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

#
# NTP server (list one or more) to synchronize with:
#server pool.ntp.org iburst
server  0.us.pool.ntp.org
server  1.us.pool.ntp.org
server  2.us.pool.ntp.org

#
# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift

# Log file
logconfig=allclock +allpeer +allsys +allsync
logfile /var/log/ntp.log
If so, what does the log have in it? My log looks like this today (the log is rotated Sunday):
Code:
13 Apr 04:40:02 ntpd[5752]: LOCAL(0) 8011 81 mobilize assoc 60268
13 Apr 04:40:02 ntpd[5752]: 108.61.73.244 8011 81 mobilize assoc 60269
13 Apr 04:40:02 ntpd[5752]: 72.14.183.239 8011 81 mobilize assoc 60270
13 Apr 04:40:02 ntpd[5752]: 162.243.243.206 8011 81 mobilize assoc 60271
13 Apr 04:40:02 ntpd[5752]: 0.0.0.0 c016 06 restart
13 Apr 04:40:02 ntpd[5752]: 0.0.0.0 c012 02 freq_set kernel -12.213 PPM
13 Apr 04:40:03 ntpd[5752]: LOCAL(0) 8024 84 reachable
13 Apr 04:40:03 ntpd[5752]: LOCAL(0) 903a 8a sys_peer
13 Apr 04:40:03 ntpd[5752]: 0.0.0.0 c515 05 clock_sync
13 Apr 04:40:05 ntpd[5752]: 108.61.73.244 8024 84 reachable
13 Apr 04:40:06 ntpd[5752]: 72.14.183.239 8024 84 reachable
13 Apr 04:40:07 ntpd[5752]: 162.243.243.206 8024 84 reachable
13 Apr 04:43:20 ntpd[5752]: 108.61.73.244 903a 8a sys_peer
13 Apr 04:43:23 ntpd[5752]: 72.14.183.239 903a 8a sys_peer
13 Apr 04:45:32 ntpd[5752]: 162.243.243.206 943a 8a sys_peer
13 Apr 04:51:47 ntpd[5752]: LOCAL(0) 8043 83 unreachable
13 Apr 05:19:30 ntpd[5752]: 72.14.183.239 941a 8a sys_peer
13 Apr 05:22:44 ntpd[5752]: 108.61.73.244 941a 8a sys_peer
13 Apr 05:37:04 ntpd[5752]: 72.14.183.239 941a 8a sys_peer
13 Apr 07:54:59 ntpd[5752]: 162.243.243.206 941a 8a sys_peer
13 Apr 08:05:36 ntpd[5752]: 108.61.73.244 941a 8a sys_peer
13 Apr 08:22:59 ntpd[5752]: 162.243.243.206 941a 8a sys_peer
13 Apr 08:49:47 ntpd[5752]: 108.61.73.244 941a 8a sys_peer
13 Apr 08:55:59 ntpd[5752]: 72.14.183.239 941a 8a sys_peer
which is what a "normal" log will look like.

What does /usr/sbin/ntpq -pn show you? Should look a lot like this:
Code:
/usr/sbin/ntpq -pn 
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l  10h   64    0    0.000    0.000   0.000
+108.61.73.244   18.26.4.105      2 u  401 1024  377  647.452   -5.554  74.515
*72.14.183.239   216.218.254.202  2 u  925 1024  377  585.039  -19.021  65.353
+162.243.243.206 216.218.192.202  2 u  284 1024  377  626.201    2.007  36.787
If you're not synchronized (no asterisk on one address), that ain't good.

Are you sure you have PST/PDT and your preferred clock setting set? You can execute
Code:
/etc/rc.d/rc.ntpd stop
/usr/sbin/timeconfig
<use hwclock to set the hardware clock to the correct time, either UTC or local>
/etc/rc.d/rc.ntpd start
<wait about five minutes for synchronization>
/usr/sbin/ntpq -pn
You should never have that much drift in the clock. When you use the date utility, you're looking at the system clock, not the hardware clock, particularly if NTPD is synchronized.

Do you by any chance have more than one NTP daemon running? You should only see
Code:
ps -ef | fgrep ntpd
root      5752     1  0 04:40 ?        00:00:01 /usr/sbin/ntpd -g -p /var/run/ntpd.pid
root     17284 17161  0 14:37 pts/0    00:00:00 fgrep ntpd
If there's more than one (not the fgrep ntpd line), you can stop one of them with rc.ntpd stop but any others will need to be killed with, as root,
Code:
kill -9 <pid of the daemon>
You can try shutting down to single user, run timeconfig to make sure your settings are correct, then set both the system clock and hardware clock to your preference (local time, UTC) or (local time, local time), something like this:
Code:
init 1
<wait a while>
log in as root
timeconfig
<hwclock to set both>
init 6
Once that's done, rc.htpd will have set the system clock from the hardware clock.

The only other thing I can think of is that, if you're shutting the system down and leaving it off for some period of time (like overnight), you may have a dead battery (the one on the motherboard). When Slackware boots, the system clock is set from the hardware clock. When you shut down, the system clock is written to the hardware clock -- if the hardware clock is set to UTC, that is taken care of in both directions (thus try running timeconfig to make sure you've got what you think you've got). If NTPD is running and you're synchronized to a time sever (ntpq -pn tells you that) and you shut down, the hardware clock should be at the correct time irrespective of whether it's set to UTC. So, maybe the battery (or maybe not).

Hope this helps some.

Last edited by tronayne; 04-13-2014 at 02:01 PM. Reason: Somehow this post got doubled, removed the double.
 
1 members found this post helpful.
Old 04-14-2014, 04:14 AM   #4
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 226Reputation: 226Reputation: 226
Is the system clock (reported by date) jumping forward after a reboot/suspend etc?

Have a read through this thread and see if your system is behaving in the same way :-
http://www.linuxquestions.org/questi...me-4175477525/

A patch for the kernel bug that causes it is also in that thread.
 
Old 04-14-2014, 01:10 PM   #5
hpfeil
Member
 
Registered: Nov 2010
Location: Tucson, Arizona US
Distribution: Slackware Current, custom kernel, amd64, Beyond LinuxFromScratch
Posts: 130
Blog Entries: 1

Rep: Reputation: Disabled
Certain "foreign" programs seem to do that. I don't know how they got into Slackware. Perhaps via gtk+3, something from freesoftware.org? There's a megalomaniacal movement afoot, if afoot is the term for which I'm searching, to infest Linux with Mommyware. One of the things that drive such people nuts is having different location-based time-zones on others' computers. They want your BIOS to be UTC; they want your kernel clock to be UTC (hwcloc). If I ever want that sort of nonsense on my computer, I'll make it so, but not until. [rant off] I live somewhere that does not do Daylight Savings Time; always UTC-7. If I want something in UTC, I'll add seven hours, otherwise leave me alone.
Here's my ad-hoc kludge for whenever I notice that someone tampered with my clock:

=-=-=-snip=-=-=-
#!/usr/bin/bash
/etc/rc.d/rc.ntpd stop
sudo /usr/sbin/ntpdate -4 2.us.pool.ntp.org
/etc/rc.d/rc.ntpd start
-=-=-=--snip=-=-=-=-

I know ntpdate is supposed to be deprecated, but ntpd doesn't work if the time difference is too large, no matter how many '-g's I specify. Seems to be a limit. I used to just reboot, manually set the bios clock, then ntpd -ggg gets things back into sync. Sometimes when I'm not paying attention, some Mommyware will set hwclock to +7, then another one that hasn't a clue that it is already set to UTC adds another 7 hours; 14 hours appears to be too large for ntpd, but ntpdate works.

Last edited by hpfeil; 04-14-2014 at 01:12 PM. Reason: PS: It's not a kernel bug.
 
Old 04-27-2014, 06:43 PM   #6
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
[QUOTE=tronayne;5151834]Seven hours ahead is UTC (for your time zone) as you probably already know.

Do you have logging turned on; e.g., in /etc/ntp.conf

I do now; hadn't before.


Are you sure you have PST/PDT and your preferred clock setting set?

Yes.

Do you by any chance have more than one NTP daemon running?

No.

Once that's done, rc.htpd will have set the system clock from the hardware clock.

When I added logging to /etc/ntpd.conf I restarted ntpd; it reported setting the hardware clock to the system clock. Don't know if this matters, but 'date' shows the time in 24-hour format while 'hwclock' shows the time in 12-hour format. Both show the same time, however.

The only other thing I can think of is that, if you're shutting the system down and leaving it off for some period of time (like overnight), you may have a dead battery (the one on the motherboard). When Slackware boots, the system clock is set from the hardware clock. When you shut down, the system clock is written to the hardware clock -- if the hardware clock is set to UTC, that is taken care of in both directions (thus try running timeconfig to make sure you've got what you think you've got). If NTPD is running and you're synchronized to a time sever (ntpq -pn tells you that) and you shut down, the hardware clock should be at the correct time irrespective of whether it's set to UTC. So, maybe the battery (or maybe not).

The host is generally left on 24/7. It's only a couple of years old so it's not likely that the cmos battery would be gone already. Actually, I've not had one fail in any portable I've had and only 1 on a deesktop system and that was many years ago.

Will report results of logging tomorrow or Tuesday.

Thanks,

Rich
 
Old 04-27-2014, 06:51 PM   #7
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by wildwizard View Post
Is the system clock (reported by date) jumping forward after a reboot/suspend etc?

Have a read through this thread and see if your system is behaving in the same way :-
http://www.linuxquestions.org/questi...me-4175477525/

A patch for the kernel bug that causes it is also in that thread.
The system clock moves ahead in 7-hour bites; it's now advancing 21 hours over some period of time. Doesn't matter if the system has been shut down or not. It can be booted, show the correct time, then a few hours later it's advanced. Since I don't use this system I cannot write how long it is before the system clock is 7, 14, or 21 hours ahead of real time. And the timezone is set to PDT.

Thanks,

Rich
 
Old 04-28-2014, 09:41 AM   #8
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,486

Rep: Reputation: 426Reputation: 426Reputation: 426Reputation: 426Reputation: 426
What is the output of the following command, run as root?
Code:
ntpq -p
 
Old 04-28-2014, 10:05 AM   #9
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,037

Rep: Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756
I cannot imagine why this is happening other than you may -- may! -- have a configuration problem.

A couple of things to check.

Open a terminal and do
Code:
ls -l /etc/localtime-copied-from
you should see
Code:
/usr/share/zoneinfo/US/Pacific
Do this:
Code:
grep UTC /etc/adjtime
adjtime:UTC
grep UTC hardwareclock
hardwareclock:UTC
You should see "UTC" in both of those files (they're text, you can cat them). If one or the other does not contain UTC, you'll want to run timeconfig (see below).

Look at /etc/ntp/drift
Code:
cd /etc/ntp
cat drift
That will show you a floating point number; what is that number?

If you boot your system into the BIOS, there will be a time/date setting there. That's the hardware clock and it should be set to your local time plus 7 hours (during daylight time, otherwise 8 hours); e.g., I'm in the eastern time zone, the local time is 08:25 EDT and the hardware clock is 12:25 (EST is 5 hours, EDT is 4 hours from UTC). Where you are, it's 05:25 PDT and UTC is 12:25 (PST is 8 hours, PDT is 7 hours from UTC).

Make sure your BIOS clock is local wall/wristwatch clock time plus seven hours, that's UTC. Make sure the date is correct, too just for grins (today being 28 April 2014 and all that). Is it actually ticking? Remember that most BIOS clock settings are AM/PM and get that right; UTC is your local time plus 7 hours (during daylight time), 8 hours (standard time).

Are you by any chance dual-booting Windows? If so, get into Windows and shut off the automatic change to daylight time -- it's in the control panel in the date and time section. Windows will roll the hardware clock, you don't want that to happen.

Have you fiddled with any KDE clock/timezone/whatever setting? Shouldn't really matter but I can recall getting things screwed up doing that (a long, long time ago).

NTP is not going to walk your clock by the offset from UTC, the 7 seven hours thing, it just won't do that. When you boot the system and NTP starts, your system clock (the software one) initially gets set from the hardware clock (which should be UTC, which is plus seven hours from your local time). NTP synchronizes the system clock with one of your external time references (as shown by ntpq -pn). When you shut the system down, the system time is written to the hardware clock.

Now, the initial setting of the system clock is done with the NTP -g option which permits "Big" initial adjustment. A swing of 7 hours, the exact offset from UTC, might be a hint that you need to run timeconfig.

timeconfig is what you ran during installation of Slackware. It's a blue screen with a box that will has whether your hardware clock is set to UTC (chose Yes), then it will ask for your time zone, pick US Pacific, don't bother with an individual city, just use the time zone.

With kernel changes that have been made, your best bet is keeping your hardware clock on UTC and let your system clock adjust up and down for daylight/standard time.

And the only other thing I can think of is do you have a cron job somewhere or other that is doing anything with the clock?

Hope this helps some.
 
Old 04-30-2014, 03:04 PM   #10
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by Richard Cranium View Post
What is the output of the following command, run as root?
Code:
ntpq -p
[root@pachy ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 10 l 45 64 1 0.000 0.000 * 0.000
96.44.142.5 200.98.196.212 2 u 20 64 1 115.658 -252034 * 0.000
199.241.31.224 132.163.4.103 2 u 20 64 1 115.211 -252034 * 0.000
bindcat.fhsu.ed 132.163.4.103 2 u 17 64 1 112.005 -252034 * 0.000
 
Old 04-30-2014, 03:21 PM   #11
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
[QUOTE=tronayne;5160565]I cannot imagine why this is happening other than you may -- may! -- have a configuration problem.

If so, it appeared well after the upgrade to 14.1

A couple of things to check.

Open a terminal and do
ls -l /etc/localtime-copied-from
you should see

/usr/share/zoneinfo/US/Pacific

Yes, that's what I see


Do this:
grep UTC /etc/adjtime
adjtime:UTC
grep UTC hardwareclock
hardwareclock:UTC

You should see "UTC" in both of those files

/etc/adjtime is set to local; there is no command 'hardwareclock' on the system.


Look at /etc/ntp/drift
cd /etc/ntp
cat drift
That will show you a floating point number; what is that number?

It's quite small; didn't copy it down.

If you boot your system into the BIOS, there will be a time/date setting there. That's the hardware clock and it should be set to your local time plus 7 hours (during daylight time, otherwise 8 hours); e.g., I'm in the eastern time zone, the local time is 08:25 EDT and the hardware clock is 12:25 (EST is 5 hours, EDT is 4 hours from UTC). Where you are, it's 05:25 PDT and UTC is 12:25 (PST is 8 hours, PDT is 7 hours from UTC).

All my systems (including this Sony Vaio) have always been set to localtime, not UTC. This Sony has had Slackware-12.0 through -14.1 installed this way and this timekeeping issue is new.

Are you by any chance dual-booting Windows?

Gag! Heck no! Haven't used anything Micro$oft since mid-1977.

Have you fiddled with any KDE clock/timezone/whatever setting? Shouldn't really matter but I can recall getting things screwed up doing that (a long, long time ago).

Have never used KDE; all hosts run Xfce4 now.

NTP is not going to walk your clock by the offset from UTC, the 7 seven hours thing, it just won't do that. When you boot the system and NTP starts, your system clock (the software one) initially gets set from the hardware clock (which should be UTC, which is plus seven hours from your local time). NTP synchronizes the system clock with one of your external time references (as shown by ntpq -pn). When you shut the system down, the system time is written to the hardware clock.

When Slackware is first installed on a new machine I'm always asked for the timezone (which is US Pacific). In all systems the hardware clock has been set to local time without issues ... until this recent problem with the one host.

With kernel changes that have been made, your best bet is keeping your hardware clock on UTC and let your system clock adjust up and down for daylight/standard time.

Both my desktop and my Dell Latitude portable (which is kept off most of the time unless I'm traveling or working out of my office) are set to local time with the 3.10.17-smp kernel and don't have the problem with keeping time correctly.

Could the issue be related to the Sony being on a different sub-net from the hosts connected by Ethernet? The wireless access point runs DHCP but is set to give the Sony the same local IP address each time it comes on line. Ethernet hosts run static IP addresses.

Here's the ntp.log for the past couple of days:

27 Apr 16:45:02 ntpd[18257]: ntpd exiting on signal 15
27 Apr 17:36:50 ntpd[745]: Deferring DNS for 0.us.pool.ntp.org 1
27 Apr 17:36:50 ntpd[745]: Deferring DNS for 1.us.pool.ntp.org 1
27 Apr 17:36:50 ntpd[745]: Deferring DNS for 2.us.pool.ntp.org 1
27 Apr 17:36:50 ntpd[749]: signal_no_reset: signal 17 had flags 4000000
27 Apr 17:37:14 ntpd[745]: ntpd exiting on signal 1
27 Apr 17:37:15 ntpd[907]: Deferring DNS for 0.us.pool.ntp.org 1
27 Apr 17:37:15 ntpd[907]: Deferring DNS for 1.us.pool.ntp.org 1
27 Apr 17:37:15 ntpd[907]: Deferring DNS for 2.us.pool.ntp.org 1
27 Apr 17:37:15 ntpd[910]: signal_no_reset: signal 17 had flags 4000000
27 Apr 17:37:22 ntpd[749]: parent died before we finished, exiting
27 Apr 17:37:23 ntpd[907]: Listen normally on 4 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
27 Apr 17:37:23 ntpd[907]: peers refreshed
27 Apr 17:37:23 ntpd[907]: new interface(s) found: waking up resolver
27 Apr 17:37:35 ntpd[907]: Listen normally on 5 wlan0 192.168.2.4 UDP 123
27 Apr 17:37:35 ntpd[907]: peers refreshed
27 Apr 17:37:35 ntpd[907]: new interface(s) found: waking up resolver
27 Apr 17:37:37 ntpd[910]: DNS 0.us.pool.ntp.org -> 64.246.132.14
27 Apr 17:37:37 ntpd[910]: DNS 1.us.pool.ntp.org -> 173.230.144.109
27 Apr 17:37:38 ntpd[910]: DNS 2.us.pool.ntp.org -> 23.253.213.220
27 Apr 18:56:15 ntpd[907]: Deleting interface #5 wlan0, 192.168.2.4#123, interface stats: received=186, sent=187, dropped=0, active_time=4639 secs
27 Apr 18:56:15 ntpd[907]: 23.253.213.220 interface 192.168.2.4 -> (none)
27 Apr 18:56:15 ntpd[907]: 173.230.144.109 interface 192.168.2.4 -> (none)
27 Apr 18:56:15 ntpd[907]: 64.246.132.14 interface 192.168.2.4 -> (none)
27 Apr 18:56:15 ntpd[907]: Deleting interface #4 wlan0, fe80::76e5:bff:fe63:2016#123, interface stats: received=0, sent=0, dropped=0, active_time=4651 secs
27 Apr 18:56:15 ntpd[907]: peers refreshed
27 Apr 19:06:56 ntpd[907]: Listen normally on 6 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
27 Apr 19:06:56 ntpd[907]: peers refreshed
27 Apr 19:06:56 ntpd[907]: new interface(s) found: waking up resolver
27 Apr 19:07:05 ntpd[907]: Listen normally on 7 wlan0 192.168.2.4 UDP 123
27 Apr 19:07:05 ntpd[907]: peers refreshed
27 Apr 19:07:05 ntpd[907]: new interface(s) found: waking up resolver
27 Apr 20:21:30 ntpd[907]: Deleting interface #7 wlan0, 192.168.2.4#123, interface stats: received=174, sent=174, dropped=0, active_time=4464 secs
27 Apr 20:21:30 ntpd[907]: 173.230.144.109 interface 192.168.2.4 -> (none)
27 Apr 20:21:30 ntpd[907]: 23.253.213.220 interface 192.168.2.4 -> (none)
27 Apr 20:21:30 ntpd[907]: 64.246.132.14 interface 192.168.2.4 -> (none)
27 Apr 20:21:30 ntpd[907]: Deleting interface #6 wlan0, fe80::76e5:bff:fe63:2016#123, interface stats: received=0, sent=0, dropped=0, active_time=4473 secs
27 Apr 20:21:30 ntpd[907]: peers refreshed
27 Apr 21:16:27 ntpd[907]: Listen normally on 8 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
27 Apr 21:16:27 ntpd[907]: peers refreshed
27 Apr 21:16:27 ntpd[907]: new interface(s) found: waking up resolver
27 Apr 21:16:31 ntpd[907]: Listen normally on 9 wlan0 192.168.2.4 UDP 123
27 Apr 21:16:31 ntpd[907]: peers refreshed
27 Apr 21:16:31 ntpd[907]: new interface(s) found: waking up resolver
27 Apr 23:04:22 ntpd[907]: Deleting interface #9 wlan0, 192.168.2.4#123, interface stats: received=179, sent=182, dropped=0, active_time=6470 secs
27 Apr 23:04:22 ntpd[907]: 173.230.144.109 interface 192.168.2.4 -> (none)
27 Apr 23:04:22 ntpd[907]: 23.253.213.220 interface 192.168.2.4 -> (none)
27 Apr 23:04:22 ntpd[907]: 64.246.132.14 interface 192.168.2.4 -> (none)
27 Apr 23:04:22 ntpd[907]: Deleting interface #8 wlan0, fe80::76e5:bff:fe63:2016#123, interface stats: received=0, sent=0, dropped=0, active_time=6474 secs
27 Apr 23:04:22 ntpd[907]: peers refreshed
27 Apr 23:14:04 ntpd[907]: Listen normally on 10 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
27 Apr 23:14:04 ntpd[907]: peers refreshed
27 Apr 23:14:04 ntpd[907]: new interface(s) found: waking up resolver
27 Apr 23:14:13 ntpd[907]: Listen normally on 11 wlan0 192.168.2.4 UDP 123
27 Apr 23:14:13 ntpd[907]: peers refreshed
27 Apr 23:14:13 ntpd[907]: new interface(s) found: waking up resolver
28 Apr 00:33:51 ntpd[907]: Deleting interface #11 wlan0, 192.168.2.4#123, interface stats: received=89, sent=89, dropped=1, active_time=4778 secs
28 Apr 00:33:51 ntpd[907]: 173.230.144.109 interface 192.168.2.4 -> (none)
28 Apr 00:33:51 ntpd[907]: 23.253.213.220 interface 192.168.2.4 -> (none)
28 Apr 00:33:51 ntpd[907]: 64.246.132.14 interface 192.168.2.4 -> (none)
28 Apr 00:33:51 ntpd[907]: Deleting interface #10 wlan0, fe80::76e5:bff:fe63:2016#123, interface stats: received=0, sent=0, dropped=0, active_time=4787 secs
28 Apr 00:33:51 ntpd[907]: peers refreshed
28 Apr 01:29:45 ntpd[907]: Listen normally on 12 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
28 Apr 01:29:45 ntpd[907]: peers refreshed
28 Apr 01:29:45 ntpd[907]: new interface(s) found: waking up resolver
28 Apr 01:29:55 ntpd[907]: Listen normally on 13 wlan0 192.168.2.4 UDP 123
28 Apr 01:29:55 ntpd[907]: peers refreshed
28 Apr 01:29:55 ntpd[907]: new interface(s) found: waking up resolver
28 Apr 18:06:06 ntpd[753]: Deferring DNS for 0.us.pool.ntp.org 1
28 Apr 18:06:06 ntpd[753]: Deferring DNS for 1.us.pool.ntp.org 1
28 Apr 18:06:06 ntpd[753]: Deferring DNS for 2.us.pool.ntp.org 1
28 Apr 18:06:06 ntpd[757]: signal_no_reset: signal 17 had flags 4000000
28 Apr 18:06:24 ntpd[753]: ntpd exiting on signal 1
28 Apr 18:06:25 ntpd[929]: Deferring DNS for 0.us.pool.ntp.org 1
28 Apr 18:06:25 ntpd[929]: Deferring DNS for 1.us.pool.ntp.org 1
28 Apr 18:06:25 ntpd[929]: Deferring DNS for 2.us.pool.ntp.org 1
28 Apr 18:06:25 ntpd[931]: signal_no_reset: signal 17 had flags 4000000
28 Apr 18:06:29 ntpd[929]: Listen normally on 4 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
28 Apr 18:06:29 ntpd[929]: peers refreshed
28 Apr 18:06:29 ntpd[929]: new interface(s) found: waking up resolver
28 Apr 18:06:38 ntpd[757]: parent died before we finished, exiting
28 Apr 18:06:41 ntpd[929]: Listen normally on 5 wlan0 192.168.2.44 UDP 123
28 Apr 18:06:44 ntpd[929]: peers refreshed
28 Apr 18:06:44 ntpd[929]: new interface(s) found: waking up resolver
28 Apr 18:06:46 ntpd[931]: DNS 0.us.pool.ntp.org -> 66.175.211.68
28 Apr 18:06:46 ntpd[931]: DNS 1.us.pool.ntp.org -> 74.117.238.11
28 Apr 18:06:46 ntpd[931]: DNS 2.us.pool.ntp.org -> 149.20.68.17
28 Apr 23:40:16 ntpd[698]: Deferring DNS for 0.us.pool.ntp.org 1
28 Apr 23:40:16 ntpd[698]: Deferring DNS for 1.us.pool.ntp.org 1
28 Apr 23:40:16 ntpd[698]: Deferring DNS for 2.us.pool.ntp.org 1
28 Apr 23:40:16 ntpd[702]: signal_no_reset: signal 17 had flags 4000000
28 Apr 23:40:40 ntpd[698]: ntpd exiting on signal 1
28 Apr 23:40:41 ntpd[887]: Deferring DNS for 0.us.pool.ntp.org 1
28 Apr 23:40:41 ntpd[887]: Deferring DNS for 1.us.pool.ntp.org 1
28 Apr 23:40:41 ntpd[887]: Deferring DNS for 2.us.pool.ntp.org 1
28 Apr 23:40:41 ntpd[889]: signal_no_reset: signal 17 had flags 4000000
28 Apr 23:40:44 ntpd[887]: Listen normally on 4 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
28 Apr 23:40:44 ntpd[887]: peers refreshed
28 Apr 23:40:44 ntpd[887]: new interface(s) found: waking up resolver
28 Apr 23:40:48 ntpd[702]: parent died before we finished, exiting
28 Apr 23:40:54 ntpd[887]: Listen normally on 5 wlan0 192.168.2.4 UDP 123
28 Apr 23:40:54 ntpd[887]: peers refreshed
28 Apr 23:40:54 ntpd[887]: new interface(s) found: waking up resolver
28 Apr 23:40:56 ntpd[889]: DNS 0.us.pool.ntp.org -> 216.158.93.130
28 Apr 23:40:57 ntpd[889]: DNS 1.us.pool.ntp.org -> 208.68.36.196
28 Apr 23:40:57 ntpd[889]: DNS 2.us.pool.ntp.org -> 97.107.129.217
30 Apr 00:24:43 ntpd[688]: Deferring DNS for 0.us.pool.ntp.org 1
30 Apr 00:24:43 ntpd[688]: Deferring DNS for 1.us.pool.ntp.org 1
30 Apr 00:24:43 ntpd[688]: Deferring DNS for 2.us.pool.ntp.org 1
30 Apr 00:24:43 ntpd[692]: signal_no_reset: signal 17 had flags 4000000
30 Apr 00:25:07 ntpd[688]: ntpd exiting on signal 1
30 Apr 00:25:08 ntpd[895]: Deferring DNS for 0.us.pool.ntp.org 1
30 Apr 00:25:08 ntpd[895]: Deferring DNS for 1.us.pool.ntp.org 1
30 Apr 00:25:08 ntpd[895]: Deferring DNS for 2.us.pool.ntp.org 1
30 Apr 00:25:08 ntpd[898]: signal_no_reset: signal 17 had flags 4000000
30 Apr 00:25:13 ntpd[895]: Listen normally on 5 wlan0 192.168.2.4 UDP 123
30 Apr 00:25:13 ntpd[895]: peers refreshed
30 Apr 00:25:13 ntpd[895]: new interface(s) found: waking up resolver
30 Apr 00:25:15 ntpd[692]: parent died before we finished, exiting
30 Apr 00:25:16 ntpd[898]: DNS 0.us.pool.ntp.org -> 108.69.104.139
30 Apr 00:25:16 ntpd[898]: DNS 1.us.pool.ntp.org -> 129.250.35.251
30 Apr 00:25:17 ntpd[898]: DNS 2.us.pool.ntp.org -> 209.105.231.38
30 Apr 05:37:13 ntpd[694]: Deferring DNS for 0.us.pool.ntp.org 1
30 Apr 05:37:13 ntpd[694]: Deferring DNS for 1.us.pool.ntp.org 1
30 Apr 05:37:13 ntpd[694]: Deferring DNS for 2.us.pool.ntp.org 1
30 Apr 05:37:13 ntpd[698]: signal_no_reset: signal 17 had flags 4000000
30 Apr 05:37:37 ntpd[694]: ntpd exiting on signal 1
30 Apr 05:37:38 ntpd[871]: Deferring DNS for 0.us.pool.ntp.org 1
30 Apr 05:37:38 ntpd[871]: Deferring DNS for 1.us.pool.ntp.org 1
30 Apr 05:37:38 ntpd[871]: Deferring DNS for 2.us.pool.ntp.org 1
30 Apr 05:37:38 ntpd[873]: signal_no_reset: signal 17 had flags 4000000
30 Apr 05:37:42 ntpd[871]: Listen normally on 4 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
30 Apr 05:37:42 ntpd[871]: peers refreshed
30 Apr 05:37:42 ntpd[871]: new interface(s) found: waking up resolver
30 Apr 05:37:45 ntpd[698]: parent died before we finished, exiting
30 Apr 05:37:51 ntpd[871]: Listen normally on 5 wlan0 192.168.2.4 UDP 123
30 Apr 05:37:52 ntpd[871]: peers refreshed
30 Apr 05:37:52 ntpd[871]: new interface(s) found: waking up resolver
30 Apr 05:37:54 ntpd[873]: DNS 0.us.pool.ntp.org -> 67.18.187.111
30 Apr 05:37:55 ntpd[873]: DNS 1.us.pool.ntp.org -> 206.209.110.2
30 Apr 05:37:55 ntpd[873]: DNS 2.us.pool.ntp.org -> 69.167.160.102
30 Apr 06:40:27 ntpd[724]: Deferring DNS for 0.us.pool.ntp.org 1
30 Apr 06:40:27 ntpd[724]: Deferring DNS for 1.us.pool.ntp.org 1
30 Apr 06:40:27 ntpd[724]: Deferring DNS for 2.us.pool.ntp.org 1
30 Apr 06:40:27 ntpd[728]: signal_no_reset: signal 17 had flags 4000000
30 Apr 06:40:53 ntpd[724]: ntpd exiting on signal 1
30 Apr 06:40:54 ntpd[912]: Deferring DNS for 0.us.pool.ntp.org 1
30 Apr 06:40:54 ntpd[912]: Deferring DNS for 1.us.pool.ntp.org 1
30 Apr 06:40:54 ntpd[912]: Deferring DNS for 2.us.pool.ntp.org 1
30 Apr 06:40:54 ntpd[916]: signal_no_reset: signal 17 had flags 4000000
30 Apr 06:40:56 ntpd[912]: Listen normally on 4 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
30 Apr 06:40:56 ntpd[912]: peers refreshed
30 Apr 06:40:56 ntpd[912]: new interface(s) found: waking up resolver
30 Apr 06:40:59 ntpd[728]: parent died before we finished, exiting
30 Apr 06:41:01 ntpd[912]: Listen normally on 5 wlan0 192.168.2.4 UDP 123
30 Apr 06:41:01 ntpd[912]: peers refreshed
30 Apr 06:41:01 ntpd[912]: new interface(s) found: waking up resolver
30 Apr 06:43:33 ntpd[912]: Deleting interface #5 wlan0, 192.168.2.4#123, interface stats: received=0, sent=0, dropped=0, active_time=152 secs
30 Apr 06:43:33 ntpd[912]: Deleting interface #4 wlan0, fe80::76e5:bff:fe63:2016#123, interface stats: received=0, sent=0, dropped=0, active_time=157 secs
30 Apr 06:43:33 ntpd[912]: peers refreshed
30 Apr 06:43:40 ntpd[912]: Listen normally on 6 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
30 Apr 06:43:40 ntpd[912]: peers refreshed
30 Apr 06:43:40 ntpd[912]: new interface(s) found: waking up resolver
30 Apr 06:43:49 ntpd[912]: Listen normally on 7 wlan0 192.168.2.4 UDP 123
30 Apr 06:43:49 ntpd[912]: peers refreshed
30 Apr 06:43:49 ntpd[912]: new interface(s) found: waking up resolver
30 Apr 06:46:47 ntpd[912]: Deleting interface #7 wlan0, 192.168.2.4#123, interface stats: received=0, sent=0, dropped=0, active_time=178 secs
30 Apr 06:46:47 ntpd[912]: Deleting interface #6 wlan0, fe80::76e5:bff:fe63:2016#123, interface stats: received=0, sent=0, dropped=0, active_time=187 secs
30 Apr 06:46:47 ntpd[912]: peers refreshed
30 Apr 06:46:56 ntpd[912]: Listen normally on 8 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
30 Apr 06:46:56 ntpd[912]: peers refreshed
30 Apr 06:46:56 ntpd[912]: new interface(s) found: waking up resolver
30 Apr 06:47:05 ntpd[912]: Listen normally on 9 wlan0 192.168.2.4 UDP 123
30 Apr 06:47:05 ntpd[912]: peers refreshed
30 Apr 06:47:05 ntpd[912]: new interface(s) found: waking up resolver
30 Apr 06:47:50 ntpd[912]: Deleting interface #9 wlan0, 192.168.2.4#123, interface stats: received=0, sent=0, dropped=0, active_time=45 secs
30 Apr 06:47:50 ntpd[912]: Deleting interface #8 wlan0, fe80::76e5:bff:fe63:2016#123, interface stats: received=0, sent=0, dropped=0, active_time=54 secs
30 Apr 06:47:50 ntpd[912]: peers refreshed
30 Apr 06:48:13 ntpd[912]: Listen normally on 10 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
30 Apr 06:48:13 ntpd[912]: peers refreshed
30 Apr 06:48:13 ntpd[912]: new interface(s) found: waking up resolver
30 Apr 06:48:23 ntpd[912]: Listen normally on 11 wlan0 192.168.2.4 UDP 123
30 Apr 06:48:23 ntpd[912]: peers refreshed
30 Apr 06:48:23 ntpd[912]: new interface(s) found: waking up resolver
30 Apr 06:49:05 ntpd[916]: ntpd exiting on signal 15
30 Apr 06:49:05 ntpd[912]: ntpd exiting on signal 15
30 Apr 06:50:01 ntpd[718]: Deferring DNS for 0.us.pool.ntp.org 1
30 Apr 06:50:01 ntpd[718]: Deferring DNS for 1.us.pool.ntp.org 1
30 Apr 06:50:01 ntpd[718]: Deferring DNS for 2.us.pool.ntp.org 1
30 Apr 06:50:01 ntpd[722]: signal_no_reset: signal 17 had flags 4000000
30 Apr 06:50:28 ntpd[718]: ntpd exiting on signal 1
30 Apr 06:50:29 ntpd[904]: Deferring DNS for 0.us.pool.ntp.org 1
30 Apr 06:50:29 ntpd[904]: Deferring DNS for 1.us.pool.ntp.org 1
30 Apr 06:50:29 ntpd[904]: Deferring DNS for 2.us.pool.ntp.org 1
30 Apr 06:50:29 ntpd[907]: signal_no_reset: signal 17 had flags 4000000
30 Apr 06:50:33 ntpd[904]: Listen normally on 4 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
30 Apr 06:50:33 ntpd[904]: peers refreshed
30 Apr 06:50:33 ntpd[904]: new interface(s) found: waking up resolver
30 Apr 06:50:33 ntpd[722]: parent died before we finished, exiting
30 Apr 06:50:42 ntpd[904]: Listen normally on 5 wlan0 192.168.2.4 UDP 123
30 Apr 06:50:42 ntpd[904]: peers refreshed
30 Apr 06:50:42 ntpd[904]: new interface(s) found: waking up resolver
30 Apr 06:57:05 ntpd[904]: Deleting interface #5 wlan0, 192.168.2.4#123, interface stats: received=0, sent=0, dropped=0, active_time=383 secs
30 Apr 06:57:05 ntpd[904]: Deleting interface #4 wlan0, fe80::76e5:bff:fe63:2016#123, interface stats: received=0, sent=0, dropped=0, active_time=392 secs
30 Apr 06:57:05 ntpd[904]: peers refreshed
30 Apr 06:57:12 ntpd[904]: Listen normally on 6 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
30 Apr 06:57:12 ntpd[904]: peers refreshed
30 Apr 06:57:12 ntpd[904]: new interface(s) found: waking up resolver
30 Apr 06:57:22 ntpd[904]: Listen normally on 7 wlan0 192.168.2.4 UDP 123
30 Apr 06:57:22 ntpd[904]: peers refreshed
30 Apr 06:57:22 ntpd[904]: new interface(s) found: waking up resolver
30 Apr 07:15:27 ntpd[907]: DNS 0.us.pool.ntp.org -> 169.229.70.183
30 Apr 07:15:28 ntpd[907]: DNS 1.us.pool.ntp.org -> 142.54.181.202
30 Apr 07:15:28 ntpd[907]: DNS 2.us.pool.ntp.org -> 108.61.73.244
30 Apr 19:10:28 ntpd[703]: Deferring DNS for 0.us.pool.ntp.org 1
30 Apr 19:10:28 ntpd[703]: Deferring DNS for 1.us.pool.ntp.org 1
30 Apr 19:10:28 ntpd[703]: Deferring DNS for 2.us.pool.ntp.org 1
30 Apr 19:10:28 ntpd[707]: signal_no_reset: signal 17 had flags 4000000
30 Apr 19:10:53 ntpd[703]: ntpd exiting on signal 1
30 Apr 19:10:54 ntpd[879]: Deferring DNS for 0.us.pool.ntp.org 1
30 Apr 19:10:54 ntpd[879]: Deferring DNS for 1.us.pool.ntp.org 1
30 Apr 19:10:54 ntpd[879]: Deferring DNS for 2.us.pool.ntp.org 1
30 Apr 19:10:54 ntpd[882]: signal_no_reset: signal 17 had flags 4000000
30 Apr 19:11:00 ntpd[879]: Listen normally on 4 wlan0 fe80::76e5:bff:fe63:2016 UDP 123
30 Apr 19:11:00 ntpd[879]: peers refreshed
30 Apr 19:11:00 ntpd[879]: new interface(s) found: waking up resolver
30 Apr 19:11:00 ntpd[707]: parent died before we finished, exiting
30 Apr 19:11:10 ntpd[879]: Listen normally on 5 wlan0 192.168.2.4 UDP 123
30 Apr 19:11:10 ntpd[879]: peers refreshed
30 Apr 19:11:10 ntpd[879]: new interface(s) found: waking up resolver
30 Apr 19:11:12 ntpd[882]: DNS 0.us.pool.ntp.org -> 162.210.196.6
30 Apr 19:11:13 ntpd[882]: DNS 1.us.pool.ntp.org -> 173.49.198.27
30 Apr 19:11:13 ntpd[882]: DNS 2.us.pool.ntp.org -> 129.250.35.250

The last lines, at least, are UTC, not local time. I don't know about the others.

Thanks,

Rich
 
Old 05-01-2014, 10:24 AM   #12
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,037

Rep: Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756Reputation: 756
Have you installed all the patches on the box? The kernel patches and all the others? You can get those at http://ftp.osuosl.org/pub/slackware/...ches/packages/ (note that the kernel patches are in a subdirectory of patches). Can't hurt -- remember, though, that when you install patches there will be ".new" configuration files, upgradepkg won't overwrite existing ".conf" files (and ntp is one of those). Might want to install patches in single-user mode (use inti 1 to get there, upgrade, then init 6).

The log entries of the form
Code:
 30 Apr 19:10:54 ntpd[879]: Deferring DNS for 0.us.pool.ntp.org 1
are a little disturbing, not too much, but a little -- I've never seen those in any NTP log. Makes me wonder about where you're getting DNS service (may not matter as long as you are getting DNS service -- you should be able to ping any internal or external NTP server).

I fumble-fingered a previous post; this is wrong:
Code:
grep UTC /etc/adjtime
adjtime:UTC
grep UTC hardwareclock
hardwareclock:UTC
This is right:
Code:
grep UTC /etc/* 2>/dev/null
/etc/adjtime:UTC
/etc/hardwareclock:UTC
That's my system, in which the hardware clock is UTC and all date displays are local time:
Code:
date
Thu May  1 10:51:46 EDT 2014
However you're configured, the same value (UTC or local) should appear in both those files. If not, run timeconfig and set it how you want it (either local or UTC, plus your time zone).

Grasping at straws, how about trying a different ntp.conf file that I know for sure works?

The attached file, ntp.conf.txt, is the stable (patched) version default file in which I edit the server section and added the logging section; nothing else is changed from the default. Do not edit this file.

If you want to try it,
  • Stop the NTP daemon: /etc/rc.d/rc.ntpd stop;
  • Empty your existing /var/log/ntp.log file: >/var/log/ntp.log
  • Save the attachment to your system;
  • Save a back up of your existing /etc/ntp.conf: cp /etc/ntp.conf /etc/ntp.conf.bak;
  • Copy the attached file to /etc: cp ntp.conf.txt /etc/ntp.conf;
  • Set your system clock: ntpd -g -q or, to see what happens, ntpd -b -g -q (note: this may take a minute or two). Don't use ntpdate;
  • Start the NTP daemon: /etc/rc.d/rc.ntpd start;
Immediately run ntpq -pn, you should see 4 lines, .LOCL. and three external time servers.

Wait about 5 minutes and you should see that you're synchronized (the one with the asterisk):
Code:
ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l  19h   64    0    0.000    0.000   0.000
+76.191.88.3     198.60.22.240    2 u  184 1024  377  645.839  -33.957 159.231
+208.75.89.4     69.36.224.15     2 u  829 1024  377  596.600   14.678  83.571
*134.121.64.62   .GPS.            1 u  154 1024  377  636.080  -24.942  74.741
If that doesn't happen,
Code:
cat /var/log/ntp.log
and post it (in code blocks, please).

What is the content of /etc/ntp/drift? Do cat /etc/ntp/drift and post that (in code blocks, please).

Did you edit /etc/rc.d/rc.ntpd?

Do you have any kind of a cron job that does anything with ntpdate?

Hope this helps some.
Attached Files
File Type: txt ntp.conf.txt (2.3 KB, 6 views)
 
2 members found this post helpful.
Old 06-08-2014, 11:35 AM   #13
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by tronayne View Post



Grasping at straws, how about trying a different ntp.conf file that I know for sure works?

The attached file, ntp.conf.txt, is the stable (patched) version default file in which I edit the server section and added the logging section; nothing else is changed from the default. Do not edit this file.

If you want to try it,
  • Stop the NTP daemon: /etc/rc.d/rc.ntpd stop;
  • Empty your existing /var/log/ntp.log file: >/var/log/ntp.log
  • Save the attachment to your system;
  • Save a back up of your existing /etc/ntp.conf: cp /etc/ntp.conf /etc/ntp.conf.bak;
  • Copy the attached file to /etc: cp ntp.conf.txt /etc/ntp.conf;
  • Set your system clock: ntpd -g -q or, to see what happens, ntpd -b -g -q (note: this may take a minute or two). Don't use ntpdate;
  • Start the NTP daemon: /etc/rc.d/rc.ntpd start;
Immediately run ntpq -pn, you should see 4 lines, .LOCL. and three external time servers.

Wait about 5 minutes and you should see that you're synchronized (the one with the asterisk):
Code:
ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l  19h   64    0    0.000    0.000   0.000
+76.191.88.3     198.60.22.240    2 u  184 1024  377  645.839  -33.957 159.231
+208.75.89.4     69.36.224.15     2 u  829 1024  377  596.600   14.678  83.571
*134.121.64.62   .GPS.            1 u  154 1024  377  636.080  -24.942  74.741
Done: used your ntp.conf and after 5 minutes I see a connection to 174.142.10.100.

Will post later today with update; preferably resolved.

Thanks again,

Rich
 
Old 06-08-2014, 05:27 PM   #14
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
[QUOTE=rshepard;5184619] Will post later today with update; preferably resolved.
/QUOTE]

Turns out there's a hardware issue: it won't go past the Vaio logo screen to the LILO prompt. And the user tells me it's been hanging up now and then for the past few weeks. So, tomorrow morning I take it to a repair shop to get that fixed. Could be related to the time keeping issue, too.

Before it failed to boot the time was accurate for about 5 hours. When it's back I'll check again, but I think the tweaked ntpd.conf file made a difference.

Rich
 
Old 06-09-2014, 11:08 AM   #15
hpfeil
Member
 
Registered: Nov 2010
Location: Tucson, Arizona US
Distribution: Slackware Current, custom kernel, amd64, Beyond LinuxFromScratch
Posts: 130
Blog Entries: 1

Rep: Reputation: Disabled
My clock keeps getting set to UTC by the Posix Police. /etc/rc.d/rc.ntpd won't fix it no matter how many '-g's I add, but ntpdate does work. When the Posix Police delete that, I'll compile my own.
/etc/ntp.conf:
# Use the pool, Luke!
pool 3.us.pool.ntp.org
pool 2.us.pool.ntp.org
pool 1.us.pool.ntp.org
pool 0.us.pool.ntp.org
driftfile /etc/ntp/drift

rshepard, while the computer is in the shop, ask the tech to replace the CMOS battery.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ntpdate/ntpd time is in UTC instead of local time? m4rtin Linux - Software 7 05-06-2011 07:57 AM
ntpd gives me non-local time, how can I fix it? inbayarea2010 Linux - Server 2 02-10-2011 03:57 AM
ntpd not keeping time accurate humbletech99 Linux - Networking 2 05-22-2007 09:41 AM
hwclock on a laptop is not keeping time okmyx Suse/Novell 1 12-01-2004 08:42 PM
ntpd not correcting local time plythgam Linux - Software 1 08-16-2004 04:12 PM


All times are GMT -5. The time now is 12:00 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration