Re: iburst - NTP

This is a discussion on Re: iburst - NTP ; Okay following Hal's suggestion I looked in /etc/rc.d/init.d.ntpd rather than copy over the file in it's entirety, there is a "start" function and a 'readconf' function called on startup. Those functions are: readconf() { dostep='' dropstr='' OPTIND=1 while getopts ":aAbc:dD:f:gi:k:l:LmnN ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: iburst

  1. Re: iburst

    Okay following Hal's suggestion I looked in /etc/rc.d/init.d.ntpd

    rather than copy over the file in it's entirety, there is a "start"
    function and a 'readconf' function called on startup. Those functions are:

    readconf() {
    dostep=''
    dropstr=''
    OPTIND=1
    while getopts ":aAbc:dD:f:gi:k:l:LmnN:P:qr:s:t:u:v:V:x" args $OPTIONS;
    do
    case "$args" in
    x) dostep=yes;;
    c) ntpconf="$OPTARG";;
    u) dropstr="-U $(echo $OPTARG | sed 's/:.*//')";;
    esac
    done

    [ -x /usr/sbin/ntpd -a -f $ntpconf ] || exit 0

    tickers=''
    if [ -s "$ntpstep" ]; then
    tickers=$(sed 's/#.*//' $ntpstep)
    echo "$tickers" | grep -qi '[a-z0-9]' && dostep=yes || tickers=''
    fi
    if [ -n "$dostep" -a -z "$tickers" ]; then
    # -x option is used, but step-tickers doesn't exist or contain
    # anything useful, use servers from ntp.conf instead
    tickers=$(awk '$1=="peer"||$1=="server"{print $2}' $ntpconf | \
    fgrep -v 127.127.1.0)
    fi
    }

    start() {
    readconf;

    if [ -n "$dostep" ]; then
    echo -n $"$prog: Synchronizing with time server: "
    /usr/sbin/ntpdate $dropstr -s -b $tickers 2>/dev/null >/dev/null
    RETVAL=$?
    [ $RETVAL -eq 0 ] && success || failure
    echo
    if [ $RETVAL -eq 0 ]; then
    [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    else
    OPTIONS="$OPTIONS -g"
    fi
    else
    # -g can replace the grep for time servers
    # as it permits ntpd to violate its 1000s limit once.
    OPTIONS="$OPTIONS -g"
    fi
    # Start daemons.
    echo -n $"Starting $prog: "
    daemon ntpd $OPTIONS
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/ntpd
    return $RETVAL
    }


    In watching the boot messages under FC5 the bootup process delays on the
    message:

    ntpd: Synchronizing with time server:

    the bootup then hangs with this message for minutes and finally displays
    the "OK" message and proceeds with the remainder of the bootup. In the
    start function that message is displayed by the "echo" command after the
    readconf function is called and just prior to invoking the 'ntpdate' app.

    Now my first impulse is to simply comment out the echo line and the
    ntpdate line.

    But I thought that since I am far from an expert in ntpd or ntpdate or
    command scripts, I had better ask first if that would screw things up
    really bad?

    Or should I comment and substitute another command sequence?

    Thoughts??


    --
    ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++
    ================================================== ====
    ************************************************** ****
    If you are always rushing towards the future,
    Then you never have any past.

    Terry Boldt
    ************************************************** ****
    Paraphrasing Ben Franklin:

    Those who sacrifice freedom for safety, have neither.

    The exact quote:

    They that can give up essential liberty to obtain a little
    temporary safety deserve neither liberty nor safety.
    Benjamin Franklin (1706 - 1790),
    US author, diplomat, inventor, physicist, politician, & printer
    Historical Review of Pennsylvania, 1759

    ************************************************** ****

  2. Re: iburst

    terrypearl wrote:
    > Okay following Hal's suggestion I looked in /etc/rc.d/init.d.ntpd
    >
    > rather than copy over the file in it's entirety, there is a "start"
    > function and a 'readconf' function called on startup. Those functions are:
    >
    > readconf() {
    > dostep=''
    > dropstr=''
    > OPTIND=1
    > while getopts ":aAbc:dD:f:gi:k:l:LmnN:P:qr:s:t:u:v:V:x" args
    > $OPTIONS;
    > do
    > case "$args" in
    > x) dostep=yes;;
    > c) ntpconf="$OPTARG";;
    > u) dropstr="-U $(echo $OPTARG | sed 's/:.*//')";;
    > esac
    > done
    >
    > [ -x /usr/sbin/ntpd -a -f $ntpconf ] || exit 0
    >
    > tickers=''
    > if [ -s "$ntpstep" ]; then
    > tickers=$(sed 's/#.*//' $ntpstep)
    > echo "$tickers" | grep -qi '[a-z0-9]' && dostep=yes || tickers=''
    > fi
    > if [ -n "$dostep" -a -z "$tickers" ]; then
    > # -x option is used, but step-tickers doesn't exist or contain
    > # anything useful, use servers from ntp.conf instead
    > tickers=$(awk '$1=="peer"||$1=="server"{print $2}' $ntpconf | \
    > fgrep -v 127.127.1.0)
    > fi
    > }
    >
    > start() {
    > readconf;
    >
    > if [ -n "$dostep" ]; then
    > echo -n $"$prog: Synchronizing with time server: "
    > /usr/sbin/ntpdate $dropstr -s -b $tickers 2>/dev/null >/dev/null
    > RETVAL=$?
    > [ $RETVAL -eq 0 ] && success || failure
    > echo
    > if [ $RETVAL -eq 0 ]; then
    > [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    > else
    > OPTIONS="$OPTIONS -g"
    > fi
    > else
    > # -g can replace the grep for time servers
    > # as it permits ntpd to violate its 1000s limit once.
    > OPTIONS="$OPTIONS -g"
    > fi
    > # Start daemons.
    > echo -n $"Starting $prog: "
    > daemon ntpd $OPTIONS
    > RETVAL=$?
    > echo
    > [ $RETVAL -eq 0 ] && touch /var/lock/subsys/ntpd
    > return $RETVAL
    > }
    >
    >
    > In watching the boot messages under FC5 the bootup process delays on the
    > message:
    >
    > ntpd: Synchronizing with time server:
    >
    > the bootup then hangs with this message for minutes and finally displays
    > the "OK" message and proceeds with the remainder of the bootup. In the
    > start function that message is displayed by the "echo" command after the
    > readconf function is called and just prior to invoking the 'ntpdate' app.
    >
    > Now my first impulse is to simply comment out the echo line and the
    > ntpdate line.
    >
    > But I thought that since I am far from an expert in ntpd or ntpdate or
    > command scripts, I had better ask first if that would screw things up
    > really bad?
    >
    > Or should I comment and substitute another command sequence?
    >
    > Thoughts??
    >
    >

    You are here:
    echo -n $"$prog: Synchronizing with time server: "
    /usr/sbin/ntpdate $dropstr -s -b $tickers 2>/dev/null >/dev/null

    i.e. the clock is hard set on start up.

    echo the ntpdate line to stderr to see what args are used.
    echo "/usr/sbin/ntpdate $dropstr -s -b $tickers " >&2

    If the server connections run into silent dropping of packets this
    takes for ages to time out.

    Incidentally i have a similar problem with invoking "ntpq -c peers"
    on a host that has a funky DNS. takes for ages.


    uwe


  3. Re: iburst

    On Tue, 28 Nov 2006, Uwe Klein wrote:

    > You are here:
    > echo -n $"$prog: Synchronizing with time server: "
    > /usr/sbin/ntpdate $dropstr -s -b $tickers 2>/dev/null >/dev/null
    >
    > i.e. the clock is hard set on start up.
    >
    > echo the ntpdate line to stderr to see what args are used.
    > echo "/usr/sbin/ntpdate $dropstr -s -b $tickers " >&2
    >
    > If the server connections run into silent dropping of packets this
    > takes for ages to time out.
    >
    > Incidentally i have a similar problem with invoking "ntpq -c peers"
    > on a host that has a funky DNS. takes for ages.


    There are even more extreme cases (e.g., ppp via modem) where typical
    startup scripts try to start the ntp service before the network is up.

    There are other ntp clients that are better suited to sites with
    intermittent operation or network access, but they will still suffer from
    the problems of temperature changes in systems that run intermittently.

    You can construct a list of server IP numbers using the pool URL's to get
    avoid delays due to DNS issues. This should be legit, since a normal 24/7
    ntp client will establish a list of servers at startup and continue
    to use the same servers for as long as they are running.

    For systems that run continuously but don't have reliable network access
    I've had good results using chrony :

    "It is designed so that it can work on computers which only have inter-
    mittent access to reference sources, for example computers which use a
    dial-up account to access the Internet. "

    I'd try letting chronyd run continuously overnight to get a good
    drift value, then switch to the power conserving regime and see what
    happens.

    Many systems can measure temperature at various places on the system
    board. Maybe this could be used to develop a relationship between drift
    and startup so the drift value could be fudged on cold starts.

    --
    George N. White III


+ Reply to Thread