Hingegen die fehlenden Zeilen in der rc.tail.sh
Code:
if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then
mknod /var/flash/debug.cfg c $tffs_major $((0x62))
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then
. /var/flash/debug.cfg
fi
fi
schon.
Wenn man das einfach auseinandernimmt, kommt eigentlich ein ähnliches Ergebnis dabei heraus. Nur daß AVM eben die zusätzlichen Kommandos dann schon an der Stelle in den Startprozess "einbaut", wo das .-Kommando steht. Das liest an dieser Stelle dann die Kommandos aus der angegebenen Datei ein und führt sie aus. Dabei erwartet es aber auch, daß beim Erreichen des Endes der Datei die danach im ursprünglichen Skript noch aufgeführten Kommandos weiter abgearbeitet werden. Kommt jetzt die Verarbeitung in der "debug.cfg" z.B. nicht zu einem Ende (weil dort jemand eine Schleife eingebaut hat in Unkenntnis der Rahmenbedingungen) oder wird dort gar mit "exit" beendet (das gilt dann eben auch für die rc.tail.sh genau an der Stelle, wo es auftriit), werden die danach stehenden Kommandos nicht mehr ausgeführt.
Das führt dann in solchen Fällen gerne mal zu einem Energieverbrauch von 0% in der Anzeige als auffälligstes Merkmal.
Und wenn Du den Hintergrund des mknod-Kommandos und die mathematische Gleichheit von 98 und 0x62 verstanden hast (ein kurzer Blick in /bin/mkconfigfile bringt genau wieder das mknod zum Vorschein), dann solltest Du die Zeile
Code:
rcuser=/var/tmp/rc.user;mkconfigfile $rcuser.tffs 98;! checkempty $rcuser.tffs && cat $rcuser.tffs >$rcuser && delay -d 1 USER "/bin/sh $rcuser";rm $rcuser.tffs
auch auseinandernehmen können. Um nicht ständig aufs Neue das "/var/tmp/rc.user" schreiben zu müssen, landet das erst einmal in der Variablen "rcuser". Anschließend wird - genau wie bei AVM - das char-Device für Node 98 (oder hex 62) angelegt und dann geprüft, ob da etwas drin steht.
Der Unterschied ist, ich lege dieses char-Device nicht in /var/flash an (das hat seinen Grund, da bei der 7490 dort ein permanenter Speicher liegt (persistente Speicherung in /dev/mtdblock4), anders als bei so ziemlich jedem anderen Modell), sondern definitiv nur im RAM der Box. Und zwar als /var/tmp/rc.user.tffs, aber das sieht man wegen der Verwendung von $rcuser an dieser Stelle nicht so klar. Dafür könnte man die Datei dann aber auch ganz einfach anders nennen, indem man nur an einer einzigen Stelle am Anfang der Zeile anpasst, z.B. auf rcuser=/var/flash/debug.cfg. Dann heißt die Datei am Ende wieder so wie bei AVM, liegt aber an einer anderen Stelle und in einer anderen Art von Speicher.
Während AVM das char-Device dann direkt liest (das Punkt-Kommando liest die Datei Zeile für Zeile ein), kopiere ich den Inhalt auf einen Schlag in eine weitere Datei im RAM (/var/tmp/rc.user) und lasse dann von der AVM-Firmware 1 Sekunde später die Abarbeitung der Kommandos in dieser Datei /var/tmp/rc.user mit dem Kommando "/bin/sh /var/tmp/rc.user" starten. Dann fliegt noch das char-Device weg, denn das ist nutzlos und nichts weiter als die "Adresse" der Kommandos im Flash-Speicher der Box - ich verwende absichtlich nicht die Bezeichnung "debug.cfg", da die da einfach nicht dabei steht und man den Text dort nennen kann, wie man will. Und so wie man eine solche Adresse auf ein beliebiges Stück Papier schreiben kann, das man dann wieder verbrennt, so kann man diese char-Devices auch an einer beliebigen (beschreibbaren, das ist die einzige Einschränkung) Stelle im Dateisystem erzeugen und wieder löschen, ohne das das irgendwelche Auswirkungen auf den Inhalt hätte.
Und um das
Löschen des Inhalts dieser - nennen wir sie mal "Datei" - zu verhindern (normalerweise kein Problem mit "echo -n >dateiname" - das schreibt einen neuen Inhalt mit genau 0 Byte Länge in dieses char-Device), will ich
vorsichtshalber kein solches Device haben. An das Anlegen des char-Devices, das Schreiben eines leeren Inhalts und das anschließende Löschen des char-Devices "aus Versehen" glaube ich nicht, das wäre dann Absicht und auch nicht zu verhindern.
Bei einer Schleife in der "debug.cfg" kommt dann ja auch der eigentliche init-Prozess (das ist der Start des Systems) nie zu einem definierten Abschluß. Daß das auf einer FRITZ!Box eher nicht auffällt, liegt nur an der ohnehin nicht vorhandenen Multiuser-Fähigkeit (das mit den Rechten beim FTP/Samba ist nur eine Krücke), ist aber letzten Endes eine "unsaubere" Aktion.
Wenn man direkt aus der debug.cfg heraus Prozesse starten will, die eigentlich keine Daemons sind (sich also nicht selbst von ihrem Erzeugerprozess "abkoppeln"), muß man durch zusätzliche Maßnahmen dafür sorgen, daß diese Prozesse nicht beim Beenden ihres Elternprozesses mit "abgeschossen" werden.
Diesen beiden potentiellen Problemen gehe ich mit der Art und Weise des Starts der Kommandos in der rc.user (da steht genau dasselbe drin, wie in der debug.cfg, nur ein anderer Name weil das eben keine "einfache" Datei ist) aus dem Weg, indem ich sie einfach von einer AVM-Basiskomponente im Auftrag starten lasse (so eine Art Job-Control, falls Dir das was sagt).
Ansonsten ist es ziemlich 1:1 dasselbe, was bei AVM auch drin steht.
Der eigentlich Witz an der Sache ist doch aber, daß die Idee mit dieser Datei im Flash meines Wissens schon aus der Zeit der ersten Boxen mit einem AR7-Chip und der entsprechenden Referenzimplementierung von Texas Instruments stammt. Dort hieß die Datei aber eben "rc.user" und es gab/gibt sogar noch eine zweite Datei (der Name ist etwas Legende, ich habe schon "rc.user.additional" gelesen), die für zusätzliche Daten (z.B. irgendwelche Konfigurationseinstellungen o.ä.) verwendet wurde. Diese beiden Dateien haben auch Minor-IDs (das ist die 98 (0x62) für die "debug.cfg/rc.user" und die 97 für die zweite Datei), die kleiner als 100 sind und sämtliche dieser "Knoten" (Nodes) oder Minor-IDs, auf die diese Bedingung zutrifft (als < 100), werden auch beim Zurücksetzen der Box auf Werkseinstellungen nicht gelöscht. Beim Werksreset werden nämlich nur die Nodes von 100 bis 255 (und noch einige mit spezieller Bedeutung und höheren Nummern) mit "leer" überschrieben. Lediglich bei der Benutzung des Recovery-Programms (oder auch des ruKT) werden auch die Daten in den Nodes < 100 gelöscht, da dabei einfach der gesamte Flashspeicher gelöscht wird und die Strukturen anschließend neu erstellt werden.
Die Fixierung auf eine "debug.cfg" und sogar auf den TFFS-Node 98, der sich bei AVM dahinter verbirgt, ist also eigentlich ein vollkommenes Mißverständnis. Wenn ich lieber eine solche "Datei" haben möchte, die bei Werksreset auch gelöscht wird, muß ich mir nur eine "freie Nummer" oberhalb von 100 suchen (ab 192 (0xC0) sind m.W. zur Zeit 9 Nummern unbenutzt, da lagen mal die Plugins bei der 7050 und der 7170, wenn ich mich recht erinnere). Dann kann ich auch eine "amoklaufende" Kommandofolge, die mir die Box immer wieder abschießt, bevor ich eingreifen kann, einfach durch einen Werksreset entsorgen. Das hat auch etwas für sich, genauso wie das "Überleben" des Inhalts. Es hängt eben davon ab, was man damit machen will. Auch für das Überleben des Inhalts sind diverse Nummern "unbenutzt", auch wenn die char-Devices da teilweise angelegt werden. Der Inhalt wird ignoriert und wer ein kleines tar-File in einem dieser Nodes unterbringt, der hat schon in der Box (und zwar nicht nur in der 7490) einen kleinen "privaten" Speicherbereich, in dem man so einiges unterbringen kann. Der TFFS-Speicher ist zwar bei den meisten Modellen nicht üppig, aber für selten geänderte Daten geht das schon (Freetz macht ja auch nichts anders mit seinen Einstellungen).
Was man dann in die Init-Files einbaut zum Auslesen des Inhalts dieser Nodes, bleibt einem ja selbst überlassen. Und wer ganz auf Nummer sicher gehen will, daß nicht AVM doch irgendwann mal eine Sequenz zum "Löschen" des Inhalts der "debug.cfg" einbaut, der nimmt eben die Minor-ID 97 anstelle der 98 und läßt dann die dort hinterlegten Kommandos abarbeiten.
Ohnehin ist die Stelle am Ende des Init-Prozesses (je nachdem, was man eigentlich machen will) nicht immer die günstigste Möglichkeit zum Starten eigener Skripte. Wenn ich einen Dienst habe, der auf irgendwelche "Vorleistungen" angewiesen ist (und sei es nur eine korrekt gesetzte Uhrzeit wie bei einem crond), dann macht der in vielen Fällen erst dann Sinn, wenn die Box wenigstens einmal Kontakt mit einem Zeitserver aufgenommen hatte (dafür braucht sie eine funktionierende Internetverbindung in den meisten Fällen) und ihre interne Echtzeituhr von 1970 (da startet die Box ihre Zeitzählung beim Booten) auf ein halbwegs plausibles Datum und eine sinnvolle Uhrzeit gesetzt wurde. Ich habe schon jede Menge Skript-Code gesehen, der den Start solcher Dienste auf allen erdenklichen Wegen verzögern sollte, bis die Rahmenbedingungen stimmen. Das kann man natürlich alles vermeiden, wenn man sich gleich an den richtigen Stellen in das System "einklinkt". Ein Skript, das erst endlos Schleifen dreht, bis endlich der USB-Speicher gemountet ist, wäre eben unmittelbar nach dem Mounten des entsprechenden Volumes besser aufgehoben. Und wenn man ohnehin das AVM-System verändern muß, kann man es auch gleich richtig machen ... das war zu Zeiten der debug.cfg sicherlich noch etwas anderes, weil man eben nicht das System ändern mußte. Heute sollte es m.E: nur noch zur einfachen Wiederaufnahme bisher klaglos funktionierender Funktionen dienen, wenn man die debug.cfg wieder aktiviert. Für neue Entwicklungen macht eine genauere Überlegung, wo man sie einbindet, meiner Meinung nach mehr Sinn. Schon der udevd bietet da viele bessere Lösungen ...
Sch..., schon wieder so lang. Wenn ich erst einmal bei Schreiben bin, kriege ich das immer gar nicht so richtig mit. Shame on me ...
