43 replies to this topic

[WanWizard]

Hier ook DSM en NFS mounts, maar ik heb dit dus echt nog nooit gezien. lsof laat ook geen open files zien in /media. Voorlopig snap ik er niks van.

[WanWizard]

Wat ik me nu realiseer, nog eens naar deze code kijkend:
 

if time.time() - st.st_mtime < 5:
	if not args:
		self.session.openWithCallback(self.delete, MessageBox, _("File appears to be busy.\n") + are_you_sure)
		return

 

Dit gaat vreselijk fout als de tijd op de NAS substantieel afwijkt van de tijd op de box, vooral als de NAS voor loopt.

 

Dus, als je de melding krijgt tot (bv) twee uur na de opname, dan kan het dus heel goed dat er een 2 uur tijdverschil is tussen box en NAS.

 

Mijn firewall is NTP source voor alle toestellen in mijn netwerk, dus lopen ze allemaal op tijd en gelijk.

[40H3X]

Wat ik van TS niet begrijp is ;"2 weken geleden na een korte stroomuitval in de buurt en het daarop volgende IP-conflict de NAS een ander IP-adres gegeven", waarom leidt een stroomuitval tot een ip conflict? Dat is al heel vreemd, statisch IP-adres voor een netwerkapparaat hebt gedefinieerd, is juist  de oorzaak  dat er dubbel-IP-adres-conflicten optreden in een DHCP-netwerk. Als je een statisch adres wil uitdelen, moet dat altijd buiten de DHCP range zijn.

[littlesat]

Goede ontdekking... 

Dit gaat vreselijk fout als de tijd op de NAS substantieel afwijkt van de tijd op de box, vooral als de NAS voor loopt.

 

Dus, als je de melding krijgt tot (bv) twee uur na de opname, dan kan het dus heel goed dat er een 2 uur tijdverschil is tussen box en NAS.

 

Mijn firewall is NTP source voor alle toestellen in mijn netwerk, dus lopen ze allemaal op tijd en gelijk.

[WanWizard]

Wat ik van TS niet begrijp is ;"2 weken geleden na een korte stroomuitval in de buurt en het daarop volgende IP-conflict de NAS een ander IP-adres gegeven", waarom leidt een stroomuitval tot een ip conflict? Dat is al heel vreemd, statisch IP-adres voor een netwerkapparaat hebt gedefinieerd, is juist  de oorzaak  dat er dubbel-IP-adres-conflicten optreden in een DHCP-netwerk. Als je een statisch adres wil uitdelen, moet dat altijd buiten de DHCP range zijn.

 

Vette kans dat bij een reboot van de router deze zijn dhcp leases kwijt is, goedkope prut heeft daar altijd last van. Die zelfde prut heeft vaak ook geen optie voor BOOTP adressen ( = statische DHCP adressen ).

 

Als dan 1 device een nieuw IP aan vraagt, dan krijgt deze de eerst vrije, zeker als de router niet eerst controleert of er iets reageert op dat IP (wat een goede DHCP server doet).

 

Ik zou dan in ieder geval de DHCP server naar de Synology verplaatsen, die is beter dan menig provider routertje...

[40H3X]

Als dan 1 device een nieuw IP aan vraagt, dan krijgt deze de eerst vrije, zeker als de router niet eerst controleert of er iets reageert op dat IP (wat een goede DHCP server doet).

 

Just my point

 

 

Ik zou dan in ieder geval de DHCP server naar de Synology verplaatsen, die is beter dan menig provider routertje...

 

Ja, dat lijkt me een goede cq. veel betere oplossing en dan ook statische ip addressen introduceren en dan ook IP reservation on mac adres, heeft ieder apparaat altijd hetzelfde IP adres.

 

 

@WanWizard Overigens kijkt hier ook alles naar dezelfde klok, nl. de NTP server van de router en NTP loopt ook mee met DHCP, maar niet OS/apparaat snapt dat.

[Snoete]

Dit gaat vreselijk fout als de tijd op de NAS substantieel afwijkt van de tijd op de box, vooral als de NAS voor loopt.

 

Dus, als je de melding krijgt tot (bv) twee uur na de opname, dan kan het dus heel goed dat er een 2 uur tijdverschil is tussen box en NAS.

 

Mijn firewall is NTP source voor alle toestellen in mijn netwerk, dus lopen ze allemaal op tijd en gelijk.

 

Dit was de oorzaak voor de melding "Bestand mogelijk in gebruik door een ander proces" bij het verwijderen van een opname (op een NAS).

De tijd instelling van de NAS stond compleet verkeerd, handmatig op 20.30 uur en het is nu 17.30 uur.

Dat gewijzigd naar NTP en geen melding meer bij het verwijderen van een opname.

 

WanWizard bedankt voor de Gouden tip !

 

 

Verder kan ik jullie verbazing over een IP-conflict na een stroomuitval begrijpen.

 

Feit is dat ik deze opstelling met NAS en 4 ontvangers zonder eigen HDD al meer dan 10 jaar zonder problemen heb gebruikt, met dezelfde configuraties.

Dus één gedeelde schijf als vervanger van de interne HDD en één gedeelde schijf voor opslag van films.

Tot de stroomuitval ook geen netwerk problemen gehad, laat staan dat ik wist waar de tijdinstelling van mijn NAS stond.

 

Waarschijnlijk is er door de (korte) stroomonderbreking iets mis gegaan bij het opnieuw uitdelen van de IP-adressen door mijn Experiabox.

Kan het niet anders verklaren.

 

In eerste instantie gaf Windows bij het benaderen van de NAS aan dat het vaste IP-adres van de NAS al werd gebruikt.

Alle netwerk apparaten en PC's uitgeschakeld, router opnieuw gestart gevolgd door als eerste de NAS, geen effect nog steeds de melding IP-conflict in Windows.

 

Mijn ontvangers zagen de NAS niet meer, ook opnieuw mounten was niet mogelijk.

Daarom uiteindelijk de NAS een ander IP-adres gegeven en in de router diverse apparaten een vaste DHCP reservering.

Mijn Experiabox heeft inderdaad wel een statische DHCP reservering, maar tot 10 apparaten.

Daarna alles weer werkend, behalve dus die melding "Bestand mogelijk in gebruik door een ander proces".

 

Kan inderdaad de DHCP server naar de Synology verplaatsen, tot nu toe was daar nog geen reden voor...

De wifi van de Experiabox is al vervangen door een Ubiquiti Mesh, dan kan ik de DHCP server ook nog verplaatsen ;-)

Edited by Snoete, 28 May 2024 - 16:54.

[WanWizard]

Ik heb alles in DHCP zitten, maar alle "server" toestellen (en dus ook alle boxen) hebben een vast DHCP IP adres, dus buiten de dynamische reeks.

 

Ook checkt mijn DHCP server of een adres al ingebruik is, voordat hij het uit geeft. En derhalve nooit last van dubbelen...

[WanWizard]

@littlesat, we moeten toch eens kijken wat de zin en onzin van die 5 seconden check is, gegeven het feit dat je niks kunt zeggen van de staat van een server klok.

 

Wat is het uiteindelijke doel daar? Als de file in gebruik is volgt er toch wel een foutmelding als je probeert die toch te verwijderen? Die met een try/except kan worden afgevangen?

 

M.i. moet dat toch gebeuren, wat als de opname lokaal staat, de lokale disk is geshared naar een nadere box, en op die andere box wordt de opname afgespeelt op het moment dat je wilt verwijderen?

Daar doet deze check niks aan...

[littlesat]

Dat wordt naar heel lang terug zoeken en ik weet echt niet meer of iemand van 'ons' dat gedaan heeft of dat nog van de zolderkamer van de DMM proggers komt.

 

Ik vermoed dat het oorspronkelijke doel is om te kijken of de file nog door iets open is.... en het komt waarschijnlijk uit een tijd dat 99.9% van de gevallen de harddisk in de box zelf zat en niet in een NAS. 

[littlesat]

Ik had het misschien ook voor een lokale schijf via lsof gedaan of de file open stond of fuser... maar dit soort dingen gaan voor een NAS niet echt, zeker als een ander device ook op de file ingrijpt. Daarom is denk ik dat timestamp ooit een work-a-round geworden die werkt zolang alles in sync is... dit wordt even good door Googlen...\

Naar o.a. de size kijken gaat ook al niet want er kan van twee kanten naar de file 'gelezen' worden....

Edited by littlesat, 28 May 2024 - 17:57.

[WanWizard]

Code is from Mike, from 2010: https://github.com/O...638902aa3b21106

 

The idea was, as I initially thought, to create some buffer because an NFS server doesn't immediately release the file after closing it. But this code is plain wrong, giving the fact the chance on a time difference (which is for most home users without NTP configured) is very real.

 

I have to think about it, but I assume you just get an OS error if you try to delete a file that is busy, which you can catch and retry if needed.

[littlesat]

The OS error depends on the NAS if you get it or not and then it might already be too late. Mikes idea here is intended to be good. The time of equipment should also be configured good and that is the trigger here why it is not working (and the first report in 14 years). When we find a better method it is fine…. But ‘statistically’ I think it should not have the highest priority

[littlesat]

Just a work-a-round to put on the consideration list. Check the time/date from the decide where the file is stored with the current time…

[Tech]

Wat is er mis met in het Nederlands reageren in een Nederlands topic?

[WanWizard]

Niks, geen idee waarom ik over ging...

 

The OS error depends on the NAS if you get it or not and then it might already be too late. Mikes idea here is intended to be good. The time of equipment should also be configured good and that is the trigger here why it is not working (and the first report in 14 years). When we find a better method it is fine…. But ‘statistically’ I think it should not have the highest priority

 

Ik heb het even getest:

root@multiboxse:~# python
Python 3.9.9 (main, Jan 26 2024, 19:19:35) 
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.remove('/media/net/nas/Misc/20240529 1232 - NPO1 HD - NOS Journaal.ts')
>>> 

als je niet expliiet locking hebt geconfigureerd, dan wordt de file gewoon weggegooid, ook als die open is en er naar geschreven wordt,

 

Op de NAS blijft de file gewoon bestaan, maar als een tmp file:

root@multiboxse:~# lsof | grep "media"
5543	/usr/bin/enigma2	/media/net/nas/Misc/.nfs000000000001fdd400000001
5543	/usr/bin/enigma2	/media/net/nas/Misc/20240529 1232 - NPO1 HD - NOS Journaal.ts.sc

De NAS gooit die temp file overigens gewoon alsnog weg als de opname is afgelopen, het is niet dat je met die tmp file blijft zitten.

 

State checking is zoals we al hebben gezien onbetrouwbaar als de datum van de NFS afwijkt van die van de box, maar ook, afhankelijk van de mount opties, worden dit soort dingen client-side gecached.

 

Dus er moet iets anders bedacht worden voor de "in use" detectie.

[40H3X]

Helder uiteen gezet, nu nog wat

[littlesat]

Op de NAS blijft de file gewoon bestaan, maar als een tmp file:

->

Ben ergens ook 'bang' dat dit niet op alle NAS-sen gelijk is... en dan ook nog afhangt van mount opties etc... het wordt ergens wel een lastig dingetje... Voor lokaal op een harddisk van de box werkt het zoals het nu is lijkt me, maar voor NAS-sen duidelijk niet als de tijd van de NAS afwijkt... Ik kan even geen general oplossing verzinnen.... buiten het dan aan de NAS over te laten zoals in jouw voorbeeld....

[WanWizard]

Niet te snel bang zijn .

 

Integendeel, deze snelle test bewijst dat het juist op de NAS makkelijker verwijderen is dan op een lokaal device (want daar zui je wel een O_BUSY error krijgen die af te vangen is).

 

Het is en blijft een rare hack, die 5 seconden check (was eerst zelfs 10 seconden). Je wilt een opname verwijderen, verwijder die dan, en handel een eventuele foutmelding af als dat niet lukt. Dit soort truken zijn helemaal nergens voor nodig.

[littlesat]

 Dit soort truken zijn helemaal nergens voor nodig.

->

Je wilt toch voorkomen dat je die file verwijdert per abuis....? Zeker als een ander device er mee bezig is via de NAS...