1748 replies to this topic

[Dimitrij]

WanWizard

Please re-add enigma2-plugin-systemplugins-systemtime in feed.

Enigma2 internet time does not work every time you turn it on from deep standby mode.

[littlesat]

What does not work? Better fix it! After the latest changes I cannot notify issues anymore related to the ntp service

Edited by littlesat, 25 July 2023 - 19:27.

[WanWizard]

Indeed, I would like to know what is not working, and why. And then fix it instead of work around it.

 

The system is configured to do an ntp update as soon as the network interface comes up.

 

Possible causes I know it could be

• the config is no longer standard but manually changed
• the connection is wireless and interface-ready is signaled ( via the /etc/network/if-up.d/ntpdate-sync symlink )

Having said that, all my boxes run the latest develop (I update virtually daily), and all are connected via wireless, and I never see any date issues, the box has the correct date before E2 starts tuning.

 

The only possible difference is may be that my firewall runs an NTP service, so the box doesn't have to deal with possible internet latency.

[Dimitrij]

Always start in iptv service.

LAN static network.

Correct time 50%

 

 

enigma2-plugin-systemplugins-systemtime -->"NTP cold start" work 100%

Edited by Dimitrij, 26 July 2023 - 05:27.

[WanWizard]

What enigma does is not relevant, it is completely handled at the network layer.

 

Do you have the /etc/network/if-up.d/ntpdate-sync symlink? Is it triggered when the network comes up, and what is the result (check dmesg or add some debugging to the script)?

 

Your plugin calls ntpdate too, the only difference is timing, or perhaps the IP of the NTP server used (see /etc/defaults/ntpdate).

 

If it sometimes works, sometimes not, I suggest you add a "sleep 1" at the top of the ntpdate-sync script, and see if that adresses the problem, as it suggests is may be fired when the interface is up but IP isn't yet (for example because of slow DHCP response).

[WanWizard]

If this is the case, it would be an idea to have it wait until the default gateway is reachable:

IP=echo $(/sbin/ip route | awk '/default/ { print $3 }')
until ping -c1 -W1 $IP >/dev/null 2>&1; do :; done

 

[littlesat]

it would be an idea to have it wait until the default gateway is reachable:

 

Maybe indeed... but when it cannot be reached at all then it stays in an endless loop....

Edited by littlesat, 26 July 2023 - 14:21.

[littlesat]

Your plugin calls ntpdate too, the only difference is timing, or perhaps the IP of the NTP server used (see /etc/defaults/ntpdate).

The plugin starts a moment later...during the startup from enigma2... which is from another perspective too late .... mmmmh.... 

[Huevos]

What enigma does is not relevant, it is completely handled at the network layer.

 

Do you have the /etc/network/if-up.d/ntpdate-sync symlink? Is it triggered when the network comes up, and what is the result (check dmesg or add some debugging to the script)?

 

Your plugin calls ntpdate too, the only difference is timing, or perhaps the IP of the NTP server used (see /etc/defaults/ntpdate).

 

If it sometimes works, sometimes not, I suggest you add a "sleep 1" at the top of the ntpdate-sync script, and see if that adresses the problem, as it suggests is may be fired when the interface is up but IP isn't yet (for example because of slow DHCP response).

 

ntpdate-sync has been removed in the latest bitbake so you are going to need to change that soon.

 

In ViX we just wrote a new script that uses /usr/sbin/ntpd.

https://github.com/o...nc/ntpdate-sync

https://github.com/o...ge/ntpd-sync.bb

Edited by Huevos, 26 July 2023 - 14:31.

[littlesat]

ntpdate-sync has been removed in the latest bitbake so you are going to need to change that soon.

 

In ViX we just wrote a new script that uses /usr/sbin/ntpd.

https://github.com/o...nc/ntpdate-sync

https://github.com/o...ge/ntpd-sync.bb

Again an example of forking here, made adaptions and improvements without any discussion and/or feedback and then afterwards when something popups here start to catch it up and initially try to invent the wheel again...

But unless this thanks for mentioning it.

[Huevos]

 

ntpdate-sync has been removed in the latest bitbake so you are going to need to change that soon.

 

In ViX we just wrote a new script that uses /usr/sbin/ntpd.

https://github.com/o...nc/ntpdate-sync

https://github.com/o...ge/ntpd-sync.bb

Again an example of forking here, made adaptions and improvements without any discussion and/or feedback and then afterwards when something popups here start to catch it up and initially try to invent the wheel again...

But unless this thanks for mentioning it.

 

Forking what exactly?

[WanWizard]

 ntpdate-sync has been removed in the latest bitbake so you are going to need to change that soon.d-sync.bb

 

Possible, but not relevant at the moment. Blindly replacing it would be the same workaround as installing the plugin: working around an issue without understanding the issue.

 

Maybe indeed... but when it cannot be reached at all then it stays in an endless loop....

 

If you have the interface come up, but IP not working, you have an issue of another magnitude

 

It could happen if you connect the box to a switch port which doesn't lead anywhere, but that would be a rather pointless excercise, assuming you plug an UTP cable in to actually send data across it...

[Huevos]

Blindly?

 

Replace is necessary. The only reason ntpdate-sync is still present in PLi is because you are using and old bitbake branch.

 

Our script tests that a connection to the public internet is available before trying to set the clock.

[Dimitrij]

 

The plugin starts a moment later...during the startup from enigma2... which is from another perspective too late .... mmmmh....

Not.

"NTP cold start"

This start script

update-rc.d ntpdate defaults 99

+

"Sync now with NTP server"

+

"Set system time manually"+

+

"Use RTC time from deep standby"+

+

"Sync now with current transponder"

+

and etc...

 

 

P.S.I don't understand what is wrong with this plugin?

Let the user decide.

The feed is full of various rubbish that has not been working for many years, and you deleted the necessary plugin.

Where is the logic...
 

[WanWizard]

I still haven't had confirmation from you about the source of the actual problem.

 

Stop inventing workarounds for issues you don't know the cause of, and instead debug the problem so it can be fixed for everyone.

 

Blindly?

 

Replace is necessary. The only reason ntpdate-sync is still present in PLi is because you are using and old bitbake branch..

 

Yes, because you also don't know what the root cause is, and therefore you don't know if replacing ntpdate-sync will fix this particular problem.

 

And it has nothing to do with bitbake, I assume you mean OpenEmbedded version?

 

Our script tests that a connection to the public internet is available before trying to set the clock.

 

My NTP server is internal, so not dependent on any public internet connection. My firewall also blocks port 123 (it has a default deny-all policy), so even if an internet NTP server was configured, it wouldn't work (even though you would be able to ping it).

 

But yes, in general a network check is a good idea. Whether that should be to "the public internet" is another matter.

Edited by WanWizard, 26 July 2023 - 17:40.

[littlesat]

I think the check you’re trying to do wanwizard should be sufficiant. Indeed a local ntp can be used and I have the same here… When something is not available in a future oe we can adapt that later.

Edited by littlesat, 26 July 2023 - 22:58.

[Beeker]

https://github.com/O...i-oe-core/pulls

[Beeker]

https://github.com/O...lugins/pull/954

[rantanplan]

done

[Beeker]

Thanks.