118 replies to this topic

[WanWizard]

Wat ik vreemd blijf vinden is dit:

Sep 23 20:30:00 vu+ cron.info crond[1424]: USER root pid 24926 cmd /usr/bin/ntpdate-sync silent
Sep 23 20:30:06 vu+ daemon.notice ntpdate[24935]: adjust time server 95.211.123.72 offset +0.018215 sec
Sep 23 21:30:00 vu+ cron.info crond[1424]: USER root pid 25619 cmd /usr/bin/ntpdate-sync silent
Sep 23 21:30:06 vu+ daemon.notice ntpdate[25628]: adjust time server 94.198.159.15 offset +0.025232 sec
Sep 23 22:30:00 vu+ cron.info crond[1424]: USER root pid 25907 cmd /usr/bin/ntpdate-sync silent
Sep 23 22:32:28 vu+ daemon.notice ntpdate[25916]: step time server 94.198.159.11 offset +140.023070 sec
Sep 23 23:30:00 vu+ cron.info crond[1424]: USER root pid 26721 cmd /usr/bin/ntpdate-sync silent
Sep 23 23:30:06 vu+ daemon.notice ntpdate[26730]: adjust time server 94.198.159.11 offset +0.032971 sec
Sep 24 00:30:00 vu+ cron.info crond[1424]: USER root pid 27379 cmd /usr/bin/ntpdate-sync silent
Sep 24 00:30:06 vu+ daemon.notice ntpdate[27388]: adjust time server 45.138.55.60 offset +0.018040 sec
Sep 24 01:30:00 vu+ cron.info crond[1424]: USER root pid 27658 cmd /usr/bin/ntpdate-sync silent
Sep 24 01:32:26 vu+ daemon.notice ntpdate[27667]: step time server 185.224.145.68 offset +140.026549 sec
Sep 24 02:30:00 vu+ cron.info crond[1424]: USER root pid 27684 cmd /usr/bin/ntpdate-sync silent

De tijd loopt keirig op tijd, en dan ineens is er 140 seconden verschil. En ook elke keer 140 seconden.

 

Wat mogelijk ook nog de oorzaak kan zijn: die "internet time" is beroerd geimplementeerd in 9.0-release, in niet alle gevallen gaat transponder time uit. En dat zou wel eens de oorzaak kunnen zijn van het verspringen van de tijd, en naar een tijd met altijd dezelfde delta.

 

Als dat zo is, dan is het wellicht verstandig om eens te wisselen naar een nighly build / develop image, want daar is die bug in gefixt.

 

Dat kan eenvoudig, via de flash image optie in het menu, en dan kiezen voor flashen met een backup (zorg voor lokale opslag via USB als je geen harde schijf hebt), en 5 minuten later ben je weer in de lucht.
 

[Rammy]

Ik zie in de eerste posting dat je development OpenPLi-9.0 hebt geïnstalleerd, die bestaat niet :-)

 

Hoe decodeer jij de beelden of kijk je alleen FTA kanalen? Als je een kaart zonder een CI in de ontvanger gebruikt, moet je oooit iets hebben geïnstalleerd, anders kan je geen beeld krijgen.

 

 

NTPD staat niet in de feeds van OpenPLi-9.0, als je een losse ipk kunt krijgen kan je die middels opkg installeren of op een stick zetten en die in de box steken, dan krijg je vanzelf een pop-up met de vraag of je iets wilt installeren.

 

Ik heb op dit moment de OpenPLi 9 Devellopment versie in gebruik nogmaals voor de duidelijkheid.

Ik kijk alleen FTA kanalen.

Waar kan ik die losse ipk voor ntpd vinden?

Op het systeem is reeds ntpddate-sync ge-installeerd is dit niet voldoende?

Wat voegt ntpd nog extra toe?

[Rammy]

Wat ik vreemd blijf vinden is dit:

Sep 23 20:30:00 vu+ cron.info crond[1424]: USER root pid 24926 cmd /usr/bin/ntpdate-sync silent
Sep 23 20:30:06 vu+ daemon.notice ntpdate[24935]: adjust time server 95.211.123.72 offset +0.018215 sec
Sep 23 21:30:00 vu+ cron.info crond[1424]: USER root pid 25619 cmd /usr/bin/ntpdate-sync silent
Sep 23 21:30:06 vu+ daemon.notice ntpdate[25628]: adjust time server 94.198.159.15 offset +0.025232 sec
Sep 23 22:30:00 vu+ cron.info crond[1424]: USER root pid 25907 cmd /usr/bin/ntpdate-sync silent
Sep 23 22:32:28 vu+ daemon.notice ntpdate[25916]: step time server 94.198.159.11 offset +140.023070 sec
Sep 23 23:30:00 vu+ cron.info crond[1424]: USER root pid 26721 cmd /usr/bin/ntpdate-sync silent
Sep 23 23:30:06 vu+ daemon.notice ntpdate[26730]: adjust time server 94.198.159.11 offset +0.032971 sec
Sep 24 00:30:00 vu+ cron.info crond[1424]: USER root pid 27379 cmd /usr/bin/ntpdate-sync silent
Sep 24 00:30:06 vu+ daemon.notice ntpdate[27388]: adjust time server 45.138.55.60 offset +0.018040 sec
Sep 24 01:30:00 vu+ cron.info crond[1424]: USER root pid 27658 cmd /usr/bin/ntpdate-sync silent
Sep 24 01:32:26 vu+ daemon.notice ntpdate[27667]: step time server 185.224.145.68 offset +140.026549 sec
Sep 24 02:30:00 vu+ cron.info crond[1424]: USER root pid 27684 cmd /usr/bin/ntpdate-sync silent

De tijd loopt keirig op tijd, en dan ineens is er 140 seconden verschil. En ook elke keer 140 seconden.

 

Wat mogelijk ook nog de oorzaak kan zijn: die "internet time" is beroerd geimplementeerd in 9.0-release, in niet alle gevallen gaat transponder time uit. En dat zou wel eens de oorzaak kunnen zijn van het verspringen van de tijd, en naar een tijd met altijd dezelfde delta.

 

Als dat zo is, dan is het wellicht verstandig om eens te wisselen naar een nighly build / develop image, want daar is die bug in gefixt.

 

Dat kan eenvoudig, via de flash image optie in het menu, en dan kiezen voor flashen met een backup (zorg voor lokale opslag via USB als je geen harde schijf hebt), en 5 minuten later ben je weer in de lucht.
 

Als ik dit doe moet ik dan vooraf mijn timer database, ssh inlog key, Enigma settings en mijn eigen bouquet in veiligheid brengen en deze dan naderhand weer terugleggen?

[WanWizard]

Een STB heeft geen hardware clock, bij het opstarten wordt door het OS een software clock opgezet, en die "tikt" op basis van een hardware kristal, die wel of niet erg accuraat is.

 

ntpdate-sync synchoniseert die klik, eenmalig, elke keer als deze loopt. Als je dus een software clock hebt die niet correct loopt, dan krijg je een soort van zaagtand grafiek, een clock die steeds verder uit de pas loopt, en op intervallen weer terug correct gezet wordt.

 

ntpd werkt anders, die heeft intern zelf een software clock die veel accurater is in het tegengaan van klok drift. Ook die syncroniseert zichzelf met een externe klok, maar het interval daarvan wordt automatisch bijgewerkt aan de hand van de drift. De grafiek van ntpd is dus veel vlakker.

 

MAAR... (en dat is een hele grote maar),

 

Dat is niet het probleem wat jij hebt, en dus gaat het ook niet de oplossing zijn.

 

De OS klok van jou box loopt prima, een drift van 0.01s per uur is zeer acceptabel. Het probleem wat jij hebt is dat er af en toe iets is wat de klok 140 seconden verzet. De vraag is dus wat dat doet, als het geen transpondertijd is.

[WanWizard]

Als ik dit doe moet ik dan vooraf mijn timer database, ssh inlog key, Enigma settings en mijn eigen bouquet in veiligheid brengen en deze dan naderhand weer terugleggen?

 

Als je al een develop image draait, heeft dit geen toegevoegde waarde.

 

En als je flasht met backup, dan gaan al die dingen de backup in. Als de box daarna na de flash herstart en die backup vind, zal deze weer automatisch worden teruggezet, en kun je direct verder. Ik gebruik dit mechanisme meedere malen per dag, ik hoef zelden nog een box in te richten.
 

[WanWizard]

De OS klok van jou box loopt prima, een drift van 0.01s per uur is zeer acceptabel. Het probleem wat jij hebt is dat er af en toe iets is wat de klok 140 seconden verzet. De vraag is dus wat dat doet, als het geen transpondertijd is.

 

Misschien moeten we eens een logging op je box zetten, bv eens per minuut, zodat we precies kunnen zien wanneer de tijd exact verspringt. En dan kun je hopelijk achterhalen wat je op dat moment aan het doen was.

[Rammy]

 

De OS klok van jou box loopt prima, een drift van 0.01s per uur is zeer acceptabel. Het probleem wat jij hebt is dat er af en toe iets is wat de klok 140 seconden verzet. De vraag is dus wat dat doet, als het geen transpondertijd is.

 

Misschien moeten we eens een logging op je box zetten, bv eens per minuut, zodat we precies kunnen zien wanneer de tijd exact verspringt. En dan kun je hopelijk achterhalen wat je op dat moment aan het doen was.

 

Dat is een goed idee. Wat moet ik hiervoor doen.
 

[WanWizard]

Inloggen, en dan op de commandline:

crontab -e

daarna de op "i" drukken voor insert mode, naar deze regel gaan

30       * * * *    /usr/bin/ntpdate-sync silent

en die veranderen naar

*        * * * *    /usr/bin/ntpdate-sync silent

daarna op Esc drukken, en twee maal op "Z" (hoofdletter !).

 

Nu doet hij elke minuut een ntp sync. Je kunt dan met

grep ntpdate /var/log/messages

precies zien op welk moment hij ineens het gat van 140s gaat dichten, of het daarna weer terug komt (volgende minuut weer 140s), en zo ja, hoelang dat duurt.
 

En dan kijken of je tijdstippen (dat het dus van 0 naar 140s springt) kunt correleren aan een actie van jou, bv een zap naar een specifieke zender?

[Rammy]

Ik heb de aanpassing doorgevoerd. Tot nu loopt de klok met een afwijking van -0.000216 tot +0.002477 minuut.

Edited by Rammy, 10 October 2024 - 18:42.

[Tech]

Ik heb op dit moment de OpenPLi 9 Devellopment versie in gebruik nogmaals voor de duidelijkheid.

 

En die bestaat NIET. Er is geen OpenPLi-9.0 development, alleen een release!

[Rammy]

 

Ik heb op dit moment de OpenPLi 9 Devellopment versie in gebruik nogmaals voor de duidelijkheid.

 

En die bestaat NIET. Er is geen OpenPLi-9.0 development, alleen een release!

 

O.k. dan, maar ik gebruik de OpenPLi develop (2024-07-23 (Develop))

[Rammy]

Hoe lang blijft de dmesg file bestaan?

Normaal bljft deze toch bestaan tot een volgende reboot?

Het systeem heeft nu reeds 2 maal op 1 dag de file verwijderd en is met een lege file opnieuw begonnen.

Edited by Rammy, 11 October 2024 - 14:27.

[Frenske]

@Rammy,

 

Als jij een develop image gebruikt en deze is verre van up to date, dan heeft dat niet heel veel zin omdat destijds actieve issues mogelijk al lang gefixt zouden kunnen zijn. Dus geregeld updaten is mijn advies.

[WanWizard]

Hoe lang blijft de dmesg file bestaan?

Normaal bljft deze toch bestaan tot een volgende reboot?

Het systeem heeft nu reeds 2 maal op 1 dag de file verwijderd en is met een lege file opnieuw begonnen.

 

dmesg is een circulaire buffer van vaste grootte. Eens vol valt de oudste regel er uit als er een nieuwe bij komt.

 

Hij wordt nooit gewist, tenzij door een herstart van de box (want het is geen bestand, het is een buffer in het geheugen), of door een specifiek commando.

[Rammy]

@Rammy,

 

Als jij een develop image gebruikt en deze is verre van up to date, dan heeft dat niet heel veel zin omdat destijds actieve issues mogelijk al lang gefixt zouden kunnen zijn. Dus geregeld updaten is mijn advies.

Dit probleem speelt bij al vanaf 2024-02. Als oplossing werd voorgesteld om te kijken of een development versie de oplossing zou kunnen bieden. Dit heb ik geprobeerd met uit eindelijk nog meer problemen en dit probleem speelt nog altijd. Natuurlijk zou het probleem reeds op opgelost KUNNEN zijn. Maar dat geloof ik niet. Maar ik zal om jouw te plezieren de versie updaten naar de nieuwste development versie. Indien dit probleem zou zijn opgelost dan zou dat ook bij jullie bekend moeten zijn!

 

Het systeem draait nu op de OpenPLi develop (2024-10-08 (Develop)), de allerlaatste versie dus.

Ik laat me verrassen!

[Rammy]

 

Hoe lang blijft de dmesg file bestaan?

Normaal bljft deze toch bestaan tot een volgende reboot?

Het systeem heeft nu reeds 2 maal op 1 dag de file verwijderd en is met een lege file opnieuw begonnen.

 

dmesg is een circulaire buffer van vaste grootte. Eens vol valt de oudste regel er uit als er een nieuwe bij komt.

 

Hij wordt nooit gewist, tenzij door een herstart van de box (want het is geen bestand, het is een buffer in het geheugen), of door een specifiek commando.

 

Wat zou hier de oorzaak van kunnen zijn?

Hoe groot is deze buffer?

Kunnen we een logging opzetten welke kan aangeven welke software wanneer de systeemklok ge-updated heeft.

Met 'ntpdate-sync' kom ik niet verder.

Edited by Rammy, 11 October 2024 - 17:43.

[WanWizard]

Het uitzetten van de box? Aannemende dat je hem niet met de hand hebt gewist.

 

ntpdate logt in /var/log/messages. Maar ook die is weg als je de box uit zet.

 

Je kunt ntpdate laten loggen naar een ander bestand, door de cron job aan te passen naar:

*        * * * *    /usr/bin/ntpdate-sync >> /home/root/ntpdate.log 2>&1

let wel op dat je dit niet weken lang doet, als je flash vol loopt heb je een groter probleem.
 

[Rammy]

Ik zou niet weten hoe ik deze buffer handmatig zou kunnen wissen.

 

Die methode had ik ook bedacht maar helaas indien ik

> /home/root/ntpdate.log 2>&1

toevoeg aan het crontab commando, dan werkt het niet meer.

Dus heb ik onderstaande regel in crontab toegevoegd,

cat /var/log/messages >"dmesg_$( date +%Y%m%d )"

Hierna laat ik mijn laptop de gemaakte copy van dmesg ophalen van de box en bewaren op mijn laptop.

Zodoende kan ik onnodige regels verwijderen om een beter overzicht van het gebeuren te verkrijgen.

Ik kan zien dat er af heel af en toe een terugval in de systeem tijd plaats vind terwijl de box in standby staat.

Dit word dan na 1 muinuut gecorrigeerd door 'ntpdat-sync'.

Verder kan ik zien dat indien de verbinding met het internet verbroken word er vrij vlug een terugval in systeemtijd plaats vind.

Ik zou moeten kunnen achterhalen wie toegang vraagt tot de systeemklok om de veroorzaker te vinden.

[WanWizard]

Eh, je kunt niet zomaar willekeurige regels aan een crontab toevoegen?

 

De tijd kan slechts op 3 manieren worden gezet:

• via ntp
• via enigma, dmv transponder tijd
• via de commandline, het date commando

 

Punt 1 werkt niet als je netwerk uit staat, punt 2 kan niet gebeuren niet in standby, tenzij er een opname loopt.

 

Staat die box open naar het internet?

 

Ik begin langzaam te denken dat iemand extern een stream op vraagt van een transponder die de verkeerde tijd heeft. Als de box internet bereikbaar is, dan kun je wachten op een hack...

 

Maar dat kan dan weer niet als het ook gebeurt als je het internet stop zet.

 

Het moet toch iets zijn, het is geen probleem met de klok zelf, de stap is elke keer van 0s naar 140s, zonder dat er verder sprake is van drift (een te snel of te langzaam lopende klok).

[WanWizard]

Die methode had ik ook bedacht maar helaas indien ik

> /home/root/ntpdate.log 2>&1

toevoeg aan het crontab commando, dan werkt het niet meer.

 

Geen idee wat voor raars je gedaan hebt, maar als ik

 

*        * * * *    /usr/bin/ntpdate-sync >> /home/root/ntpdate.log 2>&1

 

in mijn crontab zet dan werkt het prima.