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

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 . I don't know what GUI tools are available in Slackware.

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
If so, what does the log have in it? My log looks like this today (the log is rotated Sunday):
which is what a "normal" log will look like.

What does /usr/sbin/ntpq -pn show you? Should look a lot like this:
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
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
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,
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:
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.

1 members found this post helpful.

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.

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.

[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

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

What is the output of the following command, run as root?

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
you should see
Do this:
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
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.

[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

[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

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
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:
This is right:
That's my system, in which the hardware clock is UTC and all date displays are local time:
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):
If that doesn't happen,
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

ntp.conf.txt (2.3 KB, 63 views)

2 members found this post helpful.

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

[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

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.