Vix 5.1.006. Time wrong

[Huevos]

Here is just one example of 2004 used in an important e2 file.

https://github.com/OpenViX/enigma2/blob/Dev/lib/dvb/dvbtime.cpp#L315-L319

 

[bbbuk]

I see @SpaceRat is making making changes to OE-A now regarding the time issues.

 

[SpaceRat]

They are just beautification.
The core issue was https://github.com/OpenViX/enigma2/commit/031108daae7639851e13e377dc0df6e5d431d7ae

That old quirk call to ntpdate simply rarely but still sometimes happened at the very same time as the call to ntpdate-sync on boot.
In that case, both instances of ntpdate got returned the same offset and both adjusted the time accordingly ... so the difference between 28.12. and "now" was applied twice, thus the time in the future.

The quirk in enigma2.sh is a double ugly workaround:
a.) # perform a NTP update sync, before starting Enigma2, as it is broke in OE.
If you know it's broken in yocto (OE), fix it there, rather than packing ugly workarounds on top!
I just did exactly that and now that the one-shot NTP in yocto works, the workaround kicked you into the ass ...
b.) Don't ever call ntpdate directly.
It doesn't check if another instance of ntpdate is already running ... ntpdate-sync however does

So
1. Bad workaround instead of a fix.
2. Call to a wrong binary which allows collisions.

Could easily be seen in /var/log/messages:

Dec 30 10:38:13 gbquad4k daemon.notice ntpdate[*1822*]: step time server 85.199.214.101 offset 202264.724341 sec
Jan  1 18:49:22 gbquad4k daemon.notice ntpdate[*1824*]: step time server 85.199.214.101 offset 202264.725832 sec

Two instances (different PIDs) of ntpdate running at the very same time, getting almost the very same offset to adjust -> double adjustment.

The first instance of ntpdate was adjusting by 2 days, 8 hours, 11 minutes and 4 seconds. from 2017-12-28 2:27 to 2017-12-30 10:38, the second one another 2 days, 8 hours, 11 minutes and 4 seconds to 2018-01-01 18:49 ...


The latest changes of mine just beautify the log output ...

Dec 30 15:30:07 duo2 daemon.notice ntpdate[13240]: adjust time server 192.168.75.1 offset -0.007456 sec
Dec 30 15:30:07 duo2 daemon.notice stb-hwclock: Current system time has been written into FP pseudo RTC.

... the second line previously polluted stdout, now it gets sent to syslog / /var/log/messages ...

... and they allow the box to learn NTP servers by DHCPv4 (E.g. the router).

In addition, the delay for ntpdate-sync on ifup was turned from a fixed delay by 5 sec to a loop that ends as soon as google.com can be pinged (or 5 turns through the loop), so the NTP sync should now happen a little bit earlier even.

 

[bbbuk]

Will these latest changes hopefully solve potential issue with likes of certs in OpenVPN that was mentioned in an earlier post of yours?

I ask only because using vix 5.1 007, OpenVPN said it had started but I couldn't get any channel on IPTV to work but when I had openVPN off the IPTV channels worked ok.

During half-time then, I quickly went back to 5.1 002 (before all these changes) with a restore of settings and IPTV now works with openVPN.

Or was this just all coincidental?

 

[SpaceRat]

Will these latest changes hopefully solve potential issue with likes of certs in OpenVPN that was mentioned in an earlier post of yours?

Yes.

It's meant to address errors like these:

Wed Oct 15 03:03:44 2014 TLS: Initial packet from [AF_INET6]2001:db8:4063:dead:beef:1fff:fe12:3456:53667, sid=b0b81bb4 36d599a0
Wed Oct 15 03:03:46 2014 VERIFY ERROR: depth=1, error=certificate is not yet valid: C=GDR, ST=SomeState, L=Somewhere, O=mocowolf, OU=CA Cert, CN=mocowolf CA, name=Root CA, [email protected]
Wed Oct 15 03:03:46 2014 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

root@quadbox ~ # mount -a
root@quadbox ~ # 2014/10/15 03:06:01 Failed to create file system for "ACD:": failed to get endpoints: Get https://drive.amazonaws.com/drive/v1/account/endpoint: x509: certificate has expired or is not yet valid

The same applies for davfs2 (For WebDAV, which is HTTPS) or if you just want to wget/curl something during from https during boot (e.g. in rc.local or some E2 startup script).

 

[birdman]

It's meant to address errors like these:

But all that seems to have happened is that you've replaced one set of problems, which have always been there, with a different set of problems, which have never been problems before.

 

[abu baniaz]

@Birdman, I believe the latest changes have fixed the knock-on effects that were caused.

Edit:
This should be available in 5.1 009

 

[birdman]

It's meant to address errors like these:

But it won't.

The ntpdate-sync script (which is ntpdate under ntpd in meta-openembedded) is firing off ntpdate in the background, which means the rest of the boot process (including starting enigma2) goes on before the time is set. The ntpdate call must be done in the foreground to ensure that it has completed before the rest of the boot process continues.
If anything else wishes to background this then it can just background the call to the script.

Also, the check_online()function in the script is pinging www.google.com. That means it has to resolve www.google.com (meaning it has network access) before it can do the ping, which rather means the ping is pointless.
I'd suggest using the IP address of Googles nameservers instead (8.8.8.8 and 2001:4860:4860::8888).

 

[SpaceRat]

Also, the check_online()function in the script is pinging www.google.com. That means it has to resolve www.google.com (meaning it has network access) before it can do the ping, which rather means the ping is pointless.
I'd suggest using the IP address of Googles nameservers instead (8.8.8.8 and 2001:4860:4860::8888).

No, vice versa:

As the time servers are usually also specified as an URL (pool.ntp.org), name resolution has to work too for it to work.
udhcpc-Scripts set the routing first, then DNS, so there is a tiny moment at which the interface is already up (IPs are routable) but names can not be resolved yet.

 

[birdman]

As the time servers are usually also specified as an URL (pool.ntp.org), name resolution has to work too for it to work.
udhcpc-Scripts set the routing first, then DNS, so there is a tiny moment at which the interface is already up (IPs are routable) but names can not be resolved yet.

OK, but if name resolution is failing because the network isn't up isn't there a possibility that the loop over 5 attempts will actually get run very quickly (since ping won't be running with its 4s timeout)?

 

[SpaceRat]

Try it, you are free to increase the count for the loop.
I tested with bad URL, but not with resolution not working at all so you might be right.
As the sync is backgrounded, higher values at least shouldn't slow down boot.

Gesendet von meinem SM-N910F mit Tapatalk

 

[adm]

OK, but if name resolution is failing because the network isn't up isn't there a possibility that the loop over 5 attempts will actually get run very quickly (since ping won't be running with its 4s timeout)?

Out of interest. What happens if the box isn't networked at all and is just being used as a stand alone broadcast receiver/PVR?

 

[birdman]

As the sync is backgrounded, higher values at least shouldn't slow down boot.

You don't seem to be following the actual bug issue.
The time sync at boot must not be done in the background!

 

[birdman]

Out of interest. What happens if the box isn't networked at all and is just being used as a stand alone broadcast receiver/PVR?

Then you would be using the time from the transponders (in enigma2) and, since there is no network interface to bring up then there will be no ntpdate-sync run at boot time.

 

[Joe_90]

You don't seem to be following the actual bug issue.
The time sync at boot must not be done in the background!

I tried your change to ntpdate-sync to foreground the ntpdate check, but it didn't seem to make any difference (but maybe I did it wrong). I decided to join this thread as SpaceRat has responded to my PM. I found that if I changed from NTP sync to Transponder sync and rebooted (after complete power down to clear all capacitors etc.) then the box came up initially with the fake-hwclock.data time, but then corrected to the transponder time. When I changed back to NTP sync and rebooted after complete power down, then the box was stuck on fake-hwclock.data time.

 

[birdman]

When I changed back to NTP sync and rebooted after complete power down, then the box was stuck on fake-hwclock.data time.

So your box either syncs twice or never? I can't, at the moment, see how that can happen. But if it is then there must be a way...

 

[birdman]

You don't seem to be following the actual bug issue.
The time sync at boot must not be done in the background!

I now have an ntpdate-sync script which runs ntpdate in the background when called from enigma2, but in the foreground if called when an interface is brought up (i.e. METHOD is set).
The former is needed to ensure that the time is set before services start (the whole point of the original change) and the latter is needed as enigma2 runs it using Console.ePopen(), and the Vix spinner pops up if that doesn't complete in <5s(?), which it usually won't.

This is it:
View attachment ntpdate-sync.zip

 

[Joe_90]

I'm stumped. I've changed so many different things my mind is going................
Definitely the double sync which is stepping the time into the future is an issue, but I don't know what is causing that as enigma2.sh has the call to ntpdate commented out, so it should be just ntpdate-sync which is being run and it has supposedly a check to ensure that ntpdate is not run twice.
Also, the fact that fake-hwclock.data does not get updated once it has a value into the future is another issue.

 

[Joe_90]

I now have an ntpdate-sync script which runs ntpdate in the background when called from enigma2, but in the foreground if called when an interface is brought up (i.e. METHOD is set).
The former is needed to ensure that the time is set before services start (the whole point of the original change) and the latter is needed as enigma2 runs it using Console.ePopen(), and the Vix spinner pops up if that doesn't complete in <5s(?), which it usually won't.

This is it:
View attachment 55805

Thanks @birdman - I'll give it a shot on my machine. Off to bed now

 

[birdman]

Iso it should be just ntpdate-sync which is being run and it has supposedly a check to ensure that ntpdate is not run twice.

No. It has a check to ensure it isn't being run twice at the same time, but that is only done if the /usr/bin/lockfile-create exists, which it doesn't by default on OpenVix.

Also, the fact that fake-hwclock.data does not get updated once it has a value into the future is another issue.

That's a deliberate design feature, although I forget why.
It's configurable by uncomment the line in /etc/default/fake-hwclock.

The real issue here is how it ever gets a future time set.