Zu früh gefreut

[peter999]

Hallo Cypheros,
leider ist der Crash wieder da, kommt sehr selten, aber nun ist es wieder soweit....

Da der Crash immer die gleiche Position meldet (Speicherstelle), solltest Du in der Lage sein, das rauszufinden. Der Lasteintrag ist nun 0x40, also ist bereits über die Registry drüber...

Der Crash trat nun auf, als ich den Doktor wieder gestartet habe, einige Stunden vorher hatte ich den PC angemacht und ich hatte testweise den Doktor gestartet und beendet, dabei ist nichts passiert.
Nun vor ein paar Minuten habe ich den Doktor wieder gestartet, und dann bumm...


Noch ein paar Hinweise:
y:\ ist das Verzeichnis auf meinem QNAP TS-469L, in das ich die Aufnahmen meiner DM8000 HD speichere
u:\ ist das Verzeichnis auf meinem QNAP TS-412, in das ich die geschnittenen Aufnahmen vom Doktor speichere
d:\dm7025 ist ein Verzeichnis auf meinem PC, da habe ich vor Urzeiten mal einen REMUX gespeichert...
und
d:\temp spricht für sich selbst...

Alle Platten haben genügend Speicherplatz, der PC hat 32 GB RAM, eine 256 GB SSD als Bootplatte, eine 2 TB Platte als Datenplatte (D:), der Prozessor ist ein I7-3770K (4 Kerne, 4 HT), das Board ist Gigabyte (Sandy Bridge Z77).

Window 7, 64 Bit, Enterprise, aktuell...

In den letzten zwei-drei Wochen kamen kaum Updates, meist für Office 2010, Visual Studio 2010/2012 oder das lustige DotNet Gerümpel...

Vorgehen wie immer: Doktor starten, es kommt eine lange 14 % Phase, bisher hat die 104 alles verkraftet, aber diesmal war Schluß mit Lustig. Wie immer dann der Holzhammer....

Antrag auf ein Antragsformular zur Behebung der 14 %...

Das hat man nun davon, wenn man Urlaub hat und sich an den PC setzt und die liegengebliebenen Dateien versucht zu schneiden 

[Mam]

Versuch mal in der samba.conf auf Deinem NAS die Zeile

async smb echo handler = no  (bzw nicht vorhanden, da default)

auf

async smb echo handler = yes

zu ändern und boote das Teil neu
Es kommt häufiger vor, dass NASse nasse Füsse bekommen und mit irgendwas beschäftigt sind. Kommt die Überlebensquittung deshalb nicht schnell genug, so geht ein Windows Client von einem Konnektivitätsverlust aus und fährt erstmal alles durch Null.
Obige Zeile soll dies verhindern indem ein separater Task für die Quittung geforkt wird.
SOLL!
Ansonsten gilt bei Fehlern Deiner Art immer: Hätten wir doch mal lieber einen richtigen Server genommen...

[peter999]

Hallo Mam,
ich staune, mal eine ganz normale Antwort (gilt für mich allerdings auch)...

Ich habe meine drei NASe mal überprüft, es gibt keine samba.conf im QNAP. Ich habe über find / -name samba.conf
auch ein samba.* liefert diese Ausgabe:
[/] # find / -name samba.*
/mnt/ext/opt/avahi0630/etc/avahi/services/samba.service
/mnt/ext/opt/ldap_server/etc/openldap/schema/samba.schema
/mnt/HDA_ROOT/update_pkg/samba.tgz
[/] #

Was mich erstaunt ist, dass zum Zeitpunkt des Crashes ja noch keinerlei Datei aufgerufen ist (außer der Doktor fummelt alle Verzeichnisse ab), daher sollte das NAS eigentlich nicht mitspielen, da ich ja per "Öffnen" erst mal eine Datei auswählen will. Wenn die Platten schlafen, dann dauert es ein bisschen, dann kommt erst die Liste....

Und bis zum "öffnen" kommt der 14 % gar nicht...

[Mam]

Also meine Idee dahinter sind nicht die Zugriffe auf eine Datei, sondern die dafür nötige, zugrundeliegende Session.
SMB Sessions haben (meistens, kann man abschalten in der Registry) ein Timeout. Tut sich solange nichts, so wird die Sitzung klammheimlich geschlossen, der Anwender merkt davon nix.
Beim nächsten Zugriffsversuch erfolgt dann ein großer Schreck, ein interner Statusreset, ein Reconnect, eine Neuanmeldung und  dann gehts weiter.
Windows Loser kennen das von völlig unerwarteten und unvorhersehbaren "Stottern". Für ein paar Millisekunden, oder auch manchmal viel länger passiert "nix", alles steht.
Dann, kurz bevor man anfängt nervös zu werden, gehts weiter, als wenn nie was gewesen wäre.

Das ist, wie gesagt, NORMALES Verhalten.

Bei Fehlanpassungen des Protokolls (und wenn Du schon keine samba.conf gefunden hast, so deutet das auf einen groooossen Hack Deines Herstellers hin) kommen die beiden Partner unter Umständen aus dem Takt. Während der eine noch fröhlich an der Sitzung festhält, hat bei dem anderen schon längst das Timeout zugeschlagen. Was dann passiert ist sowohl sehr spannend, als auch völlig unvorhersehbar. Meistens gehts dann mörderisch in die Hose und macht JÖÖÖÖÖÖÖÖRRRRRRRGGGGGG....

Ein anderes Problem mit der "verlorenen Sitzung" ist es, wenn die Quittungen bezüglich "lebst Du noch?" nicht in einem bestimmten Zeitrahmen kommen (oder ganz in die Hose gehen). Passiert häufig bei lahmen Servern, die noch gerade auch noch anderweitig stark beschäftigt sind. Meistens glaubt dann der Klient, der Server wäre tot, und führt einen totalen Reset der Session aus (siehe oben), der Server wähnt sich aber noch bester Gesundheit und ist völlig perplex ob des dreisten Ansinnens. Auch hier ist das Endergebnis spannend und nicht vorhersehbar.

Das Problem stammt noch aus uralten DOS Zeiten, SMB als Netztwerkprotokoll wurde nach OSI Modell entworfen. OSI hat in der Praxis nie wirklich funktioniert (kennt einer noch Email nach X.400 Standard?). Danach wurde jahrelang rumgebastelt und geändert, so der große Wurf war nie dabei (der cleverste davon war noch den Kram über TCP/IP zu machen, dann kamen die Pakete schon mal am Ziel an).

ich hab zwar keinen Zugriff auf Deine NAS, aber ein einfaches GOOGLEN bringt mir:

Code Auswählen Erweitern


Re: Can we access the Samba CONF file?

Postby soopersonic » Wed Apr 07, 2010 4:01 pm
You can easily access the smb.conf file.

First login using SSH and putty (for example).
After that you can open the smb.conf file using the editor 'vi'.

    vi /etc/config/smb.conf


Read an introduction for vi, because it's probably different from what you know.

Don't forget to restart samba after editing the file:

    /etc/rc.d/init.d/smb stop
    /etc/rc.d/init.d/smb start

Andererseits findet sich auch so eine Warnung:

Code Auswählen Erweitern

And: The changes will be lost after reboot of the NAS. To automatically recover the changes at every reboot, you would have to edit the autorun.sh (there are how-tos for that, too) and make it copy over your smb.conf (saved permanently somewhere) to /etc/config


[peter999]

Hallo Mam,
die smb.conf ist vorhanden. Das Teil ist recht groß und unterteilt in Sektionen...

Aber ich hänge noch geistig an der Tatsache,  dass der Doktor crasht, bevor irgendwas geöffnet wird. Ich hatte zwischen drin mal die Quelle auf d:\verzeichnis gesetzt, das ist ein lokales Laufwerk...

Die QNAPs überschreiben alle Voreinstellungen beim Update einer neuen Version (das steht ja auch dort). Wenn Dir gerade einfällt, was man wo einpflegt, kann ich es gerne versuchen, gleich mir fehlt der Glaube, dass das der Grund ist.

[Mam]

Hallo Mam,
die smb.conf ist vorhanden. Das Teil ist recht groß und unterteilt in Sektionen...

Ja, einfach wäre doch zu einfach, nich? Allerdings müsste sich der Teil in der Abteilung [General] rumtreiben... (glaube ich, keine Ahnung, da kein Samba)

Aber ich hänge noch geistig an der Tatsache,  dass der Doktor crasht, bevor irgendwas geöffnet wird. Ich hatte zwischen drin mal die Quelle auf d:\verzeichnis gesetzt, das ist ein lokales Laufwerk...

Also wenn man sich Deinen Registry Eintrag da durchliest, ist doch ne ganze Latte Y:\ und U:\... vorhanden
Der Doc merkt sich mehr als nur die letzte Datei, ob er die auch alle abschnabbelt, weis ich nicht.

Hast Du eigentlich Y: und U: permanent gemountet???

[peter999]

Yep.
Wenn mein PC läuft (der für den Doktor), dann sind eine ganze Reihe von Freigaben über die NASe gemountet. Da Windows in letzter Zeit Diarroh hat, was den Netzwerkbetrieb, habe ich einen geplanten Job eingetragen, der die Freigaben mit NET USE nochmals freigibt, denn ohne mag Windows sich nicht verbinden (nicht nur zu den NASen, sondern auch zu meinen anderen Servern und Workstations...

Der Rechner, den ich nutzte, ist eigentlich primär für die Software-Entwicklung genutzt, die Sourcen liegen hat zur Sicherheit verteilt auf den NASen...
Der Doktor wird eigentlich nie als erstes Programm gestartet, nur wenn ich mal ein bisschen Zeit habe um mit den Filmen zu spielen...

[Mam]

Yep.
Wenn mein PC läuft (der für den Doktor), dann sind eine ganze Reihe von Freigaben über die NASe gemountet.

Der Mount an sich ist die Session von der ich rede. Deshalb ist es unerheblich, ob Du aktiv auf Dateien zugreifst oder nicht. Der Timeout betrifft den Mount.

Da Windows in letzter Zeit Diarroh hat, was den Netzwerkbetrieb,

Ich bin mir ziemlich sicher, das DORT Dein Problem liegt, der arme Doc ist nur das Opfer, dass drauf reinfällt. Eventuell behandelt er eine Fehlersituation nicht korrekt, oder nicht intelligent genug, aber der eigentliche Fehler liegt eindeutig tiefer.

Nun weis der Westfale nich, wie eine fränkische Diarröh aussieht (genauer betrachtet, will man das überhaupt sehen ? ? ?), aber Du musst schonmal etwas ausführlicher werden.

Ich gehe mal davon aus, dass Du keine Domäne im Einsatz hast, das die NAS dort im seltensten Falle mitspielen werden (wer schon bis eben nicht wußte, wo die Config ist, der kann auch kaum einer Domäne beigetreten sein).

Also hast Du überall auf den Kisten denselben User eingerichtet, mit demselben Passwort?

[peter999]

Na, ja
ich könnte mal versuchen ein Foto....

Ich habe keine Domäne, aber gleiche User/Passworte. Das Problem mit Windows 7 (die Diarröh) war, dass mit irgendeinem Update die Seuche in Form der Meldung "es konnten nicht alle freigegebenen Laufwerke verbunden werden" kam. Also war die Wahl zwischen Teufel und Belzebub, jeweils immer auf jede Freigabe doppelt klicken oder ein Script. Ich habe zweiteres gewählt, da ich von Natur aus faul bin...

Aber 100 % sind die Laufwerke gemountet, bevor ich den Doktor starte ! Und zwar, weil ich erst mal schaue, was die DM8000 wieder auf das Laufwerk gespeichert hat... Und die Freigaben sind nicht nur eine Freigabe pro NAS, sondern es sind etliche unterschiedliche Freigaben (teils per UNC geöffnet) die verwendet werden (Sourcen, Dokumente usw...)

Vielleicht kann ja mal Cypheros mal die Adresse suchen, die den Crash erzeugt (die sind seit einigen Versionen gleich), dann wissen wir mehr und müssen nicht im Trüben fischen...

[Mam]

Na, ja
ich könnte mal versuchen ein Foto....

Besser nicht, raub mir nicht alle meine Illusionen! 

Ich habe keine Domäne, aber gleiche User/Passworte. Das Problem mit Windows 7 (die Diarröh) war, dass mit irgendeinem Update die Seuche in Form der Meldung "es konnten nicht alle freigegebenen Laufwerke verbunden werden" kam. Also war die Wahl zwischen Teufel und Belzebub, jeweils immer auf jede Freigabe doppelt klicken oder ein Script. Ich habe zweiteres gewählt, da ich von Natur aus faul bin...

Aha, iss klar das Problem. Wieder einmal überholt der Schwanz den Hund beim Booten...
Die Lösung Deines Problems ist "Contenance", aber das ist ja wirklich ein Fremdwort :-)
Es gibt da mehrere Lösungsmöglichkeiten:

Probier mal diese Einstellung:

Code Auswählen Erweitern

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon]
"SyncForegroundPolicy"=dword:00000001

(sie zwingt Windows dazu, beim Booten auf das vollständige Laden des Netzwerkes zu warten. Damit sollten dann Anmeldungen an fremde Server/NAS erst ausgeführt werden, wenn sie auch übertragen werden können.)

Ansonsten tritt das Problem bei bestimmten Hardwarekonfigurationen auf, z.B. manche Gb Netzwerkkarten von Intel und NVIDEA haben diesen Bug (älteren Treiber versuchen!).

Aber 100 % sind die Laufwerke gemountet, bevor ich den Doktor starte ! Und zwar, weil ich erst mal schaue, was die DM8000 wieder auf das Laufwerk gespeichert hat... Und die Freigaben sind nicht nur eine Freigabe pro NAS, sondern es sind etliche unterschiedliche Freigaben (teils per UNC geöffnet) die verwendet werden (Sourcen, Dokumente usw...)

Nein, das glaubst Du nur  UNC Sessions sind ANDERE Sessions als die mit Laufwerksbuchstaben:

Code Auswählen Erweitern

C:\Users\mam>net use
Neue Verbindungen werden gespeichert.

Es sind keine Einträge in der Liste.


C:\Users\mam>dir \\hexalotte\c$
Datenträger in Laufwerk \\hexalotte\c$: ist SystemSSD
Volumeseriennummer: FE0C-5D49

Verzeichnis von \\hexalotte\c$

05.09.2013  07:06    <DIR>          AMD
07.09.2013  08:37    <DIR>          inetpub
18.11.2013  20:10               259 MailFilter.txt
14.07.2009  04:20    <DIR>          PerfLogs
05.11.2013  08:25    <DIR>          Program Files
10.12.2013  09:52    <DIR>          Program Files (x86)
06.09.2013  09:11    <DIR>          Users
12.11.2013  10:21    <DIR>          Windows
               1 Datei(en),            259 Bytes
               7 Verzeichnis(se), 65.639.550.976 Bytes frei

C:\Users\mam>net use
Neue Verbindungen werden gespeichert.

Es sind keine Einträge in der Liste.


C:\Users\mam>pushd \\hexalotte\c$

Z:\>net use
Neue Verbindungen werden gespeichert.


Status       Lokal     Remote                    Netzwerk

-------------------------------------------------------------------------------
OK           Z:        \\hexalotte\c$            Microsoft Windows Network
Der Befehl wurde erfolgreich ausgeführt.
Du siehst? der DIR Befehl über UNC macht keine permanente Session auf, erst der Mount über pushd erzeugt eine (ist ja nun LWK z:)

Vielleicht kann ja mal Cypheros mal die Adresse suchen, die den Crash erzeugt (die sind seit einigen Versionen gleich), dann wissen wir mehr und müssen nicht im Trüben fischen...

Ich bezweifle stark, dass die Adresse zwischen verschiedenen Maschinen gleich bleibt.

[peter999]

Illusionen ? Wasndat ?

Gontenaze ? siehe oben... Isch bin erupdif !

So, nun zum Wesentlichen.. Da der Key nicht da ist (siehe Bildchen) nehme ich an, ich sollte ihn erzeugen !?

Zum UNC: Wenn ich eine Datei per UNC öffne, habe ich damit keinen Mount, das ist ganz klar. Aber machmal reicht ein einfacher UNC-Pfad zum Arbeiten aus... Mounten ist eigentlich Faulheit, die ich beim Doktor nutze...

Zur Adresse: das dürfte so stimmen, aber es sagt auch aus, dass der Crash immer am gleichen Punkt entsteht. Aber Cypheros hat ein bisschen Paranoia wegen seines Codes, der mich nicht interessiert, wie schon ein paar mal erklärt. Warum sollte ich mir den Doktor kaufen, wenn ich mich damit auskennen würde ? Ich kaufe mir meist Software, von der ich nichts verstehe, sonst könnte ich sie ja selbst schreiben... Und solange der Crashpunkt bei Cypheros nicht gefunden wird, habe ich ihn weiterhin. Möglichkeiten, das zu finden habe ich ja schon aufgezeigt, aber ich habe keinen Bock mich immer wieder wiederholen zu müssen..

Ich hoffe, nichts vergessen zu haben (außer den Fotos  )

[Mam]

So, nun zum Wesentlichen.. Da der Key nicht da ist (siehe Bildchen) nehme ich an, ich sollte ihn erzeugen !?

Clever! Ein geschicktes Gatt&Pehst des Skripts in eine Datei mit der Endung .Reg gefolgt von einem beherzten Dobbelglick (Isch spreschen frängisch!) auf dieselbe Datei hätten Dir das schon abgenommen. Aber ich seh ja, Du bist der Hardcore Freak und willst alles selber machen.

Zum UNC: Wenn ich eine Datei per UNC öffne, habe ich damit keinen Mount, das ist ganz klar. Aber machmal reicht ein einfacher UNC-Pfad zum Arbeiten aus... Mounten ist eigentlich Faulheit, die ich beim Doktor nutze...

Wie schon so oft, hast Du mich mal wieder komplett missverstanden. Meine Ausführungen gingen eigentlich dahin, dass bei Mounten Bropleme mit Timeouts entstehen können, bei Verwendung von UNC Pfaden eigentlich nicht (da sie keine statusbehafteten Sitzungen aufbauen, wo nix Status, da kann auch nix in die Irre gehen und unsynchron werden).
Lass doch einfach mal den Doc die Dateien über UNC öffnen, und schau, was passiert (oder eben nicht mehr passiert).

Zur Adresse: das dürfte so stimmen, aber es sagt auch aus, dass der Crash immer am gleichen Punkt entsteht. Aber Cypheros hat ein bisschen Paranoia wegen seines Codes, der mich nicht interessiert, wie schon ein paar mal erklärt. Warum sollte ich mir den Doktor kaufen,

Ja, ich gebe zu, es kommt mir auch manchmal etwas paranoid vor, deshalb lass ich ihm seine Illusionen der wirkungsvollen Maßnahmen 

wenn ich mich damit auskennen würde ? Ich kaufe mir meist Software, von der ich nichts verstehe, sonst könnte ich sie ja selbst schreiben... Und solange der Crashpunkt bei Cypheros nicht gefunden wird, habe ich ihn weiterhin. Möglichkeiten, das zu finden habe ich ja schon

Gute Arbeit muß honoriert werden, keine Frage.

Aber, wenn der Viehtrieb (ääh, der Vertrieb) mehr Kohle einsackt, als der Erbauer, dann kehrt sich bei mir das Denken um 

aufgezeigt, aber ich habe keinen Bock mich immer wieder wiederholen zu müssen..

Dann tus doch nicht. Er hat doch keine Chance zu erraten, was Deinen verkorksten Rechner aus dem Tritt bringt. Und solange das nur bei Dir passiert, würde ich es auch als PAL^* behandeln.

(^* = Problem anderer Leute)

[peter999]

Als erstes mal Brrrrrrrr !
Du nixe schbreche Frängisch !!!

Das mit dem Registry Eintrag dud nichd das was es sollen dun. Da hasd du ein bisschen zu wenich gesuchd, das scheind nur mit xb oder dsweiunddreisich bidd. Und eine Menge Leude haben fesdgeschtällt, dass das ned wirklich klappd..
Und mid der Regesddrie kann ich schon auch mid der Bfode selber dun... Da brauch ich kein Schgribbt.

So, nun wieder Niederdeutsch...

Ich habe das schon vorher eingetragen, mein Skript aus dem Scheduler genommen und neu gestartet, alle Freigaben haben das schöne rote Kreuz (nicht mit dem BRK zu verwechseln).

Im Rahmen der Möglichkeiten mit Windows ist mein System nicht wirklich verkorkst (oder verkorkt ?)... Denn fast alles funktioniert damit, nur nicht mit dem Doktor.

(Jetzt kann ich's ja zugeben, ich habe immer den Dialog mit der jeweiligen Programmversion neu gemalt und den alten Dialog reinkopiert)... Und ich lüge nie !

[Cypheros]

OK, NAS-Server Synologie DS112+ ist aufgebaut und angeschlossen. Hat etwas gedauert, aber ein winziger Tipfehler bei der Workgroup hat verhindert, dass ich den NAS unter Netzwerk sehen konnte.

Teste momentan was passiert, wenn ich Aufnahmen über UNC aufrufe und dann warte bis der NAS in den Standby geht.

Da ja die Initialisierung klappt (0x40), muss der Fehler irgendwie später passieren. Diese NAS-Geschichte sieht vielversprechend aus. Mal sehen wo wir da hinkommen. Ist zur Zeit wirklich der einzige Fall in dieser Richtung.

[peter999]

Hallo Cypheros

ich habe keine UNC Verbindungen für den Doktor, alles über sauber verbundene Laufwerke. Y=Quelle (QNAP 469L) U=Ziel (QNAP 412)...

Und diese Laufwerke sind in jedem Fall verbunden, bevor der Doktor gestartet wird....

Nur so als Info.

Aber mach mal wie Du denkst...