Qsync problem - successful sync, but then retries forever

[Stogie]

.
Hi guys. I'm on Easy Buster, and I'm having a problem with qsync.

When the qsync service is enabled, after bootup the system time is indeed correctly set after a few seconds of the internet connection going active, which is fine, but it looks like qsync keeps trying to sync again, about every 5-6 seconds, apparently forever.

After every 5-6 seconds of an empty 'netstat' command, I get this for 5-7 seconds:

Code: Select all

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 0.0.0.0:123             0.0.0.0:*                           9211/ntpdate
udp6       0      0 :::123                  :::*                                9211/ntpdate

Then, empty 'netstat' for another 5-6 seconds, then the above again. It seemingly repeats forever.

Because it looks like it worked just fine the first time (as verified by looking at the system clock), why does this happen? I DO NOT want to keep spamming the ntp servers every 5-6 seconds, 24x7, for no reason.

I noticed that doing my own 'ntpdate pool.ntp.org' command does not stop the problem, so I tried running /usr/sbin/qsync which brought up the GUI, so I appended --help to look for a 'run silently, no GUI' option, but merely appending --help did exactly that. No GUI, and during the run, netstat showed it connected to north-america.ntp.org and updated the time, then exited and the command prompt returned. It also stopped the problem! No more NTP connections every 5-6 seconds. Even weirder, the problem remained gone even after multiple reboots!

Why would that fix it? Anyway, in case the fix isn't permanent, I made a script and put it in /root/Startup. It sleeps for 30 seconds (to let the internet connection get established), then does "/usr/sbin/qsync --help". I assume this should fix the problem permanently.

Anyone have any idea what this problem is/was all about? I Googled a lot, and am still baffled as to why. Will my improvised fix keep the problem from happening again? Thanks!

(P.S. -- qsync seems to use the "-b" option of ntpdate, which forces use of step instead of adjust, whereas my manually-run ntpdate commands don't specify "-b". Not sure if that is relevant. Regardless, qsync should not have this "retry forever after success" bug to begin with.)
.

[Stogie]

.
Interesting. I have two boxes running this same version of Easy Buster.

On both, manually doing a time update via qsync, either on the command line (with the "--help" option which for some reason suppresses the GUI and just silently does the update) or via the GUI (ticking the box to turn it on, and getting the yellow "Syncing time, please wait" message for a few seconds), seems to have permanently solved the problem.

Box 1 I can reboot whenever I want, so I rebooted it a bunch of times after this, not running qsync manually again, and the issue remains gone/fixed. (This was before I added the startup script described above).

Box 2 I can't reboot right now, but the problem went away there, too, after I manually did an update with qsync just once. I then disabled and re-enabled qsync several times (best thing I can do without a reboot) and it still hasn't returned.

Very strange. And now I can't get it to happen again, so I can't experiment any more. If anyone has insights, please share, thanks!
.

[BarryK]

Yes, it is very frustrating when a problem won't repeat when you want it to.

[Stogie]

.
I just figured it out and verified/replicated it with some test code, for conclusive proof!

There's a subtle bug in /usr/bin/qsync and here it is:

Code: Select all

M1="$(gettext 'Syncing time, please wait...')"
[ $NOX -eq 0 ] && popup "terminate=never level=top background=#ffff80|<big><big>${M1}</big></big> "
# -s means log to syslog
ntpdate -s -b $zNEW_SERVER
[ $NOX -eq 0 ] && killall popup #180904

if [ $? -eq 0 ];then
 #set this to prevent re-sync in current session...
 touch /tmp/qsync/have-run
 hwclock --systohc --${HWCLOCKTIME} #ref: /etc/clock
fi

I'm pretty sure Barry meant for the line "if [ $? -eq 0 ];then" to look at the returncode of the ntpdate command that's run above, but in actuality it does not test that. Instead it tests the returncode of the line "[ $NOX -eq 0 ] && killall popup" because THAT is actually the prior command, not ntpdate.

Testing shows that when NOX is 0 (meaning the GUI mode is on), the "if" around the touch/hwclock ALWAYS succeeds, whether ntpdate succeeded or not, and when NOX is 1 (meaning the GUI mode is off), the "if" ALWAYS fails, again regardless of whether ntpdate succeeded or not.

This makes total sense, as the "if" is looking at the returncode of the NOX conditional, not the returncode of ntpdate.

This is why the ntpdate itself would succeed, but then network_tray would endlessly retry, calling qsync over and over! It's because in non-GUI mode, qsync NEVER does the "touch" command, thus NEVER creates the have-run file.

So there ya go! It's a bug to fix in future versions, if it's not been fixed already (the EasyOS I'm using is several years old).

I'm going to fix it on my machines by simply moving the line that does the NOX check and killall popup to AFTER the touch/hwclock if block, yielding this:

Code: Select all

M1="$(gettext 'Syncing time, please wait...')"
[ $NOX -eq 0 ] && popup "terminate=never level=top background=#ffff80|<big><big>${M1}</big></big> "
# -s means log to syslog
ntpdate -s -b $zNEW_SERVER

if [ $? -eq 0 ];then
 #set this to prevent re-sync in current session...
 touch /tmp/qsync/have-run
 hwclock --systohc --${HWCLOCKTIME} #ref: /etc/clock
fi
[ $NOX -eq 0 ] && killall popup #180904

I believe this should fix it permanently, because the test of the return value of the prior command ($?) now DOES refer to the ntpdate returncode, as was obviously originally intended.

Hope that helps!
.

[BarryK]

That was fixed in January 2021!

[Stogie]

That was fixed in January 2021!

LOL, guess I need to upgrade!

I love this Debian-based version though and its huge available list of software packages. Awhile back, I tried a newer Easy (OpenEmbedded-based, I think) and that was definitely not the case, a lot of software I use wasn't available. Maybe the latest versions have more software available. Time to grab a cheap USB stick and try it!

Anyway, Easy is a great product, even the old 2020 version I'm using! I work it hard on an ancient 2012 PC, yet I still routinely have > 100-day uptimes between reboots, which is remarkable! Thanks!
.