On 21/02/06 14:25, Roger Oberholtzer wrote:

Anyone else have difficulty using this on boot when the network gets started via DHCP? What I 'think' is happening is that the ntp daemon does not start properly since the network is not yet functional, and never recovers when the DHCP completes. Anyone else have issues with ntp starting properly on boot? Check these:

/etc/sysconfig/network/config --> ## Type: integer ## Default: 20 # # Some interfaces need some time to come up or come asynchronously via hotplug. # WAIT_FOR_INTERFACES is a global wait for all mandatory interfaces in # seconds. If empty no wait occurs. # WAIT_FOR_INTERFACES="20" and also /etc/sysconfig/network/dhcp --> ## Type: integer ## Default: 0 # # Some interfaces need time to initialize. Add the latency time in seconds # so these can be handled properly. Should probably set per interface rather than here. # DHCLIENT_SLEEP="0" ## Type: integer ## Default: 5 # # When the DHCP client is started at boot time, the boot process will stop # until the interface is successfully configured, but at most for # DHCLIENT_WAIT_AT_BOOT seconds. # DHCLIENT_WAIT_AT_BOOT="5"

On 22/02/06 01:36, Roger Oberholtzer wrote:

On Tue, 2006-02-21 at 16:15 -0600, Darryl Gregorash wrote:

...

On 21/02/06 14:25, Roger Oberholtzer wrote:

...

Anyone else have difficulty using this on boot when the network gets started via DHCP? What I 'think' is happening is that the ntp daemon does not start properly since the network is not yet functional, and never recovers when the DHCP completes. Anyone else have issues with ntp starting properly on boot?

Check these:

/etc/sysconfig/network/config -->

## Type: integer ## Default: 20 # # Some interfaces need some time to come up or come asynchronously via hotplug. # WAIT_FOR_INTERFACES is a global wait for all mandatory interfaces in # seconds. If empty no wait occurs. # WAIT_FOR_INTERFACES="20"

and also /etc/sysconfig/network/dhcp -->

## Type: integer ## Default: 0 # # Some interfaces need time to initialize. Add the latency time in seconds # so these can be handled properly. Should probably set per interface rather than here. # DHCLIENT_SLEEP="0"

## Type: integer ## Default: 5 # # When the DHCP client is started at boot time, the boot process will stop # until the interface is successfully configured, but at most for # DHCLIENT_WAIT_AT_BOOT seconds. # DHCLIENT_WAIT_AT_BOOT="5"

My settings are these, which must be the default. It seems a hack to just wait a certain amount of time. My wireless goes through an access point that seems to take various amounts of time to respond to dhcp requests. I would expect a flag that tells when an interface is fully configured. Is this timeout the only way? I see that the system does count down 20 (from WAIT_FOR_INTERFACES I guess) when setting up the interfaces. I will extend this and see what I get.

The various scripts that use these settings aren't all that easy to follow, so I don't know if it's fair to call them 'hacks'. I expect the system will not wait forever for an interface to be fully configured, eg in case a DHCP server cannot be reached for some reason. The DHCP problems reported in this thread seem to be of this type, ie. a remote DHCP server that is slow to respond. I've now poked around the scripts enough in the past couple of days to be able to make some more suggestions. My apologies for not having them sooner, but these scripts really *are* hard to follow. First, WAIT_FOR_INTERFACES seems applicable only if MANDATORY_DEVICES is set to some value (eg. eth-id-<MAC address>) in /etc/sysconfig/network/config. If this is not set in the config file, the system will try to figure out a list of mandatory devices on its own, and I have no idea what result that will give -- is a NIC always a mandatory device?? Regardless of the answer to that question, both WAIT_FOR_INTERFACES and DHCLIENT_SLEEP only seem to insert a delay immediately after "ifconfig <dev> up" (or in newspeak, ip link set <dev> up :) ), but before the DHCP client is started. Therefore, increasing these is not going to help when we only have a delayed response from the DHCP server. We need a delay right after the DHCP client is started, and this is controlled by DHCLIENT_WAIT_AT_BOOT. The descriptions in /etc/sysconfig/network/dhcp are very vague on this point, but I cannot find anywhere at all that the ISC client "dhclient" even uses DHCLIENT_WAIT_AT_BOOT. In fact, I cannot find anywhere at all to pause the system to give dhclient time to gain an IP. For most people, dhclient is probably sufficient to configure a single nework card, but it seems that it simply will not work reliably in situations such as you describe. If you have chosen to use dhclient, you should therefore change back to dhcpcd, which is the SuSE default; for this client, the scripts make use of both DHCLIENT_SLEEP (which is simply an alternative to WAIT_FOR_INTERFACES) and DHCLIENT_WAIT_AT_BOOT. Possibly the default 5 seconds will be sufficient, but if not, you can increase this to whatever seems reasonable or necessary. In any case, the script loops once each second (approximately) to see if the DHCP reply has arrived, and continues once it has arrived. If the reply still hasn't been received after this time, the script prints a short error message and exits (the client of course is now in the background, still trying to gain an IP). Hopefully that scenario never happens with any reasonable value of the variable.

Roger Oberholtzer wrote:

My settings are these, which must be the default. It seems a hack to just wait a certain amount of time. My wireless goes through an access point that seems to take various amounts of time to respond to dhcp requests. I would expect a flag that tells when an interface is fully configured. Is this timeout the only way? I see that the system does count down 20 (from WAIT_FOR_INTERFACES I guess) when setting up the interfaces. I will extend this and see what I get.

As always, you can always use a script to determine when certain conditions are met, before starting something. As I mentioned in another note, you could always ping the ntp site and then fire up ntp when successful.

Shriramana Sharma wrote:

Wednesday, 22 February 2006 01:43 samaye, Kai Ponte alekhiit:

...

http://www.perfectreign.com/modules/articles/article.php?id=4

I tried using this method but it is giving me a warning saying if my network is not connected at startup the startup may hang or something. *Most* of the time, my linuxbox is connected to the net at startup, but if I move my PC to another place at home (which I need to do somewhat now and then) I may not be connected. I do not want my system to hang then.

So I want some application which I can startup and which will sync the clock and just exist, just like the NIST application from http://tf.nist.gov/service/its.htm (could not access the site -- can you?)

I have it set up to run in my notebook and haven't noticed any such delay. However, it is possible to delay starting it, as another mentioned or if you're really worried, start it from a script, that pings your time server and then starts up ntp when successful.

On Wednesday 22 February 2006 01:31, Shriramana Sharma wrote:

Wednesday, 22 February 2006 08:58 samaye, James Knott alekhiit:

...

mentioned or if you're really worried, start it from a script, that pings your time server and then starts up ntp when successful.

So once started does ntpd keep syncing now and then?

Unless you go into "Complex Configuration," which isn't usually necessary for desktop systems, the controls in YaST can be set to run the daemon either "Never" or "When Booting System." Carl

Shriramana Sharma wrote:

So I want some application which I can startup and which will sync the clock and just exist, just like the NIST application from http://tf.nist.gov/service/its.htm (could not access the site -- can you?)

Is this available?

ntpdate will do just that. /Per Jessen, Zürich -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.