AW: File-Locking in Shellscripten auf NFS

[Johannes Walch <j.walch@xxxxxx>]

Hi Raphael,

warum nicht einen resource monitor wie heartbeat verwenden? Muesste man eventuell die helper scripts noch ein wenig anpassen, aber ansonsten sollte das klappen. Falls eine selbstgebaute Loesung zum Einsatz kommt kann man statt TCP service mit PID ausgabe auch SNMP verwenden. Da lassen sich alle Prozesse abfragen. Das fuehrt aber bei N Systemen natuerlich zu (N-1)^2! an Abfragen, kann also viel werden.

Johannes

-----Urspruengliche Nachricht-----
Von: uugrn-bounces@xxxxxxxxx [mailto:uugrn-bounces@xxxxxxxxx] Im Auftrag von Raphael Eiselstein
Gesendet: Mittwoch, 8. Dezember 2010 21:19
An: UUGRN Mailingliste
Betreff: File-Locking in Shellscripten auf NFS

Hallo zusammen,

fuer manche Anwendungsfaelle moechte man z.B. vermeiden, dass ein Script mehrfach parallel ausgefuehrt wird, etwa per cron, wenn die Ausfuehrung aus irgendwelchen Gruenden laenger dauert als die Periode in cron eingestellt ist.

Der IMHO uebliche weg ist ein PID-File zu schreiben, welches die Prozess-ID des laufenden Prozesses enthaelt. Wird das Script (oder
Programm) dann parallel nochmal gestartet, kann man anhand des vorhandenen PID-Files bzw. nach Ueberpruefung der darin enthaltenen PID herausfinden, ob eine weitere Instanz bereits laeuft und entsprechend darauf reagieren, zB nicht nochmal neu starten.

Wie wuerde man so ewtas implementieren, wenn es mehrere Systeme gibt, die ein bestimmtes Programm periodisch ausfuehren aber sichergestellt werden soll, dass immer nur eins gleichzeitig ausgefuehrt wird?

Man koennte hier zwar auch ein PID-File auf ein gemeinsames NFS-Volume schreiben. Das liesse sich dann aber nicht pruefen, d.h. ein vorhandenes PID-File allein genuegt nicht um zu ueberpruefen, ob die darin enthaltene Prozess-ID noch gueltig ist (der Prozess laeuft ja moeglicherweise auf einem fremden System).

Kann man auf NFS eine Datei derart locken, dass der Lock entfernt wird, falls der "sperrende" Prozess abgestuerzt ist?

Und wenn ja, wie implementiert man soetwas in einem Shellscript oder mit welchem Standardtool kann man das tun? Wie erkennt man nicht nur, dass ein anderer Prozess gestartet ist sondern dass diese PID auch noch aktiv ist?

Ein Workaround waere, auf jedem der beteiligten Systeme einen unabhaengigen Cronjob zu haben, der alle PID-Files sucht und prueft, ob der entsprechende (lokale) Prozess noch aktiv ist. 

Dabei muesste im PID-File allerdings auch der Hostname enthalten sein, sonst wuerde der Garbage-Collector-Job auf Host A ein PID-File wegraeumen, welches von Host-B aus geschrieben wurde.

Nachteil dieser Methode: stirbt das ganze System (zB Host B), wuerde das Lock-/PID-File auf dem NFS liegen bleiben und nicht weggeraeumt werden, da ja auch der Garbage Collector-Job nicht mehr laufen wuerde.

Man koennte als Workaround^2 dafuer sorgen, dass alle Hosts sich gegenseitig den Garbage Collector Job ueberwachen. Dazu muesse der GC-Prozess auf jedem System ein Statusfile updaten und jeweils alle GC-Monitoring-Prozesse wuerden anhand des Dateialters herausfinden, wenn ein GC-Job laenger als erlaubt nicht mehr gelaufen ist und damit den jeweiligen Host fuer tot erklaeren und entsprechend auch alle PID-Files des fuer tot erklaerten Host automatisch wegraeumen.

Diesen Workaround und Workaround^2 halte ich aber insgesamt fuer zu fragil als dass ich das als sinnvolle Loesung ansehen wuerde.

Ein anderer Workaround waere, zB per xinetd einen Service anzubieten, der per einfachem TCP-Connect mit PID als Eingabe mit der Ausgabe "running", "stopped", ... den jeweilgen Prozess-Status (sofern vorhanden) ausgibt.
Damit koennten dann andere Hosts im Netz auch fremde PID-Files verifizieren und ggf. fuer ungueltig erklaeren.

Das einzige, was in diesem Setup als "hochverfuegbar" angesehen werden kann ist der NFS-Server, alle NFS-Clients sind einfache Systeme die unabhaengig voneinander funktionieren muessen, d.h. es darf kein anderes "zentrales System" geben.

Gibt es eine *einfache* Loesung basierend auf NFS?

Danke und Gruss
Raphael

-- 
Raphael Eiselstein <rabe@xxxxxxxxx>               http://rabe.uugrn.org/
xmpp:freibyterægmx.de  | https://www.xing.com/profile/Raphael_Eiselstein   
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..
-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/