Datei sperren: nochma dazu (Allgemeines zu Perl)

[thread]6343[/thread]

Datei sperren: nochma dazu

Leser: 1

mordur

2004-06-17 11:33

User since
2003-09-25
182 Artikel
BenutzerIn

moins,

ich hatte ja neulich schon mal was dazu gefragt und das konnte aber nur teilweise helfen.
Ich suche eine Lösung oder einen Ansatz für folgendes Problem:

In ein Verzeichnis werden Dateien geschrieben. Diese Dateien werden jeden Tag abends automatisch an einen anderen Rechner übertragen.
Dort werden sie ebenfalls automatisch ausgelesen.

Jetzt kann der Nutzer aber ausser der Reihe ebenfalls eine Datei in dieses Verzeichnis ablegen. Ich habe ein Dämon geschrieben, der nach diesen Dateien-ausser-der-Reihe sucht und sie dann versendet an den anderen Rechner. Dort läuft ebenfalls mein Dämon und soll diese ausser-der-Reihe-Dateien auslesen. Die bereits vorhandene Automatik nimmt diese Dateien aber auch mit, was sie auch soll- wer zuerst kommt, mahlt zuerst. Was aber tun, wenn mein Dämon jetzt zugange ist und just in dem Moment die automatische Übertragung antrabt? Die Dateien dürfen auf keinen Fall mehrfach übertragen,und auf dem entfernten Rechner ausgelesen, werden !! Ich wollte das evtl. mit flock sicherstellen, aber dass die vorhandene Automatik flock benutzt ist unwahrscheinlich.
Jetzt suche ich natürlich einen Ansatz, dass wirklich nur EIN einziger Prozess zur selben Zeit auf eine Datei Zugriff hat.

gruß mordur

betterworld

2004-06-17 12:34

User since
2003-08-21
2613 Artikel
ModeratorIn

user image

Leg doch eine lock-Datei an. Die kann jeweils der erste Prozess, der versucht, auf das Verzeichnis zuzugreifen, anlegen, sodass der zweite daran scheitert.

Mach es am besten so:

Code: (dl )

sysopen(LOCK, "$verzeichnis/.lock", O_CREAT | O_EXCL | O_WRONLY) or die "wahrscheinlich ist da schon ein anderer Daemon zugange"

Mit dem sysopen statt open und den angegebenen Flags kannst Du garantieren, dass das Ueberpruefen auf Existenz und das Anlegen der Datei in einem einzigen atomaren Zugriff geschieht.

Ich schrieb "wahrscheinlich", da es auch an Dateirechten liegen koennte, dass sysopen fehlschlaegt. Du kannst Dir ja noch etwas ausdenken, um solche Fehler abzufangen, wenn Du es brauchst.

Am Ende musst du natuerlich close() und unlink() aufrufen.

hth,
Betterworld\n\n

Lieblingsmodule: CPAN:

IPC::System::Simple, CPAN:

Path::Class

Gast Gast

2004-06-17 15:33

Da das alles ja wohl system-übergreifend stattfinden soll (also irgendwie auf zwei Maschinen verteilt), könnte das ganze LOCK-Problem damit umgangen werden dass man einfach mit blockierenden Sockets arbeitet - während ein Socket liest kann das andere Socket nicht schreiben (Flip-Flop-Funktion).

mordur

2004-06-18 10:30

User since
2003-09-25
182 Artikel
BenutzerIn

nun ja vielleicht hab mich undeutlich ausgedrückt. Die Vorgänge finden schon voneinander getrennt statt. d.h. wenn ich lokal auf die Datei zugreife ist es mir im Moment egal was remote passiert.D.h. auf dem Remote-Rechner läuft eine andere Instanz meines Dämon. Ich möchte nur sicherstellen, das auf einem Rechner nur ein Prozess auf einmal auf die Datei zugreifen darf. D.h. wenn mein daemon.pl die Datei anfasst darf xyz.pl keinen Zugriff haben. Und andersherum genauso. geht denn das mit sysopen wie beschrieben? ich weiss nicht wie xyz.pl codiert ist, dort steht eventuell nichts mit sysopen drin, oder flock o.ä. xyz.pl ist es also eventuell egal ob es eine Lock-Datei gibt? oder funzt sysopen so, dass das Betriebssystem das automatisch für ALLE zugreifenden Programme steuert? ODer muss ich xyz.pl dahingehend umschreiben, dass dessen Dateizugriff ebenfalls mit sysopen beginnt?

mordur

2004-06-21 14:26

User since
2003-09-25
182 Artikel
BenutzerIn

Nachdem ich nun massenweise Seiten gelesen habe mit Infos zu flock und sysopen etc. bin ich noch nicht wirklich schlauer.
Also: wenn mein Programm flock oder sysopen benutzt, um auf eine Datei zuzugreifen und in einem anderen Programm wird flock oder sysopen NICHT benutzt, bedeutet das, dass beide Programme zeitgleich an der Datei manipulieren können ( was Ärger macht) ? Ist das so richtig? Ich stelle aber mit flock oder sysopen sicher, das ein zweiter Prozess meines eigenen Programms NICHT an die Datei rankommt, wenn bereits ein erster Prozess meines eigenen Programms noch dran rum fummelt?

ptk

2004-06-21 14:49

User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]

[quote=mordur,21.06.2004, 12:26]Nachdem ich nun massenweise Seiten gelesen habe mit Infos zu flock und sysopen etc. bin ich noch nicht wirklich schlauer.
Also: wenn mein Programm flock oder sysopen benutzt, um auf eine Datei zuzugreifen und in einem anderen Programm wird flock oder sysopen NICHT benutzt, bedeutet das, dass beide Programme zeitgleich an der Datei manipulieren können ( was Ärger macht) ? Ist das so richtig?
[/quote]Ja. (sysopen nur mit O_EXCL)

Quote
Ich stelle aber mit flock oder sysopen sicher, das ein zweiter Prozess meines eigenen Programms NICHT an die Datei rankommt, wenn bereits ein erster Prozess meines eigenen Programms noch dran rum fummelt?

Ja. Du kannst die Aussage fuer *jedes* Programm, das flock benutzt, verallgemeinern.

mordur

2004-06-21 17:32

User since
2003-09-25
182 Artikel
BenutzerIn

das ist ja sch...

...eibenhonig!

Bleibt zu hoffen, das es mal irgendwannn eine Implementierung einer Dateisperre im Betriebssystem Linux gibt, die auch Progs berücksichtigt, die KEIN flock benutzen. Das wäre echte ein Fortschritt. Ich kann ja nicht immer die wahrscheinlich nicht bedachte Nachlässigkeit meiner Vorgänger ausbügeln, gerade wenn es Programme mit sehr komplexer Struktur.

ptk

2004-06-21 18:40

User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]

Ich hab mal nachgeforscht: es gibt tatsaechlich mandatory locks fuer Linux. Allerdings ist die Handhabung etwas sperrig und ein geeignetes Modul scheint zu fehlen. Hier ist aber funktionierender Beispielcode:

Code: (dl )

use strict;
use Fcntl qw(F_SETLK F_WRLCK SEEK_SET);

BEGIN {
        # c2ph says: typedef='s2 l2 i', sizeof=16
        my $FLOCK_STRUCT = 's s l l i';

        sub linux_flock {
            if (wantarray) {
                my ($type, $whence, $start, $len, $pid) =
                    unpack($FLOCK_STRUCT, $_[0]);
                return ($type, $whence, $start, $len, $pid);
            } else {
                my ($type, $whence, $start, $len, $pid) = @_;
                return pack($FLOCK_STRUCT,
                        $type, $whence, $start, $len, $pid);
            }
        }

}

if (fork != 0) { # parent
    open(BLA, ">/tmp/bla") or die $!;
    chmod 02644, "/tmp/bla" or die $!;
    warn "lock ...";
    fcntl(*BLA, F_SETLK, linux_flock(F_WRLCK, SEEK_SET, 0, 0, 0)) or die $!;
    warn "lock done...";
} else {
    sleep 1;
    warn "try to open in other process";
    open(BLA, ">/tmp/bla") or die $!;
    warn "open was successful";
}

Die Partition, auf der die Datei erstellt wird, muss mit "mand" gemountet sein. Ich konnte das auf meiner Maschine nachtraeglich mit

Code: (dl )

mount -o remount,mand /

aendern. Weiterhin muss die gelockte Datei eine merkwuerdige Rechtekombination haben: setgid-Bit gesetzt und group-execute geloescht. Im Listing von ls -al muesste die Datei so aussehen:

Code: (dl )

-rw-r-Sr--    1 nobody  nobody         0 Jun 21 16:36 /tmp/bla

Weiterhin muss statt flock() fcntl() zusammen mit F_SETLK verwendet werden. Leider habe ich zum Erstellen der Lock-Struktur kein Modul gefunden, aber der obige Code, teilweise uebernommen aus dem Perl Cookbook, erleichtert die Arbeit. Weitere Referenzen findet man in der Manpage zu fcntl(2) und hier.

Ronnie

2004-06-21 19:44

User since
2003-08-14
2022 Artikel
BenutzerIn
[default_avatar]

Okay, ich habe den Thread nur überflogen, aber was spricht gegen rsync?\n\n

View all threads created 2004-06-17 11:33.