Probleme bei Samba?/tbl-Datei gesperrt

[glaser at ub.tum.de]

Am 21 Dec 2001, um 10:55 hat Bernhard Eversberg geschrieben:

> On 20 Dec 01, at 18:41, glaser at ub.tum.de wrote:
> 
> > So wie es aussieht, bleibt also als letzer Strohhalm nur die log-Datei. Und 
> > die liefert eigentlich auch nicht das Gewünschte, denn beim letzten Eintrag 
> > hat's ja noch funktioniert! Interessant ist doch der Eintrag, der NICHT mehr
> > geschrieben werden konnte.
> > 
> NEIN! Das Programm speichert zuerst in die ALD, dann in die LOG, dann werden die 
> Indexeintraege bearbeitet, dann TBL wieder freigegeben. Es ist also sehr
> wahrscheinlich, dass der letzte LOG-Satz auch derjenige ist, nach dessen
> Speicherung die TBL nicht wieder freigegeben wurde.
> 
'Wahrscheinlich' schon; denn es ist auch denkbar, daß es zwar zur Sperre 
der TBL gekommen ist, aber zu keinem Schreibvorgang aus welchen 
Gründen auch immer.

Werte Allegrologen, lieber Herr Eversberg,

beim Fahnden in der tbl-Geschichte habe ich folgende Experimente 
gemacht:

A. (Einzelplatzbetrieb, es exisitiert eine DB zs)
1. free zs.tbl
2. Ansehen mit he zs.tbl -> 1. Byte 00 OK!
3. unfree zs.tbl
4. Ansehen mit he zs.tbl -> 1. Byte 01 OK!
5. Aufruf der Datenbank, öffnen eines Satzes und schließen -> problemlos 
möglich! Eigentlich erwartet: tbl-Datei gesperrt. kam aber nicht.
6. Nachgesehen mit he zs.tbl -> 1. Byte 01 immer noch!!!
7. Aufruf der Datenbank, ergänzen eines Satzes und abspeichern. 
problemlos möglich! Eigentlich erwartet: tbl-Datei gesperrt. Kam aber nicht!!!
9. wie 4.
10. Kontrolle ob es sich auch um dieselbe tbl-Datei handelt: Aufruf der 
Datenbank. Parken der Ausgabe. Aufruf he zs.tbl. Meldung: keinDatei.

Einigermaß ratlos wandte ich mich zum Programmaufruf, und siehe da: der 
Einzelplatzmodus -S war gesetzt. Nach Entfernung desselben trat das 
erwartete Verhalten auf: Also unfree -> Aufruf mit Änderung/Eintrag -> tbl-
Datei gesperrt -> free -> Änderungen möglich.

Ergebnis:
Obwohl es unnötig ist, im Einzelplatzmodus die tbl-Datei zu sperren, wäre 
es m.E. der Konsistenz halber sinnvoll, entweder den -S-Parameter ganz 
zu eliminieren, oder die Datenbanksperre auch hier wirken zu lassen.
Sonst ist das Verhalten zwar logisch nachvollziehbar, aber trotzdem 
enigermaßen verwirrend.

B. (Voraussetzungen wie bei A)
1. unfree zs.tbl
2. Datenbankaufruf und Eränzungsversuch eines Satzes. Wie zu erwarten 
kam 'zs.tbl gesperrt, bitte warten' u.z. 90 sec lang, wie von Herrn Eversberg 
vor kurzem mitgeteilt. Danach kam der #-Prompt der Eingabe und 
'Schweigen im Walde. Erneuter Specherversuch mit F10 liefert daselbe 
Ergebnis. Bleibt also nur der Abbruch mit F8.
3.he zs.tbl -> 1.Byte noch immer 01. 

Ergebnis:
Nach 90 sec wird zwar die Meldung 'tbl-Datei gesperrt' nicht mehr 
ausgegeben, die tbl-Datei selber aber NICHT freigegeben (vermutlich käme 
dann auch statt dem #-Prompt die Meldung 'Satz gespeichert'). Offenbar 
wird beim Speichern festgehalten, ob der momentane Prozeß die tbl-Datei 
manipuliert hat, oder jemand anderer (z.B.über unfree); denn sonst wäre 
nicht einzusehen, warum die tbl-Datei nicht zurückgesetzt wird. Das würde 
aber u.U. geordnete Schreibvorgänge durcheinanderbringen.

C.Netzbetrieb unter Samba mit einer DB mo. Gemountete LW:g:\allegro; 
h:\aufruf, i:\daten 
Experiment wie unter B mit demselben Ergebnis, d.h. nach 90 sec 
verschwindet zwar die Meldung, nicht aber die DB-Sperre. 
(Nebenbei: Server und Client wurden auf verschiedene Lokal-Zeiten gesetzt. 
In der Log-Datei wird unter der Client-Zeit abgespeichert. Hat das 
Konsequenzen? Und beim Speichern in die Log-Datei scheint es auch 
KEINE Verzögerung zu geben. Vielleicht liegt's bei der PHP-Angelegenheit 
doch nicht an Samba?)

D. Voraussetzungen wie bei C, diesmal mit einem zweiten Client, auf dem 
dieselben Verzeichnisse unter denselben LW-Buchstaben gemountet 
waren.
1. free mo.tbl
2. Aufruf der DB auf beiden Clients und Ergänzung zweier verschiedener 
Sätze. Speichern gleichzeitig, d.h. Drücken der j-Taste gleichzeitig.
Ergebnis: Beide Sätze werden gespeichert, wobei kurzzeitig beim 2. Client 
'tbl-Datei gesperrt' erschien. Ansonsten Verhalten normal.

E. Voraussetzungen wie bei D.
1. unfree mo.tbl
2. wie bei D.2.
Ergebnis: wie bei B.2 und B.3, d.h. TBL-Datei bleibt gesperrt. Mit allegro-
Mitteln scheint man nicht weiter zu kommen.

Weiterarbeiten mit Unix-Mitteln
Hier will ich mich küzer fassen. Per shell-Skript wird festgestellt, wann und 
wielange die tbl-Datei gesperrt war. Der debug-Level von Samba wird 
heraufgesetzt ( bei 2 werden schon die verwendeten Datei-Namen 
angezeigt) und über die Zeitmarke versucht, den Übeltäter zu finden.
Das soll's dann wohl gewesen sein!

mfg gl