Seite 1 von 1
Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 14:09
von NoRulez
Hi,
gibt es in python ein Module/Methode um eine Art Scope Lock durchzuführen?
Folgendes Problem.... Ich habe mehrere Projekte als Unterverzeichnisse. Das Script läuft alle 5 minuten per Cronjob durch die Verzeichnisse und tut etwas.
Da eine Operation länger dauern kann erstelle ich für das Verzeichnis das gerade bearbeitet wird eine Datei namens "project.lock" wobei "project" mit dem Namen des gerade bearbeiteten Projektes ersetzt gehört angelegt wird. Ist das Projekt fertig wird diese Datei gelöscht.
Der Sinn davon ist, das wenn ein Projekt länger braucht und der Cronjob erneut das Script ausführt, das Project das eine "lock" Datei hat übersprungen wird - da es ja gerade von einem anderen Script bearbeitet wird.
Dies funktioniert zum Teil, jedoch bleibt hin und wieder so eine "lock" Datei übrig, und somit wird dieses Projekt dann nicht mehr bearbeitet.
Gibt es ein Modul/Methode die so ein lock erzeugt und beim Abbruch des Script bzw. verlassen des Scopes (for schleife) die Datei oder was auch immer wieder freigibt?
Weiß jemand eine bessere Idee um das problem zu lösen?
Vielen Dank im Voraus
LG NoRulez
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 14:37
von snafu
Auch wenn's plump klingt, aber benutze mal eine Suchmaschine deiner Wahl. Da wirst du einige Module zu dem Thema finden.
Was das "Löschen" des Locks angeht, so würde ich, falls nicht bereits durch eine Lib unterstützt, einen simplen `try...finally`-Block empfehlen.
Generell finde ich die Sache mit dem `project.lock`-File jetzt nicht so schlimm und würde es dabei belassen. Aber vielleicht gibt's da andere Meinungen zu.
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 15:43
von NoRulez
Habe ich schon getan, jedoch habe ich keine Function gefunden die Cross Platform ist.
e.g. lockfile & Co.
Das schlimme an dem "project.lock" ist, das diese hin und wieder nicht gelöscht wird und somit das Projekt nicht bearbeitet wird. Das einzige was hilft ist manuell auf den Server gehen und die Datei löschen. Das kann's ja auch nicht sein
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 15:48
von deets
Was spricht gegen ein file-lock mittels des fcntl-Moduls? Das ist vom Betriebssystem garantiert, dass es funktioniert & nach Beendigung des Prozesses auf freigegeben wird. Schlimmstenfalls liegt die lock-Datei noch rum, aber das macht ja nix - man holt sich ja eh erst extra wieder ein richtiges Lock darauf.
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 15:58
von NoRulez
Weil ich überprüfe ob das lock file existiert, und falls es existiert überspringe ich das Projekt.
fcntl funktioniert nicht unter windows
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 16:15
von snafu
Unter welchen Umständen wird die Datei denn nicht gelöscht bzw nicht "entlocked"? Was spricht gegen meinen Vorschlag, diese Aktion in einen `finally`-Block zu packen? Solange der Interpreter nicht mit einem Segfault abstürzt, dürfte die Ausführung des Blocks garantiert sein. Mal ein Beispiel, wie ich das in etwa meine:
Code: Alles auswählen
def act_on_directory(dirname):
lock(dirname)
try:
for filename in get_files(dirname):
act_on_file(filename)
finally:
unlock(dirname)
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 16:24
von lunar
Folgender Quelltext erzeugt Sperrdateien atomar und löscht sie zuverlässig wieder:
Code: Alles auswählen
import os
from contextlib import contextmanager
@contextmanager
def lock_file(filename):
fd = os.open(filename, os.O_CREAT | O_EXCL)
yield
os.close(fd)
os.unlink(filename)
try:
with lock_file(filename):
# filename is now locked by this process
except OSError as error:
if error.errno == errno.EEXIST:
# filename already locked by another process
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 16:26
von snafu
@NoRulez: Sagt dir
portalocker vielleicht zu? Ich habe es jetzt selbst mittels Suche nach "lock" auf PyPi gefudnen, d.h. nicht ausprobiert. Der Beschreibung aus dem verlinkten Github-Repo nach ist es aber plattformübergreifend.
//edit: Natürlich nur nötig, sofern lunars Vorschlag nicht ausreicht.
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 16:48
von deets
snafu hat geschrieben:Unter welchen Umständen wird die Datei denn nicht gelöscht bzw nicht "entlocked"? Was spricht gegen meinen Vorschlag, diese Aktion in einen `finally`-Block zu packen? Solange der Interpreter nicht mit einem Segfault abstürzt, dürfte die Ausführung des Blocks garantiert sein.
Da sagst du es doch selbst. Und es muss ja nicht mal ein segfault sein - ein kill eines haengenden Prozesses, ein System-Shutdown, Power-Failure... usw. In all diesen Faellen musst du aufraeumen, und bei einem auf dem System beruhendem Lock musst du es eben nicht.
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 16:50
von deets
NoRulez hat geschrieben:Weil ich überprüfe ob das lock file existiert, und falls es existiert überspringe ich das Projekt.
Das ist doch kein Grund. Dieselbe Funktionalitaet erreichst du ja auch mit file-locking.
fcntl funktioniert nicht unter windows
Es gibt aber auch dafuer entsprechende Calls (hab' ich gerade nicht im Kopf). Und ueber einem *Netzwerk-Share* solche Sachen zu machen ist eh hoch riskant. Dann wuerde ich einen Service implementieren.
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 17:05
von NoRulez
deets hat geschrieben:NoRulez hat geschrieben:Weil ich überprüfe ob das lock file existiert, und falls es existiert überspringe ich das Projekt.
Das ist doch kein Grund. Dieselbe Funktionalitaet erreichst du ja auch mit file-locking.
fcntl funktioniert nicht unter windows
Es gibt aber auch dafuer entsprechende Calls (hab' ich gerade nicht im Kopf). Und ueber einem *Netzwerk-Share* solche Sachen zu machen ist eh hoch riskant. Dann wuerde ich einen Service implementieren.
Wer spricht von Network Shares? Es sind 4 Server, darunter ein Windows-Server
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 17:08
von deets
Ich habe das nur vermuten koennen, weil du cross-plattform erwaehnt hast. Und es sich so anhoerte, als ob dasselbe Lock von einem unix-System und einem Windows-System gleichzeitig geholt werden muss - zumindest hast du das nicht ausgeschlossen.
Wenn dem nicht so ist, dann ist wie gesagt das entprechende API auch unter Windows zugaenglich - bzw. benutz halt den portalocker, der macht genau das.
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 17:11
von NoRulez
lunar hat geschrieben:Folgender Quelltext erzeugt Sperrdateien atomar und löscht sie zuverlässig wieder:
Code: Alles auswählen
import os
from contextlib import contextmanager
@contextmanager
def lock_file(filename):
fd = os.open(filename, os.O_CREAT | O_EXCL)
yield
os.close(fd)
os.unlink(filename)
try:
with lock_file(filename):
# filename is now locked by this process
except OSError as error:
if error.errno == errno.EEXIST:
# filename already locked by another process
Wird diese auch gelöscht wenn der Prozess gekillt wird?
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 17:27
von lunar
@NoRulez: Natürlich nicht, schließlich ist es offensichtlich der Prozess selbst, welcher die Datei löscht. Wie deets bereits gesagt hat, ist keine Sperre, welche der Prozess selbst verwaltet, in dieser Hinsicht sicher. Das können nur Sperren des Systems leisten, die im Gegenzug eben nicht plattformunabhängig sind.
Allerdings ist es nicht schwer, die Sperre in dieser Hinsicht etwas zu erweitern. Zum einen kannst Du liegen gebliebene Sperrdateien beim Beenden des Prozesses löschen, indem Du entsprechende Funktionen über "atexit" oder "signal" (e.g. für SIGTERM) installierst, zum anderen kannst Du prüfen, ob der sperrende Prozess noch läuft (indem Du beispielsweise die PID des sperrenden Prozesses in die Sperrdatei schreibst und bei fehlgeschlagener Sperre auf Existenz des Prozesses prüfst).
Auch könntest Du die Sperrdateien außerhalb des Verzeichnisses an einem Ort erzeugen, der beim Systemstart bereinigt wird (unter Unix beispielsweise "/tmp/"). Ein Systemneustart sollte schließlich so ziemlich die einzige Ursache für den harten Abbruch eines Prozesses sein.
Re: Scope Lock?
Verfasst: Sonntag 31. Juli 2011, 18:34
von BlackJack
@lunar: Cron-Jobs werden bei Webhostern gerne auch mal nach einer bestimmten Laufzeit hart abgeschossen. Es ist also nicht nur der Systemneustart der „Leichen” hinterlassen kann.