On Sam, 28 Jun 2003 at 11:26 (+0200), Marcus Roeckrath wrote:

Nohn Markus wrote on Samstag, 28. Juni 2003 10:07 about Wie baut man ein spool-verzeichnis:

Die Hälfte Deiner gewaltigen Einleitungszeile steht schon im Subject.

...

gibt es ein Möglichkeit mit Bordmitteln von Perl oder bash eine Art Spoolverzeichnis zu überwachen?

Vielleicht mit folgendem Fragment, wobei man das Script einfach in der boot.local startet.

#!/bin/bash # # Simple script daemon

while true do

# put your commands here

sleep 60

Dann kannst Du auch gleich einen crontab minütlich laufen lassen.

done

Ich habe prinzipiell Bauchschmerzen bei bash-Scripts, die mit while true; do done arbeiten. Sowas sollte man immer zumindest über einen crontab-Job überwachen lassen (man kriegt es selten so abgedichtet, dass es _nie_ abstürzen kann und dann sollte die Möglichkeit eines Wiederanlaufs da sein). Jan

On Sam, 28 Jun 2003 at 20:36 (+0200), Markus Nohn wrote:

Am Samstag 28 Juni 2003 20:07 schrieb Jan Trippler:

...

Die Hälfte Deiner gewaltigen Einleitungszeile steht schon im Subject.

Und die "Antwort" darauf ist 0,6 KB größer als meine Frage.

Ich hatte nicht Dich gemeint - das war aber aus meinem Quoting heraus deutlich zu sehen. Meine "Antwort" bestand aus mehr als dieser Zeile und hatte sachlich mit dem Thema zu tun - wenn Du meine ganze Mail gelesen hättest, wäre Dir das aufgefallen. Jan P.S.: Ich habe keine Lust mehr, mich dauernd dumm anmachen zu lassen: *PLONK*

On Sam, 28 Jun 2003 at 21:43 (+0200), Kristian Koehntopp wrote:

On Sat, Jun 28, 2003 at 08:07:57PM +0200, Jan Trippler wrote:

...

Ich habe prinzipiell Bauchschmerzen bei bash-Scripts, die mit while true; do done

arbeiten. Sowas sollte man immer zumindest über einen crontab-Job überwachen lassen (man kriegt es selten so abgedichtet, dass es _nie_ abstürzen kann und dann sollte die Möglichkeit eines Wiederanlaufs da sein).

Das kommt darauf an, was man erreichen will. Ein Crontab-Eintrag hat die Chance auf multiple parallele Instanzen desselben Scriptes, wenn die Laufzeit des Scriptes durch was auch immer laenger wird als das Intervall, in dem Cron die Scripte startet. Wenn Du also minütlich Dein Script hochziehst, es aber durch einen hängenden NFS-Server im $PATH länger als eine Minute stehen bleibt, dann stapeln sich die Scripte übereinander.

Ich schrieb was von *Überwachen*, nicht von *bedingungslos neu starten*. Dass man vorher per *pidof*, Lockfile oder mit anderen Mechanismen prüft, ob das Script noch läuft, hatte ich dabei schon im Sinn. [while true]

kann niemals konkurrierende Instanzen haben, sondern es prodziert immer nicht überlappende Iterationen. Den Wiederanlauf regelt man leicht damit, daß man das Script mit einem "respawn"-Eintrag in die /etc/inittab setzt, denn dafür ist init genau da:

kk:235:respawn:/root/bin/meiniterator.sh mit drei parametern

und dann ein telinit q.

Das ist auch eine Möglichkeit. Ich bin aber des Öfteren in Situationen, wo ich möglichst flexibel regeln will, dass eine einstellbare Anzahl paralleler Instanzen laufen soll (wenn z. B. eine Queue abhängig von der Last - resp. der Anzahl der zu verarbeitenden Dateien - reagieren können soll). Dann ist IMHO crontab besser geeignet. Mit diesen Gedanken im Hintergrund hatte ich auf cron verwiesen. Jan

Hallo! Am Samstag 28 Juni 2003 11:43 schrieb Frieder Simmeth:

Man könnte ein Programm verwenden das das verzeichniss auf Schreibzugiffe überprüft und ggf ein script startet. Sowas z.B.: http://www.student.lu.se/~nbi98oli/dnotify.html

Das ist genau das was ich wollte. Vielen Dank für den Tipp! Gruß! Markus.

On Sat, Jun 28, 2003 at 08:43:48PM +0200, Joerg Rossdeutscher wrote:

Wenn ich z.B. ein ghostscript starten möchte, nachdem eine postscript-Datei in einen Ordner gelegt wurde, dann darf gs erst starten, wenn die Datei komplett drin ist, und das kann schonmal ein paar Minuten dauern. Wenn er losrennt, sobald die Datei auftaucht, gibt es garantiert Murx.

Auch das ist ein häufiges Problem, und man löst es, indem man am Ende des Uploads eine atomare Operation im Dateisystem ausführt. Atomar sind das Anlegen, das Löschen oder das Umbenennen von Dateien. Man kann also a) die Datei hochladen ("daten.ps") und dann eine Triggerdatei anlegen ("daten.ps.doit"). Mit dem Anlegen der Triggerdatei startet die Verarbeitung. b) eine Lockdatei anlegen ("daten.ps.LOCK") und dann den Upload starten. Ist der Upload fertig, löscht man das Lock wieder und die Verarbeitung startet. c) den Upload in eine Workdatei vornehmen ("daten.ps.UP") und am Ende die Workdatei umbenennen ("daten.ps"). Die Verarbeitung faßt Dateien, die die Endung ".UP" haben, grundsätzlich nicht an. Je nach Szenario können unterschiedliche Verfahren opportun sein, bei Upload mit ftp und scp verwende ich meist a oder c, UUCP verwendet a (D-Datei mit den Daten, gefolgt von X-Datei mit dem Kommando), rsync verwendet c (".datei.ps.<pid-spezifische-kennung>" wird zu "datei.ps"), Mail und auch einige POP-Server verwenden auf vielen Systemen b. Kristian

Am Samstag 28 Juni 2003 20:43 schrieb Joerg Rossdeutscher:

Meldet sich das Programm, wenn ein Verzeichnis sich ändert, oder wenn die Veränderung abgeschlossen ist? Letzteres wäre interessant.

Erst die Datei ins Verszeichnis kopieren und anschließend die Rechte der Datei ändern. dnotify vorher mit der Option -B (Überwachung der Änderung von Dateirechten) starten. Gruß, Markus.