LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Power outage causes ntpd to derail (http://www.linuxquestions.org/questions/slackware-14/power-outage-causes-ntpd-to-derail-4175429911/)

Wed 10-01-2012 12:23 PM

Power outage causes ntpd to derail
 
From earlier threads I have learned to set up the system to sync with timeservers. This is good and all.

On three occasions, my client system has been subjected to power loss. Every time the time has been off by an hour, almost precisely. Once it caused me to be late. Highly annoying. It makes me not trust the system to be correct. I feel that it is necessary to understand why this happens, and that I can make it not happen again.

/etc.ntp.conf contain three servers and the path to a writable driftfile, the vitals. /etc/rc.d/rc.ntpd is executable.

But seemingly, ntpd does not start at boot. And if I start it manually, it ends on its own after a few minutes. I have used "watch -n 20 ntpq -pn" on it.

Once I force a manual update of the time, the daemon stays on longer, hopefully (but certainly?) henceforth.

Please help me understand how my system should be made reliable.

michaelk 10-01-2012 01:11 PM

I suspect the CMOS battery is bad which will cause the hardware clock to drift excessively or you might just have a bad clock chip. When the computer is rebooted the system clock syncs to the hardware clock which is now wrong. Depends on how the ntp start up script is written but if the difference between the system clock and ntp time is > 1024 seconds ntp will quit assuming something is wrong.

What version of ntp is running on your system? ntpdate can be run at boot first to force the time to be correct then start the ntp daemon or if running a recent version use the -g option.

Can you post your rc.ntpd script?

Wed 10-01-2012 01:54 PM

Quote:

Originally Posted by michaelk (Post 4794214)
I suspect the CMOS battery is bad which will cause the hardware clock to drift excessively or you might just have a bad clock chip. When the computer is rebooted the system clock syncs to the hardware clock which is now wrong. Depends on how the ntp start up script is written but if the difference between the system clock and ntp time is > 1024 seconds ntp will quit assuming something is wrong.

I haven't measured the battery. Might be an idea. The machine has been running constantly the last few years, not regarding the involuntary power shortages of course.

The HW clock is set to Swedish Normal Time. That is also what it resorts to after a power cut. At the moment though, it should show DST, another hour.

Quote:

What version of ntp is running on your system? ntpdate can be run at boot first to force the time to be correct then start the ntp daemon or if running a recent version use the -g option.
ntpd - NTP daemon program - Ver. 4.2.6p3. It came with 13.37.

Quote:

Can you post your rc.ntpd script?
It too came with 13.37. I haven't fiddled with it in any other way other than making it executable.
Code:

#!/bin/sh
# Start/stop/restart ntpd.

# Start ntpd:
ntpd_start() {
  CMDLINE="/usr/sbin/ntpd -g"
  echo -n "Starting NTP daemon:  $CMDLINE"
  $CMDLINE -p /var/run/ntpd.pid
  echo
}

# Stop ntpd:
ntpd_stop() {
  echo -n "Stopping NTP daemon..."
  if [ -r /var/run/ntpd.pid ]; then
    kill -HUP $(cat /var/run/ntpd.pid)
    rm -f /var/run/ntpd.pid
  else
    killall -HUP -q ntpd
  fi
  echo
}

# Restart ntpd:
ntpd_restart() {
  ntpd_stop
  sleep 1
  ntpd_start
}

# Check if ntpd is running
ntpd_status() {
  if [ -e /var/run/ntpd.pid ]; then
    echo "ntpd is running."
  else
    echo "ntpd is stopped."
    exit 1
  fi
}

case "$1" in
'start')
  ntpd_start
  ;;
'stop')
  ntpd_stop
  ;;
'restart')
  ntpd_restart
  ;;
'status')
  ntpd_status
  ;;
*)
  echo "usage $0 start|stop|restart|status"
esac


michaelk 10-01-2012 04:15 PM

Another common problem is if the hardware clock was set to local but the OS thought it was UTC. Time would be off by the UTC offset but ntp will run happily.

ntp is starting with the -g option so it should start by forcing a time update.

ReaperX7 10-01-2012 08:54 PM

If you experience frequent outages, you should consider investing in a UPS for the workstation as frequent outages and shutdowns without proper methods can damage file integrity even on the most advanced file systems. Even cheap budget minded ones are a lifesaver to allow a few minutes to power down the machine during an outage to make sure your machine is safe. All you need to connect to it is the monitor and tower and you'll be fine.

Wed 10-02-2012 01:55 AM

No power outages are very uncommon. This time around it was because of a junction that burned off in the street, taking down two buildings. And its subsequent repair (that I was warned of beforehand). Before that, it was also a known cut for restoration in the building.

I was curious as to what would happen. And therefore I kept it running through the cut. This because of another machine in a different area that behaved in a similar way.

A UPS keeps the gateway somewhat safe. But only for 30 minutes. The large UPS can not be trusted, so is not in use.

kikinovak 10-02-2012 04:49 AM

Quote:

Originally Posted by Wed (Post 4794632)
A UPS keeps the gateway somewhat safe. But only for 30 minutes. The large UPS can not be trusted, so is not in use.

Here in South France, power outages are a daily nuisance. (<rant>Countries that are manifestly unable to supply basic commodities like electricity and/or water without daily interruptions should not be allowed to have nuclear bombs</rant>).

In my office, there are severall small UPS for desktop clients and one bigger UPS for the server. Couldn't work without it.

Petri Kaukasoina 10-02-2012 06:05 AM

Quote:

Originally Posted by michaelk (Post 4794336)
Another common problem is if the hardware clock was set to local but the OS thought it was UTC.

Or both the hardware clock and OS thought it was local time but the system was last booted before the daylight saving time started. (Only the minutes and seconds are periodically written to the hardware clock. Hours get updated only when the system is shut down cleanly.)

The hardware clock should really use UTC.

Wed 10-02-2012 08:32 AM

Quote:

Originally Posted by Petri Kaukasoina (Post 4794783)
Or both the hardware clock and OS thought it was local time but the system was last booted before the daylight saving time started. (Only the minutes and seconds are periodically written to the hardware clock. Hours get updated only when the system is shut down cleanly.)

In my case the last two occurences was within this past month, which is within DST.

Quote:

The hardware clock should really use UTC.
Agreed. Will make the change sometime. Maybe while installing Slack 14.

Skaperen 10-02-2012 10:04 PM

The ntpdate program could be run at boot up time to force the system time to be abruptly reset to the correct time. It should be done as soon as the network is up, and before any daemons are started. Throw a command in the background to set the hardware clock from the system clock about an hour later. Using ntpdate should get the clock very close, but an hours worth of letting the ntp daemon run after ntpdate should get it as close as a good hardware clock can keep it even with a good battery.

Of course, if your clock battery is bad, or the hardware clock is bad, you will always have many problems.


All times are GMT -5. The time now is 03:32 PM.