Bernd Tannenbaum wrote:
Am Mittwoch, 3. September 2003 09:15 schrieb Werner Merz:
Bernd Tannenbaum wrote:
Hullos,
Am Dienstag, 2. September 2003 23:08 schrieb Bernd Brodesser:
* Bernd Tannenbaum schrieb am 02.Sep.2003:
Am Dienstag, 2. September 2003 11:53 schrieb Andreas Kyek:
a) Deine Lösung ist nicht sicher, da prinzipiell zwei verschiedene Instanzen die Datei mit gleichem Inhalt lesen können
Yop, das ist richtig aber egal. Da nur ich an der Kiste sitze und eben auch mal 5 Sitzungen öffne, die über autossh offen bleiben sollen, ist klar, das diese nacheinander aufgerufen werden, nie gleichzeitig. Wenn das anders wäre, könnte man dem aber auch sicher leicht entgegenwirken, indem man ein Token vergiebt, welches die Resourcenverwaltung auf die Textdatei regelt.
Außschließen, das Du es vielleicht versehentlich zweimal aufrufst, kannst Du nicht.
Hmm, bist du da sicher? Das System einer Tokenvergabe sollte sich doch auch unter Linux realisieren lassen. Jan hat mir eine mögliche Lösung über Locks gemailt aber auch geschrieben, das dies nicht völlig sicher ist. Gesetzt den Fall, das ich das Problem bearbeiten müsste, wäre meine erste Idee folgende:
1) Neben der Textdatei noch eine zweite Dummydatei erstellen, auf diese Datei hat der Prozess Schreibrecht. 2) Ruft jemand das script auf, prüft es zuerst ob es etwas in die Datei schreiben kann. Falls ja, schreibt es etwas shell-spezifisches (die tty-Nummer) in die Datei und in eine Variable und ändert die Rechte in Nur-lesen. 3) Eine zweite script-Instanz kann nicht in die Datei "dummy" schreiben und muß warten. 4) Der problematische Fall ist natürlich, wenn 2 Instanzen zeitgleich aufgerufen werden, die beide erfolgreich in die Dummy-Datei schreiben können und dann die Rechte ändern. 5) Hierfür wird nun eine zweite Abfrage nach 1 Sekunde Wartezeit an die Dummy-Datei gemacht, in der das Script die Datei ausliest. Stimmt der Inhalt mit der gespeicherten Variable überein, hat das Script das Token und darf weitermachen. Falls nicht, muß es wiederum warten. Haben also 2 Instanzen gleichzeitig in die Datei geschrieben, wird am Ende trotzdem nur 1 Inhalt drinstehen, weitere Änderungen sind nicht möglich da die Schreibrechte weg sind. Der Token ist somit eindeutig vergeben.
Ist jetzt nur so eine spontane Überlegung, ist ein Denkfehler drin?
Sieht eigentlich gut aus, was Du dir überlegt hast, ist aber ziemlich kompliziert für den von dir vorgesehenen Zweck.
Vielleicht könnte für Dir /usr/bin/lockfile dienlich sein. Schau mal die manpage an.
Yo, Jan hat auch eine Lösung mit Lockfiles vorgeschlagen. Er erwähnte aber auch, das diese keine 100%tige Sicherheit bieten, worin Bernd wohl übereinstimmte. Daher hier mein Gedankenspiel, wie sich das 100%ig sicher bewerkstelligen lässt. Das das dann völlig überzogen kompliziert für so eine "Spielanwendung" ist, darin stimme ich mit dir überein. Geht mir mehr darum, ob die theoretische Überlegung stimmt oder ein Denkfehler drin ist.
MfG, Bernd
OK, Das einzige Problem, das ich in deinem Script sehe ist folgendes: A testet ob Token writeable ist. Ja ist writeable B testet im selben Moment ob das Token writeable ist. Ja ist writeable. A schreibt A setzt Token auf readonly B will schreiben, das Token ist aber nun readonly -> Fehler Ist aber sehr an den Haaren herbeigezogen, aber theoretisch möglich. Das Problem, das bei einem "Absturz" eines Prozesses die Token auf einem falschen Status stehen bleiben, war glaube ich schon im Thread und muss meiner Meinung nach unbedingt berücksichtigt werden. Im übrigen ist die Vergabe von fortlaufenden Nummern ein interessantes Programmierer Problem z.B. Das Vergeben von Kundennummern usw. Vielleicht liest ja ein Informatikstudent mit und kennt einen Theoretischen Ansatz. Bisher gieng ich davon aus, das sich das Problem nur sauber und sicher mit Systemen lösen lässt, die ein Locking integriert haben. (z.B. Datenbanken uä.) MfG Werner