47 replies to this topic

[Cor1950]

Vaak als ik flash via : instellingen ; image flashen crasht enigma , zie bijlage. Dat gebeurt voor het maken van de backup . Na de herstart van enigma gaat het wel altijd goed , na de herstart heb ik nog nooit een crash gehad bij het flashen. Betreft vuduo4kse onder 8.3 , maar is geen 8.3 issue , had ik ook al in 8.2 en eerder last van.

Attached Files

•  enigma2_crash_1667212264.log   61.03KB   9 downloads

[WanWizard]

Er staat een mount in je backup die (niet meer) deugt:

OSError: [Errno 112] Host is down: '/media/net/usb@VUUNO4K'

mijn gokje: het is een CIFS mount, en je hebt deze anonymous gemaakt (zonder gebruikersnaam/wachtwoord). Dat is inmiddels verplicht. Of het is een box die uit staat.

 

FlashImage zoekt ruimte om tijdelijke bestanden op te slaan, en loopt tegen deze niet reageerde mount aan.

[littlesat]

Helemaal mee eens...

 

ADD Peer vuuno4k=vuuno4k.local:8001
ADD Peer vuuno4k=vuuno4k.local:8001
REMOVE Peer vuuno4k
REMOVE Peer vuuno4k
[eDVBPESReader] ERROR reading PES (fd=60): Value too large for defined data type
Traceback (most recent call last):
  File "/usr/lib/enigma2/python/StartEnigma.py", line 223, in processDelay
    callback(*retval)
  File "/usr/lib/enigma2/python/Screens/FlashImage.py", line 279, in checkMedia
    self.destination, isDevice = findmedia(os.path.isfile(self.BACKUP_SCRIPT) and config.plugins.autobackup.where.value or "/media/hdd")
  File "/usr/lib/enigma2/python/Screens/FlashImage.py", line 271, in findmedia
    if checkIfDevice(path, diskstats):
  File "/usr/lib/enigma2/python/Screens/FlashImage.py", line 262, in checkIfDevice
    st_dev = os.stat(path).st_dev
OSError: [Errno 112] Host is down: '/media/net/usb@VUUNO4K'
[ePyObject] (CallObject(<bound method Session.processDelay of <__main__.Session instance at 0xb449e1c0>>,()) failed)

[littlesat]

Misschien kunnen we wel overwegen dit 'crash-proof' te maken met een try/except constructie er omheen...

Edited by littlesat, 1 November 2022 - 13:21.

[Cor1950]

Ok bedankt. het is een cifs mount met gebruikersnaam/wachtwoord , maar die box staat tijdens het flashen inderdaad meestal uit . Zal hem de volgende keer eens aanzetten.

[HFX]

Dus als je een andere sat ontvanger in je netwerk hebt gemount, en je zet die dan uit dan crasht je ontvanger als je die via je pvr toets selecteerd, ook ik merk dit dan blijft het tandwieltje draaien en moet de de stroom er even afgooien anders start die niet meer op.   Bij oudere images van openpli had je hier nooit last van.  

[luisteraar]

Dit klingt na een missing try except afvang mechanisme in enigma2

[WanWizard]

Dat merkte Littlesat ook al op.

 

Dus als je een andere sat ontvanger in je netwerk hebt gemount, en je zet die dan uit dan crasht je ontvanger als je die via je pvr toets selecteerd, ook ik merk dit dan blijft het tandwieltje draaien en moet de de stroom er even afgooien anders start die niet meer op.   Bij oudere images van openpli had je hier nooit last van.  

 

Als het een CIFS mount is niet, dan krijg je bovenstaande. Als het een NFS mount is wel, dat is een kernel mount die wacht op een timeout, NFS is niet ontworpen voor servers die je zo maar uit zet. Dan moet je iets als autofs gebruiken.

[HFX]

Zou misschien wel mooi zijn om software matig iets te maken zodat je sat ontvanger niet meer kan vastlopen op een draaiend tandwiel, dat had je vroeger ook op met windowsxp en nu met windows 11 niet meer een soort control alt delite toets op je afstandsbediening

[luisteraar]

Bijna ieder programmeer taal kent try except catch routines ook python.

Bij functies die mis kunnen lopen kan je acties nemen om hangen te voorkomen.

Bv kan geen netwerk verbinding maken dan die netwerk verbinding overslaan.

De deskundigen hier kunnen dat wel oplossen.

[WanWizard]

Niet alles is op die manier op te lossen. Een NFS connectie bv hangt op een I/O wait in de kernel, daar kan python helemaal niks mee, totdat de kernel met een timeout terug komt.

 

Autofs lost dit probleem overigens ook niet op, maar werkt er om heen door een mount automatisch te verwijderen na het verlopen van een idle timer.

[luisteraar]

Je moet natuurlijk de try except op de juiste plaats zetten ,bij de functie oproep die

niet terug komt en dat kan je dan afvangen.

Inderdaad bij netwerken is dat lastiger try zetten daar waar je de data wilt verzenden.

Kan zijn dat python dat niet goed doet die zit verder van de bron.

[WanWizard]

Denk dat je me niet begrijpt.

 

De applicatie doet I/O (open, read, write), dat roept via de file API de kernel driver aan, en die retourneert niet. Het hele process gaat in I/O-WAIT. Er valt dus niks te try/excepten.

[luisteraar]

<..>

try:

  open(xxxxxx)

except:

  meld dat stream niet te openen is

  en meld het de user

 

<..>

try:

  read(fd)

except:

  meld dat geen data binnen komt

  en meld het de user

<..>

try:

  write(fd)

except:

  meld dat geen data verzonden kon worden

  en meld het de user

<..>

try:

  close(fd)

except:

  meld dat niet goed afgesloten kon worden

  en meld het de user

<..>

[WanWizard]

En dat werkt dus niet, want zowel open() als read() ald write() retoureren niet, laat staat dan ze een exception kunnen triggeren. Die blijven in de kernel hangen: python open() -> c open() -> linux API -> nfs driver -> hangen in I/O WAIT.

 

Was ik daar nu niet duidelijk genoeg in?

[luisteraar]

Ok jammer dan dat python dat niet goed verwerkt.

Bij de c compiler gaat dat wel goed heb server software geschreven waar vaker

netwerk ergens niet ging en heb het zo altijd kunnen opvangen met het gestuntel in

patch kasten.

Heeft weinig met linux api te doen het loopt over tcp socket in kernel en die

meldt altijd.

 

Python is niet mijn ding dus open geeft in python geen FileDiscriptor terug ?

-1 mis gelopen positieve waarde socket is open.

Edited by luisteraar, 1 November 2022 - 19:35.

[WanWizard]

Nogmaals, het is specifiek aan NFS.

 

Ja, de socket meldt 't keurig. Maar de NFS driver blijft gewoon wachten tot de server weer terug komt, dat is inherent aan het design van NFS. Servers mogen gewoon nooit plat gaan.

 

Vroeger kon je nog wat sleutelen met "intr, soft" op de mount, maar dat werkt niet echt meer.

[luisteraar]

OK dat is een ander verhaal nfs werkt niet met open read write close op de socket 

zoals gemeld.

nfs kent wel automount als server down is wordt nfs automatisch umounted

heb ik vernomen.

[scriptmelvin †]

Je zou nog "bg" op de mount kunnen proberen, dan gaat mount in de achtergrond (en blijft het bijna een week (!) proberen).

[WanWizard]

Op de mount zelf zou dat kunnen, het probleem hier is een bestaande mount, waarbij de server is uitgezet zonder een deugdelijke umount te doen.
 

OK dat is een ander verhaal nfs werkt niet met open read write close op de socket 
zoals gemeld.

 

niet als je file I/O bedoelt, het is tenslotte een networked filesystem .

 

nfs kent wel automount als server down is wordt nfs automatisch umounted

heb ik vernomen.

 

Ik ben reuze beniewd wat je dan precies vernomen hebt,