| Message ID | 1540300218-59209-1-git-send-email-matthew.weber@rockwellcollins.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | package/ntp: use ntpd to set initial time | expand |
On 10/23/18 2:10 PM, Matt Weber wrote: > The ntpdate program has been in the process of being deprecated for > some time. (http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate) > > This patch updates the existing ntpd script to handle setting initial > time using the new ntpd "one time set and exit" approach. I still think this should be a separate script, e.g. S48ntpdate. But OK, I'm not going to block the patch for that. > > Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> > Signed-off-by: Oscar Gomez Fuente <oscargomezf@gmail.com> > --- > Based on Oscar's v1 patch to add a ntpdate startup script. > http://patchwork.ozlabs.org/patch/986852/ > --- > package/ntp/Config.in | 5 +++++ > package/ntp/S49ntp | 17 +++++++++++++++++ > 2 files changed, 22 insertions(+) > > diff --git a/package/ntp/Config.in b/package/ntp/Config.in > index efd47e1..5cc78ce 100644 > --- a/package/ntp/Config.in > +++ b/package/ntp/Config.in > @@ -54,6 +54,11 @@ config BR2_PACKAGE_NTP_NTPDATE > The ntpdate utility program is used to set the local date > and time from an NTP server given as an argument. > > + This option is deprecated by upstream and replaced with the > + -gq options of ntpd. The package/ntp/S49ntp script has an > + example implementation. > + (http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate) > + > config BR2_PACKAGE_NTP_NTPDC > bool "ntpdc" > help > diff --git a/package/ntp/S49ntp b/package/ntp/S49ntp > index 35e5874..9851747 100755 > --- a/package/ntp/S49ntp > +++ b/package/ntp/S49ntp > @@ -11,6 +11,23 @@ fi > case "$1" in > start) > printf "Starting $NAME: " This should be done after the ntpdate run. > + NTP_WAIT_DELAY=15 #sec This should be done before sourcing the defaults file, so it can be overridden. > + CURRENT_DATE=$(date | grep "1970") So, you didn't like my proposal to use the Unix timestamp (to avoid any possible issue with localtime): CURRENT_UNIX_TIME="$(date +%s)" if [ $CURRENT_UNIX_TIME -lt 1000000000 ]; then > + if [ "$CURRENT_DATE" != "" ]; then > + printf "checking for time" > + /usr/sbin/ntpd -g -q > /dev/null 2>&1 & Why redirect stderr and stdout? > + NTP_PID=$! > + while [ ${NTP_WAIT_DELAY} -gt 0 ]; do > + [ ! -e /proc/$NTP_PID ] && break > + sleep 1 > + printf "." > + : $((NTP_WAIT_DELAY -= 1)) > + done This is horribly ugly, but there is no better way because the timeout applet is not enabled in our busybox config. One small improvement could be to use the -p option to save it in a PID file. However, is there any reason to not just add the "-w $NTP_WAIT_DELAY" option to the normal invocation of ntpd, below? I haven't tried it, I just thought that that is what is supposed to be the replacement of the initial ntpdate command. So my proposal would be: NTPD_WAIT_ARG="" CURRENT_UNIX_TIME="$(date +%s)" if [ $CURRENT_UNIX_TIME -lt 1000000000 ]; then NTPD_WAIT_ARG="-w ${NTP_WAIT_DELAY}" fi start-stop-daemon -S -q -x /usr/sbin/ntpd -- -g $NTPD_WAIT_ARG It would actually even make sense to set the wait delay to a low value (say, 1). I've had quite a few boards where the RTC is wildly inaccurate, off by a few seconds after a day or so. But maybe that is a bit too board-specific. And would anyway be a separate patch. Note that with -w, ntpd returns ETIMEDOUT if it times out, and unfortunately that value is platform-dependent (145 on mips, 60 on sparc, 110 on others). So it's a bit tricky to handle that properly. Without handling, the init script will return FAIL while the daemon is actually running. Regards, Arnout > + # ntpd never returns if it can't access the NTP server(s) > + # noted in /etc/ntp.conf. > + kill $NTP_PID > /dev/null 2>&1 > + [ $? = 0 ] && printf "(Not set): " > + fi > start-stop-daemon -S -q -x /usr/sbin/ntpd -- -g > [ $? = 0 ] && echo "OK" || echo "FAIL" > ;; >
Arnout, On Tue, Oct 23, 2018 at 3:31 PM Arnout Vandecappelle <arnout@mind.be> wrote: > > > > On 10/23/18 2:10 PM, Matt Weber wrote: > > The ntpdate program has been in the process of being deprecated for > > some time. (http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate) > > > > This patch updates the existing ntpd script to handle setting initial > > time using the new ntpd "one time set and exit" approach. > > I still think this should be a separate script, e.g. S48ntpdate. But OK, I'm > not going to block the patch for that. > > > > > Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> > > Signed-off-by: Oscar Gomez Fuente <oscargomezf@gmail.com> > > --- > > Based on Oscar's v1 patch to add a ntpdate startup script. > > http://patchwork.ozlabs.org/patch/986852/ > > --- > > package/ntp/Config.in | 5 +++++ > > package/ntp/S49ntp | 17 +++++++++++++++++ > > 2 files changed, 22 insertions(+) > > > > diff --git a/package/ntp/Config.in b/package/ntp/Config.in > > index efd47e1..5cc78ce 100644 > > --- a/package/ntp/Config.in > > +++ b/package/ntp/Config.in > > @@ -54,6 +54,11 @@ config BR2_PACKAGE_NTP_NTPDATE > > The ntpdate utility program is used to set the local date > > and time from an NTP server given as an argument. > > > > + This option is deprecated by upstream and replaced with the > > + -gq options of ntpd. The package/ntp/S49ntp script has an > > + example implementation. > > + (http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate) > > + > > config BR2_PACKAGE_NTP_NTPDC > > bool "ntpdc" > > help > > diff --git a/package/ntp/S49ntp b/package/ntp/S49ntp > > index 35e5874..9851747 100755 > > --- a/package/ntp/S49ntp > > +++ b/package/ntp/S49ntp > > @@ -11,6 +11,23 @@ fi > > case "$1" in > > start) > > printf "Starting $NAME: " > > This should be done after the ntpdate run. Sure, do you think it is still good to have the information prints about checking and if set or not? > > > + NTP_WAIT_DELAY=15 #sec > > This should be done before sourcing the defaults file, so it can be overridden. Sure. > > > + CURRENT_DATE=$(date | grep "1970") > > So, you didn't like my proposal to use the Unix timestamp (to avoid any > possible issue with localtime): I'll switch to unix. > > CURRENT_UNIX_TIME="$(date +%s)" > if [ $CURRENT_UNIX_TIME -lt 1000000000 ]; then > > > + if [ "$CURRENT_DATE" != "" ]; then > > + printf "checking for time" > > + /usr/sbin/ntpd -g -q > /dev/null 2>&1 & > > Why redirect stderr and stdout? Habit, I'll see if just stdout keeps it clean for the basic output. Err I guess would be good to see. > > > + NTP_PID=$! > > + while [ ${NTP_WAIT_DELAY} -gt 0 ]; do > > + [ ! -e /proc/$NTP_PID ] && break > > + sleep 1 > > + printf "." > > + : $((NTP_WAIT_DELAY -= 1)) > > + done > > This is horribly ugly, but there is no better way because the timeout applet is > not enabled in our busybox config. One small improvement could be to use the -p > option to save it in a PID file. > True. > However, is there any reason to not just add the "-w $NTP_WAIT_DELAY" option to > the normal invocation of ntpd, below? I haven't tried it, I just thought that > that is what is supposed to be the replacement of the initial ntpdate command. > From what I can tell and tested, it just waits until the first time is sync'd correctly. It doesn't do the one shot setting of the initial time (must -g and should do -q so it exits). So since we have the case of the time possibly not being valid, I'm not sure we'd want to add the -w to our actual ntpd service start so that it would wait for the other ntpd -g to get time. We already handle this with the NTP_WAIT_DELAY that manages the ntpd -gq process state. http://lists.ntp.org/pipermail/questions/2011-July/030041.html > So my proposal would be: > > NTPD_WAIT_ARG="" > CURRENT_UNIX_TIME="$(date +%s)" > if [ $CURRENT_UNIX_TIME -lt 1000000000 ]; then > NTPD_WAIT_ARG="-w ${NTP_WAIT_DELAY}" > fi > start-stop-daemon -S -q -x /usr/sbin/ntpd -- -g $NTPD_WAIT_ARG > > It would actually even make sense to set the wait delay to a low value (say, > 1). I've had quite a few boards where the RTC is wildly inaccurate, off by a few > seconds after a day or so. But maybe that is a bit too board-specific. And would > anyway be a separate patch. > > Note that with -w, ntpd returns ETIMEDOUT if it times out, and unfortunately > that value is platform-dependent (145 on mips, 60 on sparc, 110 on others). So > it's a bit tricky to handle that properly. Without handling, the init script > will return FAIL while the daemon is actually running. Yeah, I was sort of thinking of keeping it simple by not changing the existing ntpd behavior at all and just adding the one shot support in a reliable manner above it. -w feels like something that would need to be tuned and we'd still need the code to kill the -gq process. Matt
On 10/24/18 4:26 AM, Matthew Weber wrote: > Arnout, > > On Tue, Oct 23, 2018 at 3:31 PM Arnout Vandecappelle <arnout@mind.be> wrote: [snip] >> However, is there any reason to not just add the "-w $NTP_WAIT_DELAY" option to >> the normal invocation of ntpd, below? I haven't tried it, I just thought that >> that is what is supposed to be the replacement of the initial ntpdate command. >> > > From what I can tell and tested, it just waits until the first time is > sync'd correctly. It doesn't do the one shot setting of the initial > time (must -g and should do -q so it exits). So since we have the > case of the time possibly not being valid, I'm not sure we'd want to > add the -w to our actual ntpd service start so that it would wait for > the other ntpd -g to get time. We already handle this with the > NTP_WAIT_DELAY that manages the ntpd -gq process state. > http://lists.ntp.org/pipermail/questions/2011-July/030041.html > >> So my proposal would be: >> >> NTPD_WAIT_ARG="" >> CURRENT_UNIX_TIME="$(date +%s)" >> if [ $CURRENT_UNIX_TIME -lt 1000000000 ]; then >> NTPD_WAIT_ARG="-w ${NTP_WAIT_DELAY}" >> fi >> start-stop-daemon -S -q -x /usr/sbin/ntpd -- -g $NTPD_WAIT_ARG >> >> It would actually even make sense to set the wait delay to a low value (say, >> 1). I've had quite a few boards where the RTC is wildly inaccurate, off by a few >> seconds after a day or so. But maybe that is a bit too board-specific. And would >> anyway be a separate patch. >> >> Note that with -w, ntpd returns ETIMEDOUT if it times out, and unfortunately >> that value is platform-dependent (145 on mips, 60 on sparc, 110 on others). So >> it's a bit tricky to handle that properly. Without handling, the init script >> will return FAIL while the daemon is actually running. > > Yeah, I was sort of thinking of keeping it simple by not changing the > existing ntpd behavior at all and just adding the one shot support in > a reliable manner above it. -w feels like something that would need > to be tuned and we'd still need the code to kill the -gq process. Just to be clear: the idea is to NOT do the -gq process, so it doesn't need to be killed. Instead, you do just ONE invocation of ntpd with the -g option (so the first time it gets a time, it does a big jump; we may want to add -G as well for smaller jumps in case of an inaccurate RTC). As far as I understand, this should do the same as what we attempt to do here: wait for one clock adjustment to finish before continuing, but time out and continue with the wrong time if that clock adjustment doesn't happen within 15 seconds. Regards, Arnout
Arnout, On Wed, Oct 24, 2018 at 8:10 AM Arnout Vandecappelle <arnout@mind.be> wrote: > > > > On 10/24/18 4:26 AM, Matthew Weber wrote: > > Arnout, > > > > On Tue, Oct 23, 2018 at 3:31 PM Arnout Vandecappelle <arnout@mind.be> wrote: > [snip] > >> However, is there any reason to not just add the "-w $NTP_WAIT_DELAY" option to > >> the normal invocation of ntpd, below? I haven't tried it, I just thought that > >> that is what is supposed to be the replacement of the initial ntpdate command. > >> > > > > From what I can tell and tested, it just waits until the first time is > > sync'd correctly. It doesn't do the one shot setting of the initial > > time (must -g and should do -q so it exits). So since we have the > > case of the time possibly not being valid, I'm not sure we'd want to > > add the -w to our actual ntpd service start so that it would wait for > > the other ntpd -g to get time. We already handle this with the > > NTP_WAIT_DELAY that manages the ntpd -gq process state. > > http://lists.ntp.org/pipermail/questions/2011-July/030041.html > > > >> So my proposal would be: > >> > >> NTPD_WAIT_ARG="" > >> CURRENT_UNIX_TIME="$(date +%s)" > >> if [ $CURRENT_UNIX_TIME -lt 1000000000 ]; then > >> NTPD_WAIT_ARG="-w ${NTP_WAIT_DELAY}" > >> fi > >> start-stop-daemon -S -q -x /usr/sbin/ntpd -- -g $NTPD_WAIT_ARG > >> > >> It would actually even make sense to set the wait delay to a low value (say, > >> 1). I've had quite a few boards where the RTC is wildly inaccurate, off by a few > >> seconds after a day or so. But maybe that is a bit too board-specific. And would > >> anyway be a separate patch. > >> > >> Note that with -w, ntpd returns ETIMEDOUT if it times out, and unfortunately > >> that value is platform-dependent (145 on mips, 60 on sparc, 110 on others). So > >> it's a bit tricky to handle that properly. Without handling, the init script > >> will return FAIL while the daemon is actually running. > > > > Yeah, I was sort of thinking of keeping it simple by not changing the > > existing ntpd behavior at all and just adding the one shot support in > > a reliable manner above it. -w feels like something that would need > > to be tuned and we'd still need the code to kill the -gq process. > > Just to be clear: the idea is to NOT do the -gq process, so it doesn't need to > be killed. Instead, you do just ONE invocation of ntpd with the -g option (so > the first time it gets a time, it does a big jump; we may want to add -G as well > for smaller jumps in case of an inaccurate RTC). As far as I understand, this > should do the same as what we attempt to do here: wait for one clock adjustment > to finish before continuing, but time out and continue with the wrong time if > that clock adjustment doesn't happen within 15 seconds. > Agree. So if we do the one invocation we'll have to figure out how to deal with the return value. Sounds like that is desired, so I'll put together a test and see. For the -w value, from testing it looks like the -w should probably be ~10-15sec as a sync on average was ~8-9sec. Matt
On 10/24/18 2:14 PM, Matthew Weber wrote: > Agree. So if we do the one invocation we'll have to figure out how to > deal with the return value. Sounds like that is desired, so I'll put > together a test and see. For the -w value, from testing it looks like > the -w should probably be ~10-15sec as a sync on average was ~8-9sec. 8 seconds is not good. We want to get the same sync time as with ntpdate, otherwise we're doing something wrong. And I guess ntpdate does it in a second, right? If I remember correctly (but it has been *years* since I used ntpd rather than chrony or systemd-timesyncd) ntpd had options for how fast it would converge on the first sync. Normally when a new peer is added, it waits for a couple of round trips before that peer is accepted as a healthy source. But I thought it was possible (and hopefully default) to just believe the first packet you receive during startup and sync on that.
Hi Arnout, > 8 seconds is not good. We want to get the same sync time as with ntpdate, > otherwise we're doing something wrong. And I guess ntpdate does it in a second, > right? I made a test on my Raspberry Pi 3B+ and it took me around 10-12 seconds to execute ntpdate. Best regards. Oscar Gomez Fuente TST Sistemas www.tst-sistemas.es
Arnout, Oscar, On Wed, Oct 24, 2018 at 10:02 AM Arnout Vandecappelle <arnout@mind.be> wrote: > > > > On 10/24/18 2:14 PM, Matthew Weber wrote: > > > Agree. So if we do the one invocation we'll have to figure out how to > > deal with the return value. Sounds like that is desired, so I'll put > > together a test and see. For the -w value, from testing it looks like > > the -w should probably be ~10-15sec as a sync on average was ~8-9sec. > > 8 seconds is not good. We want to get the same sync time as with ntpdate, > otherwise we're doing something wrong. And I guess ntpdate does it in a second, > right? > > If I remember correctly (but it has been *years* since I used ntpd rather than > chrony or systemd-timesyncd) ntpd had options for how fast it would converge on > the first sync. Normally when a new peer is added, it waits for a couple of > round trips before that peer is accepted as a healthy source. But I thought it > was possible (and hopefully default) to just believe the first packet you > receive during startup and sync on that. All the research I've found and also inspection of the code leads me to believe that the -w option can be used to wait for an initial sync of "good time". Not an initial step which is large and set to system time right away. I've submitted a v3 using the new sntp tool which I believe has got some traction as the replacement for ntpdate. https://patchwork.ozlabs.org/patch/991267/ Oscar, this new script should sync time quite fast ~1sec in my QEMU. Matt
Hi everyone, I was checking it on my Raspberry Pi 3B+ and it works perfectly. The only weird thing is the log related to the other ntp servers, but I think they are normal. It sees to be that they are duplicated, the alternative servers exist in case one of them it was down, so it is ok. -----> # date --set "1970-01-01 10:10:00" Thu Jan 1 10:10:00 UTC 1970 # sntp -K /tmp/kod -sS -M 128 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org sntp 4.2.8p12@1.3728-o Wed Oct 31 08:22:38 UTC 2018 (1) 213.251.52.234:123 0.pool.ntp.org duplicate address from 1.pool.ntp.org ignored. 37.139.121.60:123 0.pool.ntp.org duplicate address from 1.pool.ntp.org ignored. 185.132.136.116:123 0.pool.ntp.org duplicate address from 1.pool.ntp.org ignored. 81.19.96.148:123 0.pool.ntp.org duplicate address from 1.pool.ntp.org ignored. 213.251.52.234:123 0.pool.ntp.org duplicate address from 2.pool.ntp.org ignored. 81.19.96.148:123 0.pool.ntp.org duplicate address from 2.pool.ntp.org ignored. 185.132.136.116:123 0.pool.ntp.org duplicate address from 2.pool.ntp.org ignored. 37.139.121.60:123 0.pool.ntp.org duplicate address from 2.pool.ntp.org ignored. Send to [2001:720:1014:a205::2]:123 failed, Network is unreachable 213.251.52.234:123 0.pool.ntp.org duplicate address from 3.pool.ntp.org ignored. 81.19.96.148:123 0.pool.ntp.org duplicate address from 3.pool.ntp.org ignored. 185.132.136.116:123 0.pool.ntp.org duplicate address from 3.pool.ntp.org ignored. 37.139.121.60:123 0.pool.ntp.org duplicate address from 3.pool.ntp.org ignored. Send to [2001:720:1014:a202::2]:123 failed, Network is unreachable 1970-01-01 10:10:05.624784 (+0000) +1540938259.059756 +/- 1027292172.738343 0.pool.ntp.org 213.251.52.234 s2 no-leap # date Wed Oct 31 08:34:26 UTC 2018 -----> Great Job! Best regards. Oscar Gomez Fuente TST Sistemas www.tst-sistemas.es
Oscar, On Wed, Oct 31, 2018 at 3:38 AM Oscar Gomez Fuente <oscargomezf@gmail.com> wrote: > > Hi everyone, > > I was checking it on my Raspberry Pi 3B+ and it works perfectly. > > The only weird thing is the log related to the other ntp servers, but > I think they are normal. It sees to be that they are duplicated, the > alternative servers exist in case one of them it was down, so it is > ok. > > -----> > # date --set "1970-01-01 10:10:00" > Thu Jan 1 10:10:00 UTC 1970 > > # sntp -K /tmp/kod -sS -M 128 0.pool.ntp.org 1.pool.ntp.org > 2.pool.ntp.org 3.pool.ntp.org > sntp 4.2.8p12@1.3728-o Wed Oct 31 08:22:38 UTC 2018 (1) > 213.251.52.234:123 0.pool.ntp.org duplicate address from 1.pool.ntp.org ignored. > 37.139.121.60:123 0.pool.ntp.org duplicate address from 1.pool.ntp.org ignored. > 185.132.136.116:123 0.pool.ntp.org duplicate address from > 1.pool.ntp.org ignored. > 81.19.96.148:123 0.pool.ntp.org duplicate address from 1.pool.ntp.org ignored. > 213.251.52.234:123 0.pool.ntp.org duplicate address from 2.pool.ntp.org ignored. > 81.19.96.148:123 0.pool.ntp.org duplicate address from 2.pool.ntp.org ignored. > 185.132.136.116:123 0.pool.ntp.org duplicate address from > 2.pool.ntp.org ignored. > 37.139.121.60:123 0.pool.ntp.org duplicate address from 2.pool.ntp.org ignored. > Send to [2001:720:1014:a205::2]:123 failed, Network is unreachable > 213.251.52.234:123 0.pool.ntp.org duplicate address from 3.pool.ntp.org ignored. > 81.19.96.148:123 0.pool.ntp.org duplicate address from 3.pool.ntp.org ignored. > 185.132.136.116:123 0.pool.ntp.org duplicate address from > 3.pool.ntp.org ignored. > 37.139.121.60:123 0.pool.ntp.org duplicate address from 3.pool.ntp.org ignored. > Send to [2001:720:1014:a202::2]:123 failed, Network is unreachable > 1970-01-01 10:10:05.624784 (+0000) +1540938259.059756 +/- > 1027292172.738343 0.pool.ntp.org 213.251.52.234 s2 no-leap > > # date > Wed Oct 31 08:34:26 UTC 2018 > -----> I debated keeping all the pool servers in the list. When the sntp agent resolves any of the "0/1/2/3.pool.ntp.org or pool.ntp.org", the DNS response is 4 server IPs. The sntp agent then uses all 4 in serial or a -c flag can be set to concurrently check them. So realistically just pool.ntp.org could be set as the sole server, assuming there are 4 servers provided when it resolves. Matt
Oscar, On Wed, Oct 31, 2018 at 7:44 AM Matthew Weber <matthew.weber@rockwellcollins.com> wrote: > > Oscar, > > On Wed, Oct 31, 2018 at 3:38 AM Oscar Gomez Fuente > <oscargomezf@gmail.com> wrote: > > > > Hi everyone, > > > > I was checking it on my Raspberry Pi 3B+ and it works perfectly. > > > > The only weird thing is the log related to the other ntp servers, but > > I think they are normal. It sees to be that they are duplicated, the > > alternative servers exist in case one of them it was down, so it is > > ok. > > > > -----> > > # date --set "1970-01-01 10:10:00" > > Thu Jan 1 10:10:00 UTC 1970 > > > > # sntp -K /tmp/kod -sS -M 128 0.pool.ntp.org 1.pool.ntp.org > > 2.pool.ntp.org 3.pool.ntp.org > > sntp 4.2.8p12@1.3728-o Wed Oct 31 08:22:38 UTC 2018 (1) > > 213.251.52.234:123 0.pool.ntp.org duplicate address from 1.pool.ntp.org ignored. > > 37.139.121.60:123 0.pool.ntp.org duplicate address from 1.pool.ntp.org ignored. > > 185.132.136.116:123 0.pool.ntp.org duplicate address from > > 1.pool.ntp.org ignored. > > 81.19.96.148:123 0.pool.ntp.org duplicate address from 1.pool.ntp.org ignored. > > 213.251.52.234:123 0.pool.ntp.org duplicate address from 2.pool.ntp.org ignored. > > 81.19.96.148:123 0.pool.ntp.org duplicate address from 2.pool.ntp.org ignored. > > 185.132.136.116:123 0.pool.ntp.org duplicate address from > > 2.pool.ntp.org ignored. > > 37.139.121.60:123 0.pool.ntp.org duplicate address from 2.pool.ntp.org ignored. > > Send to [2001:720:1014:a205::2]:123 failed, Network is unreachable > > 213.251.52.234:123 0.pool.ntp.org duplicate address from 3.pool.ntp.org ignored. > > 81.19.96.148:123 0.pool.ntp.org duplicate address from 3.pool.ntp.org ignored. > > 185.132.136.116:123 0.pool.ntp.org duplicate address from > > 3.pool.ntp.org ignored. > > 37.139.121.60:123 0.pool.ntp.org duplicate address from 3.pool.ntp.org ignored. > > Send to [2001:720:1014:a202::2]:123 failed, Network is unreachable > > 1970-01-01 10:10:05.624784 (+0000) +1540938259.059756 +/- > > 1027292172.738343 0.pool.ntp.org 213.251.52.234 s2 no-leap > > > > # date > > Wed Oct 31 08:34:26 UTC 2018 > > -----> > > I debated keeping all the pool servers in the list. When the sntp > agent resolves any of the "0/1/2/3.pool.ntp.org or pool.ntp.org", the > DNS response is 4 server IPs. The sntp agent then uses all 4 in > serial or a -c flag can be set to concurrently check them. So > realistically just pool.ntp.org could be set as the sole server, > assuming there are 4 servers provided when it resolves. > Would you mind testing my v4 patch which defaults to one server and if all looks good, provide your tested-by on that patch's email? https://patchwork.ozlabs.org/patch/992167/
Hi Matthew, > Would you mind testing my v4 patch which defaults to one server and if > all looks good, provide your tested-by on that patch's email? > https://patchwork.ozlabs.org/patch/992167/ Ok, It will have to be on Monday because I'm out of the office until Monday. Best regards.
Hi Matthew, I was able to connect by VPN and check the new patch v4. Everything works fine on my Raspberry Pi 3B+: # /etc/init.d/S49ntp stop Stopping ntpd: OK # date Sat Nov 3 15:41:17 UTC 2018 # date --set "1970-02-01 10:10:10" Sun Feb 1 10:10:10 UTC 1970 # date Sun Feb 1 10:10:11 UTC 1970 # /etc/init.d/S48sntp start Starting sntp: sntp 4.2.8p12@1.3728-o Wed Oct 31 08:22:38 UTC 2018 (1) 1970-02-01 10:10:24.982820 (+0000) +1538544675.515026 +/- 1025696450.421369 pool.ntp.org 37.139.121.60 s2 no-leap OK # date Sat Nov 3 15:41:42 UTC 2018 But I don't how to do that: > >... provide your tested-by on that patch's email? > > https://patchwork.ozlabs.org/patch/992167/ Best regards. Oscar Gomez Fuente TST Sistemas www.tst-sistemas.es
On 03/11/18 16:49, Oscar Gomez Fuente wrote: > Hi Matthew, > > > I was able to connect by VPN and check the new patch v4. Everything > works fine on my Raspberry Pi 3B+: > > # /etc/init.d/S49ntp stop > Stopping ntpd: OK > # date > Sat Nov 3 15:41:17 UTC 2018 > # date --set "1970-02-01 10:10:10" > Sun Feb 1 10:10:10 UTC 1970 > # date > Sun Feb 1 10:10:11 UTC 1970 > # /etc/init.d/S48sntp start > Starting sntp: > sntp 4.2.8p12@1.3728-o Wed Oct 31 08:22:38 UTC 2018 (1) > 1970-02-01 10:10:24.982820 (+0000) +1538544675.515026 +/- > 1025696450.421369 pool.ntp.org 37.139.121.60 s2 no-leap > OK > # date > Sat Nov 3 15:41:42 UTC 2018 > > But I don't how to do that: > >>> ... provide your tested-by on that patch's email? >>> https://patchwork.ozlabs.org/patch/992167/ Just reply to the patch with this line in the mail: Tested-by: Oscar Gomez Fuente <oscargomezf@gmail.com> (now you don't need to do it anymore since I already did). This gets picked up by Patchwork, so you can see in [1] that your tested-by line has been added to the commit message. Regards, Arnout [1] http://patchwork.ozlabs.org/patch/992167/mbox/
diff --git a/package/ntp/Config.in b/package/ntp/Config.in index efd47e1..5cc78ce 100644 --- a/package/ntp/Config.in +++ b/package/ntp/Config.in @@ -54,6 +54,11 @@ config BR2_PACKAGE_NTP_NTPDATE The ntpdate utility program is used to set the local date and time from an NTP server given as an argument. + This option is deprecated by upstream and replaced with the + -gq options of ntpd. The package/ntp/S49ntp script has an + example implementation. + (http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate) + config BR2_PACKAGE_NTP_NTPDC bool "ntpdc" help diff --git a/package/ntp/S49ntp b/package/ntp/S49ntp index 35e5874..9851747 100755 --- a/package/ntp/S49ntp +++ b/package/ntp/S49ntp @@ -11,6 +11,23 @@ fi case "$1" in start) printf "Starting $NAME: " + NTP_WAIT_DELAY=15 #sec + CURRENT_DATE=$(date | grep "1970") + if [ "$CURRENT_DATE" != "" ]; then + printf "checking for time" + /usr/sbin/ntpd -g -q > /dev/null 2>&1 & + NTP_PID=$! + while [ ${NTP_WAIT_DELAY} -gt 0 ]; do + [ ! -e /proc/$NTP_PID ] && break + sleep 1 + printf "." + : $((NTP_WAIT_DELAY -= 1)) + done + # ntpd never returns if it can't access the NTP server(s) + # noted in /etc/ntp.conf. + kill $NTP_PID > /dev/null 2>&1 + [ $? = 0 ] && printf "(Not set): " + fi start-stop-daemon -S -q -x /usr/sbin/ntpd -- -g [ $? = 0 ] && echo "OK" || echo "FAIL" ;;