[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: File-Locking in Shellscripten auf NFS


Am 08.12.2010 21:19, schrieb Raphael Eiselstein:
> 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

Nein. Die Datei mit der PID dient in der Regel nur dazu die PID des
entsprechenden Prozess spaeter einfach wiederzufinden. Die meisten Server bzw.
Daemons die eine PID-Datei schreiben koennen haben nichts dagegen (z.B. mit
unterschiedlichen Konfigurationen) mehrfach gestartet zu werden.

Will ein Programm explizit Mehrfachausfuehrung verhindern nutzt man in der
Regel IPC (inter-process communication), d.h. z.B. eine Semaphore.
Netzwerkdaemons haben es da relativ einfach, die nutzen dazu einfach bind, was
dann (auf die Nutzung des entsprechenden Ports bezogen) den gleichen Effekt
hat.

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

Nein.

> 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?

Ich wuerde das eigentliche Problem beseitigen. D.h. die offensichtlich zentrale
Aufgabe (sonst waere Mehrfachausfuehrung ja wohl kein Problem), zentral
erledigen lassen, oder die Problemstellung so angehen, dass Mehrfachausfuehrung
kein Problem ist.

Dazu Dateien zu nutzen ist, wie bereits festgestellt, mehr oder weniger
ungeeignet, zumindest wenn das Locking des Dateisystems nicht zur
Synchronisation missbraucht werden kann.

Mehr kann man aufgrund der duerftigen Problembeschreibung nicht sagen.

Gruss,

Alexander

-- 
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/