Defect #193
Neustart des TFTP nach slxconfig-demuxer notwendig
| Status: | Erledigt | Start date: | ||
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | zooey | % Done: | 0% |
|
| Category: | konzept | |||
| Target version: | Visionen ;) | |||
| Resolution: | fixed |
Description
In vielen Fällen scheint es unumgänglich zu sein, dass der TFTP (z.B. tftp-hpa unter Ubuntu) neu gestartet werden muss (nach einem vollständigen Lauf des slxconfig-demuxer), da er sonst nicht damit klarkommt, dass das Verzeichnis neu aufgebaut wurde. Der hockt dann wohl noch fest auf einem Filehandle, der schon weg ist. Wird eigentlich schon die oberste Verzeichnisebene, was sein TFTP-Root ist gelöscht/neu geschrieben!?
History
Updated by uhrig almost 4 years ago
Work around: atftpd (ubuntu, debian)
- aptitude install atftpd
- ln -s /srv/openslx/tftpboot /tftpboot
Updated by dvs almost 4 years ago
Hm, ich weiß nicht, ob das mit unserem Problem zu tun hat. Es sollte u.U. reichen, wenn wir das oberste Verzeichnis tftpboot/ nicht wegschmeißen und neu anlegen!? Es sollte ja immer genauso heißen!?
Updated by zooey almost 4 years ago
- Status changed from Neu to Erledigt
- Resolution set to fixed
Dieses Problem sollte nun behoben sein, da der config-demuxer nun das Verzeichnis tftpboot nicht mehr ersetzt, sondern nur noch dessen Inhalt.
Dies geschieht jetzt übrigens mit einer Art trivialem Staging Konzept (auf Basis von rsync), so dass der demuxer erst alle Dateien in neuen temporären Verzechnissen erstellt, und nur im Erfolgsfall diese Verzeichnisse in tftpboot hineinkippt.
Es bleiben natürlich theoretisch noch immer Race-Conditions möglich, wenn während des Laufes vom config-demuxer Clients booten, aber die aktuelle Strategie sollte schon recht weit reichen, denke ich.
Wenn irgend jemand weiß, wie man unter Unix ein Verzeichnis atomar durch ein neues ersetzt - bitte melden! ;-)
Updated by lmuelle almost 4 years ago
Könntest Du das per 'mv' statt rsync erreichen?
Erst das alte Dir per mv wegsichern und dann nur im Erfolgsfall per mv das neue an die Stelle verschieben.
Updated by zooey almost 4 years ago
Nein, 'mv' ist eben genau nicht atomar, leider. D.h. man würde zuerst das ganze Verzeichnis wegziehen und dann das neue hinzufügen, dabei gibt es dann aber eine kurze Zeitspanne, in der das Verzeichnis gar nicht mehr existiert.
Da ist dann IMHO das rsync-Verfahren besser, denn dieses überschreibt nur die Dateien, so dass die Race-Condition immer nur einzelne Dateien betrifft (soll heißen: der Client liest entweder die alte oder die neue Version einer Datei, er kriegt aber niemals die Fehlermeldung, dass eine Datei nicht existiert).
Updated by lmuelle almost 4 years ago
Zwar ist mv nicht atomar jedoch minimiert die bedingte Ausführung des zweiten mv das Risiko einer Inkonsistenz. Hinzu kommt jedoch das Fehlerrisiko durch eine volle Platte.
Bei dem Ansatz per rsync hat man für jede Datei die Übertragung in eine temporäre Datei plus die Umbenennung in das Ziel. Somit ist man hier dem initial beschriebenen Risiko mehrfach ausgesetzt.
Updated by zooey almost 4 years ago
Es ist zwar korrekt, dass bei einem 'mv' der Zeitraum, in der die Race-Condition existiert kürzer ist als bei dem Rsync-Ansatz, aber dafür sind eben alle einzelnen Operationen, die rsync durchführt, atomar. Dadurch kann es eben niemals dazu kommen, dass eine Datei gar nicht geöffnet werden kann. Der Client bekommt immer entweder die neue oder die alter Version einer Datei.
Andererseits besteht natürlich bei rsync erhöht die Gefahr, dass der Client inkompatible Stände bekommt (weil er z.B. die alte Version eines Kernels und die neue Version der initrd lädt). Aber das Problem besteht ja grundsätzlich bei beiden Lösungen. Dagegen würde nur helfen, den tftpd temporär zu stoppen und nach dem demuxen neu zu starten, aber das könnte wiederum dann unschön sein, wenn der noch andere Aufgaben hat, als nur OpenSLX zu bedienen (aber wie wahrscheinlich ist das?).
Updated by lmuelle almost 4 years ago
In der Theorie besteht die Race-Condition. In der Praxis wird die Ausführungszeit der beiden kombinierten mv-Aufrufe im Bruchteil einer Sekunde bewegen.
Aufgrund des relativ hohen Rechenaufwands dürfte rsync selbst für eine Datei länger benötigen als die beiden mv-Aufrufe.