Move ntpdate-sync from if-up.d to init.d script and refactor ntpdate-sync.

[original-birdman]

No description provided.

[original-birdman]

NOTE: This PR will require someone to "also update the submodule"!

[TwolDE2]

While this is an all encompassing solution, the current requirements just need the ntpdate-sync linked to /etc/rc3.d as before and as there is only call without the locking.
Can you do that?

[original-birdman]

No.
Entries used by init.d should handle start and stop parameters and the lock code is needed to stop it running twice at the same time (and it is extremely light code).

[TwolDE2]

Why would it run twice at the same time?

[TwolDE2]

I haven't the time to mess around and I want the ntpdate-sync script updated, so will commit and look to simplify later.

[original-birdman]

Why would it run twice at the same time?

It did in the past, which is why the lock was put in.

look to simplify later.

I reckon it's as simple as it can be whilst being "correct".

[Papi2000-new]

What i don't understand is the fact, why is the "ntpdate-sync" still in the system? In former times, the binary file has been stored as /usr/bin/ntpdate-sync. It was triggered by a symlink in \etc\network\if-up.d\ named ntpdate-sync, pointing to the binary /usr/bin/ntpdate-sync.
Some guys injected another call into the /cron/crontabs/root (restored old settings in newer images after flashing) to get a cyclic resync of the system-time every hour or similar. That might be the second running task.
So what shall now be moved whereto for what reason? ntpdate-sync seems obsolete, and is not longer in the oATV images.
In actual oATV images the new timesync is done by the command:
"ntpd -nq -p pool.ntp.org"

[original-birdman]

ntpdate-sync has been a shell script for some time.

When it was a symlink from /etc/network/if-up.d it had to be a script, as otherwise the command would have been given no parameters and so wouldn't know which system to sync from.

In actual oATV images the new timesync is done by the command:
ntpd -nq -p pool.ntp.org

Which doesn't allow you to configure your own NTP servers.

ntpdate-sync seems obsolete

But it is not. It is one script (and hence one place) that encapsulates how the system should synchronize time using NTP. So if that ever needs to change there is only one place that needs to be changed.

The Vix Components/Networktime.py should also be calling ntpdate-sync - not ntpd directly. I intend to submit a PR for that.

[Papi2000-new]

Of course, "ntpdate-sync" is a script (and therefore also a binary, even if not compiled). The default datas for it could be found in /etc/default/ntpdate (now also obsolete).
And the example for the todays command was only for a test on the console, to check the working of timesync, how it is performed by chrony in the image. Fact is, you look at old structures, and the double-running task points to a general failure. What image is your wish related to, that it follows still theses old structures? What is it needed in it for?

[original-birdman]

Of course, "ntpdate-sync" is a script (and therefore also a binary, even if not compiled).

No, it's a script. The binary is /bin/sh.

What image is your wish related to, that it follows still theses old structures?

We cannot know what anyone will do in the future.
At one point the ntp code included an ntpdate binary - which we used. Then that was removed and ntpd -q replaced it.
Having only one place where the ntp time setting is done means there is only ever one place that needs to be fixe/modified/checked. Modularity.

[TwolDE2]

@Papi200-new
The issue here is that users set timers to perform various actions and then drop into deep standby for instance, and if the clock is not set correctly prior to Enigma start there are problems.
The ntpd -nq -p call in NetworkTime.py is standard in most images (and will not be changed).