https://bugzilla.novell.com/show_bug.cgi?id=337075
Summary: NTP daemon often fails to start under 10.3
Product: openSUSE 10.3
Version: Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
AssignedTo: bnc-team-screening@forge.provo.novell.com
ReportedBy: martin.burnicki@meinberg.de
QAContact: qa@suse.de
Found By: Customer
The startup procedure for the NTP service in OpenSUSE 10.3 urgently needs some
cleanup. After booting the start script seems to be run several times, the
first time even before the network interface is up.
If ntpd is finally started then it may stop itsel
If there is an initial time offset which has to be adjusted then running
ntpdate before starting ntpd even yields an error m
The first time ntpdate is called just after the loopback interface has been set
up, but before eth0 is up. From the syslog:
----------------------------------------------------------------------------
Oct 25 13:03:18 pc-martin5 kernel: Mobile IPv6
Oct 25 13:03:21 pc-martin5 ifup: lo
Oct 25 13:03:21 pc-martin5 ifup: lo
Oct 25 13:03:21 pc-martin5 ifup: IP address: 127.0.0.1/8
Oct 25 13:03:21 pc-martin5 ifup:
Oct 25 13:03:22 pc-martin5 ntpdate[2881]: can't find host 0.pool.ntp.org
Oct 25 13:03:22 pc-martin5 ntpdate[2881]: can't find host 1.pool.ntp.org
Oct 25 13:03:22 pc-martin5 ntpdate[2881]: can't find host 2.pool.ntp.org
Oct 25 13:03:22 pc-martin5 ntpdate[2881]: no servers can be used, exiting
Oct 25 13:03:23 pc-martin5 ifup: eth0 device: Realtek Semiconductor \
Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
Oct 25 13:03:24 pc-martin5 kernel: r8169: eth0: link up
Oct 25 13:03:24 pc-martin5 ifup-dhcp: eth0 (DHCP)
Oct 25 13:03:24 pc-martin5 ifup-dhcp: IP/Netmask: 172.16.3.106
----------------------------------------------------------------------------
So it's not surprising that ntpdate is unable to find any host, nor to use any
server. The corresponding lines from boot.msg:
----------------------------------------------------------------------------
Setting up hostname 'pc-martin5'done
Setting up loopback interface lo
lo IP address: 127.0.0.1/8
Checking for network time protocol daemon (NTPD): unused
Can't determine current runlevel
done
System Boot Control: The system has been set up
----------------------------------------------------------------------------
The above happens in runlevel N.
The next time the NTP startup script is run is when runlevel 5 is entered,
after e.g. xinetd has been started:
----------------------------------------------------------------------------
Oct 25 13:03:28 pc-martin5 xinetd[3280]: Started working: 2 available services
Oct 26 13:03:30 pc-martin5 ntpdate[3209]: step time server 85.25.139.186 \
offset 86400.268576 sec
Oct 26 13:03:30 pc-martin5 syslog-ng[2221]: STATS: dropped 0
Oct 26 13:03:30 pc-martin5 ntpd[3298]: ntpd 4.2.4p3@1.1502-o Fri Sep 21 \
21:36:25 UTC 2007 (1)
Oct 26 13:03:30 pc-martin5 ntpd[3299]: precision = 1.000 usec
Oct 26 13:03:30 pc-martin5 ntpd[3299]: ntp_io: estimated max descriptors: \
1024, initial socket boundary: 16
Oct 26 13:03:30 pc-martin5 ntpd[3299]: unable to bind to wildcard socket \
address 0.0.0.0 - another process may be \
running - EXITING
Oct 26 13:03:31 pc-martin5 ntpdate[3176]: step time server 81.169.172.219 \
offset -0.004415 sec
Oct 26 13:03:31 pc-martin5 /usr/sbin/cron[3403]: (CRON) STARTUP (V5.0)
----------------------------------------------------------------------------
In this case ntpd is started when either ntpdate or ntpd from a previous call
is still running. The message "unable to bind to wildcard socket" and "EXITING"
is logged if the NTP daemon is unable to open its well-known port 123, which is
normally the case if another ntpd is already running, or ntpdate has not yet
finished (unless run with the -q, -d, or -u parameter, ntpdate also opens port
123 to send request packets to an upstream NTP server. This in intentional to
keep ntpdate from changing the system time if ntpd is already running).
So if runlevel 5 has been reached ntpd is _not_ running anymore, even though
the startup messages on the splash screen pretend everything would be OK.
Interestingly ntpd seems to keep running if the initial time offset to be
adjusted by ntpdate is small. So a safe way to duplicate the behaviour seems to
be to change the RTC time (e.g in the BIOS setup) before the OS is booted, so
that the initial time difference exceeds the sanity limit of ntpd, which should
normally be corrected by ntpdate before ntpd is started.
BTW, maybe it would be a good idea to use the new features of ntpd which
obsolete running ntpdate at least for this purpose.
I've tested this on a fresh installation with recent online repos. The machine
was a x86_64, but that should not matter.
Martin