Bug 407804

Summary:	ntpd stalls boot process.
Product:	[openSUSE] openSUSE 11.0	Reporter:	Andreas Pfaller <andreas.pfaller>
Component:	Network	Assignee:	Peter Varkoly <varkoly>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Enhancement
Priority:	P5 - None	CC:	andreas.pfaller, forgotten_DHIkF8sU1p, kolAflash, mailstijn, mrueckert
Version:	Final
Target Milestone:	openSUSE 11.1
Hardware:	Other
OS:	openSUSE 11.0
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Andreas Pfaller 2008-07-10 01:34:53 UTC

Starting with openSUSE 11.0 /etc/init.d/ntp started using ntpd itself
to get an initial time (instead of ntpdate). This causes long delays
during boot if the configured timeservers are not reachable, e.g.
because of a dialup connection (ntpdate would fail immediately).

I suggest an option in /etc/sysconfig/ntp to disable the initial
time sync (or preferable make some timeout configurable for the initial ntpd
query also you seem to say its impossible - see Bug #359502).

Rationale: Many devices support ntp nowadays (some which even don't have an
internal clock). Synchronizing the times of these devices is important
in an local network even when temporarily no external connectivity exists.
This requires an internal ntp server which is always running (even if
its only always available time source is its local clock). Once external
connectivity is established this local ntp server can than start syncing with
the external sources.

Comment 1 kolA flash 2008-07-10 17:30:42 UTC

Having the same problem - very annoying when connection wlan after graphical login.

Comment 2 Forgotten User DHIkF8sU1p 2008-07-15 11:32:45 UTC

I have the same problem, my workaround is a dispatcher-script for networkmanager. 

'sleep 600' because ntpd check every 5 minutes ( -U <sec> ) for available interfaces, 10 minutes are on the secure side.
There is no external server configured in /etc/ntp.conf, only the buildin clock



bernd@schleppi:~> cat '/etc/NetworkManager/dispatcher.d/ntp'
#! /bin/sh
#
# ntp dispatcher script for NetworkManager
#
# Bernd Weigelt <xxxxx@xxxx.xyz>
#
case "$2" in
    up)
        /sbin/chkconfig --check ntp && \
            /etc/init.d/ntp restart && \
            sleep 600 && \
            /etc/init.d/ntp addserver de.pool.ntp.org
        ;;
    down)
        /sbin/chkconfig --check ntp && \
        /etc/init.d/ntp restart
        ;;
    *)
        exit 0
        ;;
esac

Comment 3 Peter Varkoly 2008-07-16 21:17:01 UTC

Are you using network manager or traditional ifup?

Comment 4 Andreas Pfaller 2008-07-16 22:05:07 UTC

ifup. The system is headless and serves as my internet gateway. External
connectivity is via pppoe (with smppd on the gateway and (k|c)internet on
my other systems). Connection to the internet is manually controlled
(no dial-on-demand).

Comment 5 Peter Varkoly 2008-09-11 06:56:20 UTC

Fixed for STABLE (SLES11 & openSUSE 11.1) 
I've introduced a new sysconfig variable: 

## Type:           yesno
## Default:        yes
## ServiceRestart: ntp
#
# Shall the time server ntpd syncronize the time by booting the system?
#
NTPD_BOOT_SYNC="yes"

Comment 6 Peter Varkoly 2008-09-11 07:03:22 UTC

*** Bug 414478 has been marked as a duplicate of this bug. ***

Comment 7 Olaf Hering 2008-09-11 10:09:30 UTC

Peter does that new sysconfig variable really fix the issue?

If I boot a testkernel on an internal buildhost, and the network driver does not work because $Linus screwed it up, what will happen?
I suspect, from the very short description, my testbox will not allow me to login on console for a very very long time just because ntp is stalled (and ntpd must run on a buildhost).

Comment 8 Peter Varkoly 2008-09-11 10:26:20 UTC

yes and for this case you can set this variable to "no".

Comment 9 Marcus Rückert 2008-09-13 04:07:54 UTC

imho you should put the check for NTPD_BOOT_SYNC around the call $0 ntptimeset.

otherwise you break "rcntp timeset" when called from a shell later.

Comment 10 Peter Varkoly 2008-09-16 13:39:17 UTC

*** Bug 425675 has been marked as a duplicate of this bug. ***