LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
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 01-20-2013, 04:01 PM   #16
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, Slackware64
Posts: 1,489

Rep: Reputation: 662Reputation: 662Reputation: 662Reputation: 662Reputation: 662Reputation: 662

Quote:
Originally Posted by stf92 View Post
In my past tries to fix the problem, I skipped the second step above. I do not say things are OK now. I have to keep an eye on it and see what happens. And of course, to thank you. Cheers.
In my experience, the one piece of documentation that you don't read will come back to bite you.
 
Old 01-20-2013, 05:08 PM   #17
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 2,994

Rep: Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737
Quote:
Originally Posted by stf92 View Post
My output to ntpq -pn is quite like yours. Now, I do not understand what happened just after 14.0 installation. All should have worked out of the box, I mean this problem should never have happened.
When you were installing Slackware 14.0, down toward the end of the setup, there's a section that offers choices of things to start at boot. One of those is NTP. Others include, oh, MySQL, Sendmail ...

The philosophy is that it's up to you to decide what you want running rather than jamming everything down your throat whether you want it or not; it's your system, your way.

Hope this helps some.

Last edited by tronayne; 01-20-2013 at 05:09 PM.
 
Old 01-20-2013, 08:41 PM   #18
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,033

Original Poster
Rep: Reputation: 45
Based on my experience with 12.0 and ntp, I'm almost sure I chose ntp. Somewhere I wrote down the default selections and the options such as I finally left them. I was about to pass these notes to some file, but I have not done it yet and the paper will have to wait till I find it. I like your "Oh".
 
Old 01-22-2013, 12:45 AM   #19
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,033

Original Poster
Rep: Reputation: 45
OK. This is from /var/log/ntp.log (see attachment). The output speaks for itself. The daemon was running while logging (now it does not), it was started by someone, hence it's executable, and post #1 shows the configuration file. Any diagnostics possible?
Attached Files
File Type: txt output.txt (4.1 KB, 18 views)

Last edited by stf92; 01-22-2013 at 01:03 AM.
 
Old 01-22-2013, 02:47 PM   #20
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 2,994

Rep: Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737
Your /etc/ntp.conf looks fine -- one thing you might want to change, though, is add or edit this to allow multicasting (it's not absolutely necessary but may help):
Code:
multicastclient 224.0.1.1
Then you should see lines like this every so often in your log:
Code:
22 Jan 14:37:41 ntpd[2003]: Listen normally on 5 multicast 224.0.1.1 UDP 123
 .
 .
 .
22 Jan 14:37:52 ntpd[2003]: Listen normally on 6 eth0 fe80::210:18ff:fe8a:82c1 UDP 123
Check your /etc/ntp/drift file; there should be a number in it, something like
Code:
cat /etc/npt/drift
-20.847
Yours, of course, will vary. If that file does not exist, you will need to create it with a zero in it (if it does exist, don't do this but do see what the value is, it's a text file, you can simply cat) it):
Code:
su -
cd /etc/ntp
cat > drift
0
Ctrl-D
Looking at your log entries, it does not appear that NTP ever synchronized. When it has synchronized, the output of ntpq -pn will look like
Code:
/usr/sbin/ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l   88   64   76    0.000    0.000   0.002
*72.8.140.200    64.147.116.229   2 u    7   64   77  1260.51   21.718  62.851
+173.255.224.22  129.6.15.29      2 u    7   64   77  1501.47   51.393  12.867
+199.7.177.206   64.147.116.229   2 u    5   64   77  1601.49  144.431  88.870
The asterisk and plus signs must appear or you're not synchronized. Before you do anything else, do this:
Code:
date
Is the result within a minute or so of the actual time? If so, do this
Code:
su -
# stop the server
/etc/rc.d/rc.ntpd stop
# start the server
/etc/rc.d/rc.ntpd start
# wait about five minutes and execute
/usr/sbin/ntpq -pn
# exit from su
If not, that usually means that the clock was too far off for NTP to sync it and the fix is
Code:
su -
# first, stop the server
/etc/rc.d/rc.ntpd stop
# use ntpdate to set the clock
ntpdate 3.ar.pool.ntp.org
# start the server
/etc/rc.d/rc.ntpd start
# wait about five minutes and exeucte
/usr/bin/ntpq -pn
Now, the use of ntpdate above is going to slew the clock to the correct time.

If your system was rebooted at some point (it looks as if it was given the log entry)
Code:
22 Jan 03:20:47 ntpd[1588]: ntpd exiting on signal 15
Were you really fiddling with it in the middle of the night? Wow.

Anyway, what happens when you shut the system down is that the system clock time is written to the hardware clock, which is kept running by a small battery on the motherboard. When the system is booted, that time is read from the hardware clock and the system clock is set to that time. The system clock is not an actual "clock;" it's timer executed by the kernel. The hardware clock is an actual clock chip (something like the ones in a wristwatch) that is kept running by the battery (system time is independent of the hardware clock after the system boots).

You've said that you were running Slackware 12? On the same hardware? It's quite possible that you've got a dead battery (Slackware 12 goes back a few years). If that's the case, the hardware clock isn't keeping time and, when the system boots, the system clock gets set to some who-knows-what time. You can tell if this is a problem by running date, write that down, reboot but enter the BIOS instead of letting the system boot.

Check the hardware clock time in the BIOS and compare the time to what the date utility showed you.

Hope this helps some.

Last edited by tronayne; 01-22-2013 at 02:50 PM.
 
Old 01-22-2013, 03:45 PM   #21
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,033

Original Poster
Rep: Reputation: 45
tronayne: thank you very much. Some points:
  • The multicastclient line is there. It takes 224.0.1.1 by default.
  • "Listen normally ..." does appear in the log.
  • /etc/npt/drift does exist.
  • The system clock does synchronize. I see in the log how it tracks the legal argentine time. And 'ntpq -pn' outputs the same as yours.
  • OS version is Slackware 14.0 and the machine, brand new, has a battery that is working. I can tell because BIOS keeps all of its values.
But the system panics by itself. I follow your procedure to start the daemon, I watch the log file and see all goes well, then suddenly, as you can see in the attachment,

LOCAL(0) MMMM NN unreachable.

A few more entries and then, it panics. That is, all this within a machine session, I mean, before turning off the machine. So, any battery problem is out of question. This is all i can say for now.

Last edited by stf92; 01-22-2013 at 06:17 PM.
 
Old 01-23-2013, 07:12 AM   #22
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 2,994

Rep: Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737
Those LOCAL unreachable messages aren't an error -- they frequently appear in the log:
Code:
grep LOCAL ntp.log
20 Jan 04:40:02 ntpd[8160]: LOCAL(0) 8011 81 mobilize assoc 42537
20 Jan 04:40:13 ntpd[8160]: LOCAL(0) 8024 84 reachable
20 Jan 04:40:13 ntpd[8160]: LOCAL(0) 903a 8a sys_peer
20 Jan 04:53:01 ntpd[8160]: LOCAL(0) 8043 83 unreachable
20 Jan 17:27:26 ntpd[8160]: LOCAL(0) 8054 84 reachable
20 Jan 17:27:26 ntpd[8160]: LOCAL(0) 906a 8a sys_peer
20 Jan 17:47:42 ntpd[8160]: LOCAL(0) 8073 83 unreachable
22 Jan 14:37:41 ntpd[2003]: LOCAL(0) 8011 81 mobilize assoc 55212
22 Jan 14:37:49 ntpd[2003]: LOCAL(0) 8024 84 reachable
22 Jan 14:37:49 ntpd[2003]: LOCAL(0) 903a 8a sys_peer
22 Jan 14:50:38 ntpd[2003]: LOCAL(0) 8043 83 unreachable
22 Jan 14:57:36 ntpd[2003]: LOCAL(0) 8054 84 reachable
22 Jan 14:57:36 ntpd[2003]: LOCAL(0) 906a 8a sys_peer
22 Jan 15:10:24 ntpd[2003]: LOCAL(0) 8073 83 unreachable
23 Jan 06:55:37 ntpd[2002]: LOCAL(0) 8011 81 mobilize assoc 26179
23 Jan 06:55:49 ntpd[2002]: LOCAL(0) 8024 84 reachable
23 Jan 06:55:49 ntpd[2002]: LOCAL(0) 903a 8a sys_peer
23 Jan 07:10:45 ntpd[2002]: LOCAL(0) 8043 83 unreachable
Log entries when the system is rebooted (I did that earlier after installing the MySQL security update today) look like this (the first entry was the shutdown):
Code:
23 Jan 06:47:49 ntpd[2003]: ntpd exiting on signal 1
23 Jan 06:55:37 ntpd[2002]: Listen normally on 5 multicast 224.0.1.1 UDP 123
23 Jan 06:55:37 ntpd[2002]: Joined 224.0.1.1 socket to multicast group 224.0.1.1
23 Jan 06:55:37 ntpd[2002]: LOCAL(0) 8011 81 mobilize assoc 26179
23 Jan 06:55:41 ntpd[2002]: 50.116.38.157 8011 81 mobilize assoc 26180
23 Jan 06:55:43 ntpd[2002]: 72.8.140.200 8011 81 mobilize assoc 26181
23 Jan 06:55:49 ntpd[2002]: 199.7.177.206 8011 81 mobilize assoc 26182
23 Jan 06:55:49 ntpd[2002]: 0.0.0.0 c016 06 restart
23 Jan 06:55:49 ntpd[2002]: 0.0.0.0 c012 02 freq_set kernel -17.132 PPM
23 Jan 06:55:49 ntpd[2002]: LOCAL(0) 8024 84 reachable
23 Jan 06:55:49 ntpd[2002]: LOCAL(0) 903a 8a sys_peer
23 Jan 06:55:49 ntpd[2002]: 0.0.0.0 c515 05 clock_sync
23 Jan 06:55:50 ntpd[2002]: Listen normally on 6 eth0 fe80::210:18ff:fe8a:82c1 UDP 123
23 Jan 06:55:50 ntpd[2002]: peers refreshed
23 Jan 06:55:50 ntpd[2002]: new interface(s) found: waking up resolver
23 Jan 06:55:52 ntpd[2002]: 50.116.38.157 8024 84 reachable
23 Jan 06:55:52 ntpd[2002]: 72.8.140.200 8024 84 reachable
23 Jan 06:55:54 ntpd[2002]: 199.7.177.206 8024 84 reachable
23 Jan 07:02:26 ntpd[2002]: 50.116.38.157 903a 8a sys_peer
23 Jan 07:06:44 ntpd[2002]: 72.8.140.200 943a 8a sys_peer
23 Jan 07:10:45 ntpd[2002]: LOCAL(0) 8043 83 unreachable
23 Jan 07:24:09 ntpd[2002]: 199.7.177.206 943a 8a sys_peer
23 Jan 07:37:21 ntpd[2002]: 72.8.140.200 941a 8a sys_peer
You might take a look in /var/log/messages and see what that might tell you. Use an editor and jump to the end of the file then search backwards for "ntpd" -- that may give an indication of why the daemon is quitting.

The whole thing about the battery is, of course, moot (new hardware, should be a good battery one would think).

By the way, what's the value stored in /etc/ntp/drift?

Last edited by tronayne; 01-23-2013 at 10:46 AM.
 
Old 01-23-2013, 10:28 AM   #23
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,033

Original Poster
Rep: Reputation: 45
Nothing odd in /var/log/messages.
Code:
semoi@darkstar:~/sma_/info/clear/cl1/correo/lvb$ cat /etc/ntp/drift
-2.750
semoi@darkstar:~/sma_/info/clear/cl1/correo/lvb$
 
Old 01-23-2013, 11:04 AM   #24
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 2,994

Rep: Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737Reputation: 737
OK, so what happens if you stop the daemon and let the clock free run for, say, 24 hours?

Just do
Code:
su -
/etc/rc.d/rc.nptd stop
Then every four hours or so use the date and the hwclock utilities to see what time it is; write those down for later reference. Neither clock should not drift by much (couple or three minutes or so) over a 24-hour period. If either one does, it may require some "tuning" with the hwclock or adjtimex utilities (you probably want to read those manual pages). Let them free run for a day before attempting any adjustments.

Also, just a thought here, do your Ethernet connections go down at night?

And, those LOCAL(0) 8043 83 unreachable messages? Those appear when you're synchronized to the three external time sources you have defined. When you run /usr/sbin/ntpq -pn the LOCALHOST line is displayed without an asterisk or plus sign when the external timeservers are active, that's why the message.

Hope this helps some.

Last edited by tronayne; 01-23-2013 at 11:05 AM.
 
Old 01-23-2013, 11:39 AM   #25
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,033

Original Poster
Rep: Reputation: 45
So LOCAL(0) is the hardware clock, or some interrupt driven by the hardware clock (aka hardware timer).

Quote:
Originally Posted by tronayne View Post
OK, so what happens if you stop the daemon and let the clock free run for, say, 24 hours?

Just do
Code:
su -
/etc/rc.d/rc.nptd stop
Then every four hours or so use the date and the hwclock utilities to see what time it is; write those down for later reference. Neither clock should not drift by much (couple or three minutes or so) over a 24-hour period. If either one does, it may require some "tuning" with the hwclock or adjtimex utilities (you probably want to read those manual pages). Let them free run for a day before attempting any adjustments.
I'll do so.

Quote:
Also, just a thought here, do your Ethernet connections go down at night?
Definitely no. Maybe some small glitches in the line?
 
Old 01-23-2013, 12:19 PM   #26
michaelk
Moderator
 
Registered: Aug 2002
Posts: 11,761

Rep: Reputation: 719Reputation: 719Reputation: 719Reputation: 719Reputation: 719Reputation: 719Reputation: 719
Local(0) is the fudge server defined in the ntp.conf and is the system clock. It is a used as fallback when the all other NTP servers (as defined in ntp.conf) or the network become unusable or unreachable. While NTP is running it will update the hardware clock periodically but it not used for anything else.
 
Old 01-23-2013, 12:22 PM   #27
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,033

Original Poster
Rep: Reputation: 45
Ahhh!
 
  


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
vsftpd not working: Connection attempt failed with "ECONNREFUSED - Connection refused davidlu766 Linux - Server 7 05-03-2010 08:34 PM
Socket Connection Failed: 111 Connection Refused degraffenried13 Linux - General 3 05-31-2009 01:17 AM
ntpq bsk66 Linux - Newbie 4 04-02-2009 09:10 AM
eth0 going down (connection reset by peer, then connection refused) Astarath Slackware 1 09-05-2007 05:14 AM
Not sure about ntpq -pn output.... r_jensen11 Linux - General 5 07-01-2004 10:35 AM


All times are GMT -5. The time now is 08:50 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