[Trunk #3318-24] Neues & Änderungen bei den Konfiguartionsdateien von Freetz

[cuma]

@olistudent: Kannst du mal schauen was nslookup ausgibt bei deiner Konfiguration mit der 127.0.0.1?

 

[er13]

vor dem Update MOD_LIMIT etwas erhöhen

Weiß nicht zurecht wohin mit dem folgenden... vielleicht in FAQ?

Die Änderung aus #3318 oder um genauer zu sein die Tatsache, dass einige Dateien statt direkt unter /tmp/flash jetzt in Unterverzeichnissen abgelegt werden, hat einen Nebeneffekt - /var/flash/freetz wird dadurch größer (weil eben diese Pfade mit abgespeichert werden müssen). Beim Booten der Box wird /var/flash/freetz abgespeichert - zumindest bei mir, denn es erscheint "Writing /var/flash/freetz..." (übrigens von wo genau erfolgt der Aufruf und wozu?). Nun scheitert dieser Versuch, so wird rc.mod nicht zu Ende oder sogar gar nicht ausgeführt, was eben zur Folge hat, dass das freetz-Webinterface und andere mod-Dienste nicht erreichbar sind, weil sie ja gar nicht gestartet wurden.

Dies ist meine Analyse des Problems... Habe heute etwas leidvolle und vorallem zeitraubende Erfahrung machen müssen, dass nach einem Update von einer vor-3318-Revision auf eine danach zwar die freetz-Firmware drauf war (AVM-Interface war erreichbar) aber eben kein freetz-Interface und auch keine Dienste liefen, ein Reboot änderte nichts. Habe dann per Telnet rc.mod gestartet und das mit dem überschrittenen Limit gesehen. Hochgesetzt, rebootet - alles geht wieder.

Moral der Geschichte: für all diejenigen, bei denen die aktuelle Größe von /var/flash/freetz knapp am eingestellten Limit liegt, empfiehlt es sich, das Limit vor dem Update etwas hochzustellen (oder, wenn es eh schon hoch ist, durch andere Maßnahmen dafür zu sorgen, dass /var/flash/freetz wieder etwas kleiner wird).

@an den, der sich auskennt: kann man /var/flash/freetz irgendwie anders abspeichern, komprimiert wurde schon mal vorgeschlagen (auch wenn das flash-Dateisystem es auch noch macht) oder vielleicht tar dazu bringen, dass es weniger pad-zeros hinzufügt.. Oder ist vielleicht nur die Prüfung in /usr/bin/modsave nicht ganz korrekt, man soll in /tmp zusätzlich noch die komprimierte Version erstellen und wenn diese eine bestimmte Größe nicht überschreitet, dass ist doch noch alles ok. Gespeichert soll dabei weiterhin die nicht komprimierte Version.

 

[cuma]

Wird es wirklich soviel größer? Es sind doch maximal nur 6 Dateien bei denen das "/mod" eingefügt wird und damit maximal 24 Bytes. Das TFFS komprimiert selbst, die Daten noch zu packen bringt also nichts (ich hatte selbst mal einen Patch dafür gemacht). Es passen wesentlich mehr Dateien ins TFFS wie momentan per default eingestellt ist. Das ist aber zur Sicherheit so, falls jemand Binarys oä dorthin kopiert. An Konfig-Text die sehr gut komprimierbar sind, düfte also sehr viel hinenpassen.
Weshalb bootet die Box eigentlich nicht, die Daten müssen doch nur geladen werden

 

[olistudent]

Es wird wohl irgendwo ein "modsave flash" ausgeführt.

MfG Oliver

 

[cuma]

Soweit schon klar. Dieses modsave wird dann wohl fehlschlagen. Aber dass dadurch das Booten unterbrochen wird?

 

[er13]

Wird es wirklich soviel größer?

Habe jetzt etwas getestet. Das Anlegen eines neuen Unterverzeichnisses oder einer neuen leeren Datei unter /tmp/flash erhöht die Größe von /var/flash/freetz um genau 512 bytes - ein Block, der wohl irgendeine Untermenge von inode enthalten wird (i.e. Name, Dateityp, Owner, Rechte usw). Das Anlegen einer neuen nicht-leeren Datei erhöht die Größe um mindestens 1024 bytes - die Blöcke ab dem zweiten werden wohl der Inhalt der Datei sein. Der inode-Block und der letzte Inhalt-Block sind am Ende mit Nullen aufgefüllt, d.h. bei einer großen Menge kleinerer Dateien (wie das bei freetz unter /tmp/flash der Fall ist) wird sich die tar-Datei gut komprimieren lassen.

p.s. Wenn ich mir jetzt 3318 anschaue, dann waren es bei mir mindestens drei neue Untervezeichnisse (mod, dnsmasq und privoxy), also mindestens 1,5kB, die wohl ausgereicht haben.

 

[er13]

Es wird wohl irgendwo ein "modsave flash" ausgeführt.

hab' glaube ich die Stelle gefunden. Aus rc.mod wird rc.inetd aufgerufen (inetd kommt in static.pkg vor), in der config-Funktion von diesem wird parameterlos /usr/bin/modinetd aufgerufen und in diesem wird am Ende wofür auch immer ein "modsave flash" ausgeführt. Es wird glaube ich die inetd.conf aktualisiert, ob man sie beim Booten gleich zurückschreiben soll, ist halt die Frage.

Das Phänomen, dass rc.mod nach einem gescheiterten "modsave flash" nicht zu Ende ausfegührt wird, kann ich mir übrigens auch nicht erklären. Es ist aber definitiv der Fall, dass das Hochsetzen des Limits alles wieder in Ordnung brachte.

 

[cuma]

An die anderen Verzeichnisse hab ich garnicht gedacht. Vielleicht sollte man das Limit per default höher stellen?