[Lunar-bugs] [Lunar Linux 0000043]: default ntp startup comes before network in /etc/rc*

[Lunar bug reports list]

The following issue has been RESOLVED.
======================================================================
<http://bugs.lunar-linux.org/view.php?id=43> 
======================================================================
Reported By:                engelsman
Assigned To:                
======================================================================
Project:                    Lunar Linux
Issue ID:                   43
Category:                   module
Reproducibility:            unable to duplicate
Severity:                   minor
Priority:                   normal
Status:                     resolved
Moonbase Version:           20051113
Core Tools:                 Lunar
Core Tools Version:         20051113
Resolution:                 unable to duplicate
Fixed in Version:           
======================================================================
Date Submitted:             11-28-2005 08:39 UTC
Last Modified:              01-05-2006 19:47 UTC
======================================================================
Summary:                    default ntp startup comes before network in /etc/rc*
Description: 
I installed ntp after the big 'lunar update' a few weeks ago, just as
daylight savings time ended, and the system time is 1-hour out after
reboot. A problem with timezone or dst settings I thought. But no, while
tidying the logs, I see that NTP always generates an error on startup
about not being able to access the servers.

The problem is that the /etc/rc*/S*ntp script is installed as a lower
S-number than the S*network script, so there is no access to the network
at all when the NTP daemon is first run.

I know that the order of startup scripts is customisable by the sysadmin
(me), but maybe the default S- and K- numbers should work out of the box,
for noobs (me)
======================================================================

----------------------------------------------------------------------
 sofar - 11-28-05 08:54 
----------------------------------------------------------------------
both ntp and openntpd have the start number at 31 - way after network (10).
Maybe an old version of the init.d scripts? check lvu from /etc/init.d/ntp
- it should list your ntp module.

----------------------------------------------------------------------
 engelsman - 11-29-05 00:13 
----------------------------------------------------------------------
yep, you're right - S10network and S31ntpd.
lvu from -> ntp:/etc/init.d/ntpd
lvu installed ntp -> 4.2.0

will investigate further in a couple of days.

----------------------------------------------------------------------
 engelsman - 12-01-05 21:45 
----------------------------------------------------------------------
Well I've investigated further.
I think I was a bit too quick off the mark with the 'always generates an
error on startup' - there were a couple of 'no servers available' in
ntp.log but since I've been tinkering I haven't seen any more.

I do get 'ntpd[2295]: no IPv6 interfaces found' in the kernel log, but
then I never configured IPv6 even before I removed it from the kernel
config.

I notice that the xfce4 clock is an hour ahead when I first boot/start
before it resyncs, but that's probably a different story altogether.

I think you should close this one, as it was probably down to the user.
If can't work out the xfce4 clock problem, I'll raise another.

----------------------------------------------------------------------
 engelsman - 12-05-05 21:11 
----------------------------------------------------------------------
sofar: I withdraw this bug report. it was user error. ntp server error
messages have not been repeated. delay in synchronisation due to hwclock
being on daylight savings time. according to ntp.log, ntp starts at
bootup, but doesn't connect to server straight away, so hwclock doesn't
get updated for 30mins or so until ntp does connect to xerver. I've just
waited for ntp to sync correctly, then called hwclock --hctosys to reset
the hardware clock. Problem solved until daylight savings time again.

----------------------------------------------------------------------
 sofar - 01-05-06 19:47 
----------------------------------------------------------------------
can't verify this - all modules in moonbase have proper chkconfig levels.

Issue History
Date Modified  Username       Field                    Change              
======================================================================
11-28-05 08:39 engelsman      New Issue                                    
11-28-05 08:39 engelsman      Moonbase Version          => 20051113        
11-28-05 08:39 engelsman      Core Tools                => Lunar           
11-28-05 08:39 engelsman      Core Tools Version        => 20051113        
11-28-05 08:54 sofar          Note Added: 0000051                          
11-28-05 08:54 sofar          Status                   new => feedback     
11-29-05 00:13 engelsman      Note Added: 0000053                          
12-01-05 21:45 engelsman      Note Added: 0000055                          
12-05-05 21:11 engelsman      Note Added: 0000057                          
01-05-06 19:47 sofar          Note Added: 0000095                          
01-05-06 19:47 sofar          Reproducibility          always => unable to
duplicate
01-05-06 19:47 sofar          Status                   feedback => resolved
01-05-06 19:47 sofar          Resolution               open => unable to
duplicate
======================================================================