forcing ntpdate timeout with no network

[Ben Nizette-2]

Hi all,

I've got a system which runs ntpdate on startup but if the thing isn't
connected to a network (not uncommon for this machine) it sits there for
about a minute before failing.  This is actually long enough that the
system watchdog gets angry and resets the machine.

The ntpdate "-t" switch supposedly controls timeouts but doesn't fix
things in this case.  This switch value works fine if I've got a network
but an invalid server address but doesn't work if I just have no
network.  Given that, I assume the timeout in questions is more a TCP/IP
stack timeout thing rather than an ntpdate specific thing.  Anyone have
an idea how I can tweak that timeout?

I'm not much of a sysadmin so my thoughts centre around getting ntpdate
to generate a pid file and have something running in parallel killing
the thing after a few secs.  Anyone have better, less hackish ideas?

Thx,
        --Ben.


--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

[Dale Shaw]

Hi Ben,

On Mon, Nov 2, 2009 at 2:19 PM, Ben Nizette <bn@...> wrote:
>
> I've got a system which runs ntpdate on startup but if the thing isn't
> connected to a network (not uncommon for this machine) it sits there for
> about a minute before failing.  This is actually long enough that the
> system watchdog gets angry and resets the machine.

[...]

Does your NTP configuration file reference an IP address or a name?
Maybe the delay is name lookup-related, rather than NTP. If that's the
case, you could play with resolv.conf.

Have you considered running ntpd as a daemon (only)? I realise this
means it stays resident in memory and may bleat away in the background
when it can't sync time, but at least it's not blocking/delaying
bootup. Not sure I really understand the benefit of an ntpdate-on-boot
on a system with a real time clock. Another option may be a periodic
cron job/script with a simple "do I have network connectivity?" check
at the start.

Lastly, your problem may be distribution/release specific, so it may
help to provide those details. I found references to some ntpdate bugs
but they were all distro-specific and quite old so I didn't bother
referencing them.

cheers,
Dale
--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

[Alex Satrapa-5]

On 02/11/2009, at 14:19 , Ben Nizette wrote:

> The ntpdate "-t" switch supposedly controls timeouts but doesn't fix
> things in this case.  This switch value works fine if I've got a  
> network
> but an invalid server address but doesn't work if I just have no
> network.

It's probably DNS getting stuck in this case.  In an ideal world,  
you'd only run ntpdate if the system had an IP address and could  
verify connectivity to it's DNS servers.

One option could be to remove ntpdate from the init scripts and run it  
as part of the "up" scripts as defined in /etc/network/interfaces - on  
the assumption that having configured the network means you'll have a  
DNS server to talk to.

Alex

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

[Ben Nizette-2]

Hey Dale,

On Mon, 2009-11-02 at 14:33 +1100, Dale Shaw wrote:
> Does your NTP configuration file reference an IP address or a name?
> Maybe the delay is name lookup-related, rather than NTP. If that's the
> case, you could play with resolv.conf.

Tried both, both behave the same

>
> Have you considered running ntpd as a daemon (only)?

Yeah but...

> I realise this
> means it stays resident in memory and may bleat away in the background
> when it can't sync time, but at least it's not blocking/delaying
> bootup. Not sure I really understand the benefit of an ntpdate-on-boot
> on a system with a real time clock.

... don't have an RTC :-D  It's a little embedded board and quite poorly
designed; I've ensured the next revision will be all clock'd up but
doesn't help just yet.

>  Another option may be a periodic
> cron job/script with a simple "do I have network connectivity?" check
> at the start.

Not a bad option

>
> Lastly, your problem may be distribution/release specific, so it may
> help to provide those details. I found references to some ntpdate bugs
> but they were all distro-specific and quite old so I didn't bother
> referencing them.

No distro - the half-dozen apps on this embedded board I've just
compiled myself and scp'd across - except scp, kernel and shell which
were transferred by rather more laborious means ;-)

The ntpdate version is 4.2.4p5 which afaik is pretty recent..

Thx,
        --Ben.

>
> cheers,
> Dale

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

[Ben Nizette-2]

On Mon, 2009-11-02 at 14:35 +1100, Alex Satrapa wrote:

> On 02/11/2009, at 14:19 , Ben Nizette wrote:
>
> > The ntpdate "-t" switch supposedly controls timeouts but doesn't fix
> > things in this case.  This switch value works fine if I've got a  
> > network
> > but an invalid server address but doesn't work if I just have no
> > network.
>
> It's probably DNS getting stuck in this case.  In an ideal world,  
> you'd only run ntpdate if the system had an IP address and could  
> verify connectivity to it's DNS servers.

Yeah I might keep an eye out for proper network connectivity and do just
this

>
> One option could be to remove ntpdate from the init scripts and run it  
> as part of the "up" scripts as defined in /etc/network/interfaces - on  
> the assumption that having configured the network means you'll have a  
> DNS server to talk to.

Not a bad plan, but it appears the "up" scripts get called when ifup is
called, whether or not I've got a cable plugged in :-(

        --Ben.

>
> Alex
>

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

[Alex Satrapa-5]

On 02/11/2009, at 15:35 , Ben Nizette wrote:

> Not a bad plan, but it appears the "up" scripts get called when ifup  
> is
> called, whether or not I've got a cable plugged in :-(

Are you getting an IP address using DHCP? If so, there may be a script  
that the DHCP client invokes that you can hijack to spawn a thread  
which runs ntpdate and then quietly dies?

Alex

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

[Ben Nizette-2]

On Mon, 2009-11-02 at 15:53 +1100, Alex Satrapa wrote:
> On 02/11/2009, at 15:35 , Ben Nizette wrote:
>
> > Not a bad plan, but it appears the "up" scripts get called when ifup  
> > is
> > called, whether or not I've got a cable plugged in :-(
>
> Are you getting an IP address using DHCP? If so, there may be a script  
> that the DHCP client invokes that you can hijack to spawn a thread  
> which runs ntpdate and then quietly dies?

Ooh, that'd be nice, I'll look in to it.  It isn't a complete solution
as the board theoretically may or may not be using DHCP, but in practise
I've never heard of them assigning statically.

        --Ben.

>
> Alex
>

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

[Dale Shaw]

Hi,

On Mon, 2009-11-02 at 14:33 +1100, Dale Shaw wrote:
>> Have you considered running ntpd as a daemon (only)? [...] Not sure I really understand the benefit of an ntpdate-on-boot
>> on a system with a real time clock.

On Mon, Nov 2, 2009 at 3:31 PM, Ben Nizette <bn@...> wrote:
> Yeah but [I] don't have an RTC :-D  It's a little embedded board and quite poorly
> designed; I've ensured the next revision will be all clock'd up but
> doesn't help just yet.

There's a couple of well-known sayings about assumptions that come to
mind -- my apologies! :-)

cheers,
Dale
--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

[Sam Couter-2]

Ben Nizette <bn@...> wrote:
> Not a bad plan, but it appears the "up" scripts get called when ifup is
> called, whether or not I've got a cable plugged in :-(

Debian has a package called laptop-net which includes a daemon named
ifd which watches the media sense status on ethernet ports. You plug a
cable in that has something on the other end, and it does its thing. I
have no idea how heavy it is or whether it's suitable for an embedded
system, but it might do what you want.
--
Sam Couter         |  mailto:sam@...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C


--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux