dass man nicht alle Änderungen auf einmal testet.
Man sollte sich aber zuvor vergewissern, daß die Änderungen auch tatsächlich - wie geplant - ausgeführt wurden und gewirkt haben.
Deshalb habe ich ja noch die Aufforderung nachgeschoben, diverse Protokolle zu sichern, damit man nachsehen kann, was da jeweils angeworfen wurde und wie weit das kam. Von Deinem ersten Versuch mit den von mir vorgeschlagenen Änderungen wissen wir bisher ja auch nur, daß die Box offenbar erneut abgestürzt ist, weil wohl das "init-done" nicht vom "supervisor" kam.
Hilfreicher wäre es aber zu wissen, was der in der Zwischenzeit alles gestartet hat, wie die Abhängigkeiten der Services NACH dem Patch aussehen (das Kommando dazu hatte ich weiter oben verlinkt) und welche Services er gestartet hat, die sich jetzt in welchem Zustand befinden (auch das steht weiter oben als Kommando zur Abfrage).
Für den erwähnten Versuch ist nicht einmal - sicher - bekannt, ob dabei der "rcmod.service" überhaupt gestartet wurde oder ob nicht vielleicht der "supervisor" diese (unabhängigen) Services erst mal in eine Warteschlange einreiht, deren Abarbeitung erst dann begonnen wird, wenn der derzeit angeordnete "Zustand" (auch das "multi-user.target" für die Abhängigkeiten der Dienste, die vor dem "init-done" gestartet sein müssen, ist ja nur eine Annahme) erreicht wurde. Das wäre auch nicht absolut ungewöhnlich ... irgendwie muß der "supervisor" ja (wie der "systemd" auch) die Transitions serialisieren, weil das System ja nicht gleichzeitig in zwei Zuständen sein kann bzw. nicht gleichzeitig versuchen kann, zwei (verschiedene) Zustände einzunehmen.
Daß der Start aus der "tail" heraus nur die erste Idee war und man ggf. nach einem besseren Platz dafür suchen müßte, wenn das so nicht funktionieren sollte, hatte ich (iirc) schon weiter vorne geschrieben - ebenso, daß man natürlich auch einfach zwischen "rcmod.service" und "999-zzz-rcmod" noch ein weiteres Skript einbauen kann, das dann die "rc.mod" vom Service entkoppelt - dann kann man den auch wieder zum Bestandteil von "multi-user.target" machen. Denn daß so etwas prinzipiell auch möglich ist und funktioniert, zeigt ja meine Umsetzung für die "rc.user" in "modfs", die m.W. auch für GRX-Boxen (konkret auch die 7590) funktioniert und nicht zum Absturz der Box führt, auch wenn man die Watchdogs nicht anfaßt.
Das Sichern der ganzen Protokolldaten bringt auch nicht wirklich etwas, wenn man das "von Hand" machen will ... das kann man problemlos skripten und dann läuft es garantiert auch viel flüssiger und schafft es, mehr Daten vor dem Neustart zu sichern - bis hin zu eingestreuten "sync"-Aufrufen, damit Buffer in den Flash-Speicher geschrieben werden. Es bringt jedenfalls nichts, eine Idee zu verwerfen, wenn man sich nicht zuvor davon überzeugt hat, daß man sie auch fehlerfrei und wie geplant umgesetzt hat und sie dann nicht den gewünschten Erfolg erzielte.
Zumal ja das Verlängern des Timeouts nun nicht so "unübersichtlich" ist als Änderung, daß davon irgendwelche negativen Auswirkungen auf anderes zu erwarten wären (und man das schon als "something completely different" werten müßte, was man nicht mit anderem vermischen sollte) ... im schlechtesten Falle erfolgt der Neustart wegen des abgelaufenen Systemstart-Watchdogs dann eben erst später. Wenn der (rechtzeitig) vom "supervisor" korrekt abgeschaltet wird, ist es auch egal, wieviel Restlaufzeit der noch hatte.
Wenn Du es für andere ordentlich nachvollziehbar machen willst, schreibst Du auch selbst bei jedem neuen Versuch genau dazu, welche Änderungen (bis hin zur Deaktivierung des Watchdog-Patches) da jeweils vorgenommen wurden - dann muß man nicht erst raten oder nachfragen, was dabei - ggü. dem Stand aus dem Repo - geändert wurde.
@cuma:
Ich würde zwar die Zeit bis zum Timeout etwas verlängern, aber nur zum Testen und parallel trotzdem danach suchen, warum der Watchdog nicht sauber abgeschaltet wird. Denn daß der "supervisor" selbst dabei nicht auf das Internet wartet, ist auch klar ... sonst würde ja eine DSL-Störung zu einer ständigen Reboot-Schleife führen.
Da muß es also schon vorher eine Bedingung im "supervisor" geben (der importiert jedenfalls die Funktion "watchdog_init_done" aus der "libwdt.so"), die ihn dazu veranlaßt, den Watchdog auch lange vor dem Ablauf der Zeit (bei anderen waren noch 78 Sekunden übrig) zu deaktivieren und das nur unter Freetz-Bedingungen zu verzögern, denn (noch mal) mein eigener zusätzlicher Service für die "rc.user" (aus "modfs") funktioniert ja auch, ohne daß der "supervisor" da irritiert wird und dessen Service-Einstellungen sehen auch so aus, wie die für "rcmod.service".
Nur die Arbeitsweise in der von dort aufgerufenen Shell-Datei unterscheidet sich eben deutlich ... zuvor hatte ich das auch über "delay" entkoppelt, nur haut dann ein Neustart des "multid" (der u.U. von der AVM-Firmware beim "online" ausgelöst werden kann) auch ins Kontor, weil sich der "multid" keinen der Aufträge merkt, die er per "delaystart" als IPC-Kommando erhalten hat, wenn er neu gestartet wird. Danach habe ich das auf "nohup" umgestellt und auch das funktioniert (soweit ich das gehört habe und einige haben sich wohl auch eine 7590 so modifiziert, wobei ich natürlich jeweils nicht die Hand dafür ins Feuer legen kann, daß die auch alle das entsprechende "modscript" benutzen).
Da es sich hier ja um ein Timing-Problem handelt (der "supervisor" muß vor dem Ablauf des Watchdogs zu der Überzeugung kommen, daß der Start abgeschlossen ist), muß man eben versuchen, das "blockierende Element" zu isolieren und aller Wahrscheinlichkeit nach liegt das nun mal in einer Änderung durch Freetz(-NG), weil die originale Firmware ja auch funktioniert. Da liegt es - am Beginn - für mich nun mal am Nächsten, daß man versucht, den Start der ganzen Freetz-Pakete vom Start des FRITZ!OS zu entkoppeln ... das war (spätestens bei der "rc.custom" oder der "debug.cfg"/"rc.user") aber schon immer mein Credo, weil ansonsten falsche Einträge in diesen Dateien (oder falsches Vorgehen) das gesamte System beinträchtigen können (also der Freetz-Benutzer sich das System damit - sehr leicht - zerschießen kann) - beim Start über "rc.S" wurde dann eben der Startvorgang von "init" nie wirklich beendet, weil er immer noch irgendwo in der "debug.cfg" festhing.
Genau für die Feststellung, in welchen Zustand sich der "supervisor" denn jeweils gerade befindet, muß man eben die Abhängigkeiten der Services ermitteln (das reicht einmalig) und den aktuellen Zustand dieser Service-Units - das aber (zumindest bei der Fehlersuche) so häufig wie möglich. Dann kann man daraus schließen, wo er zu diesem Zeitpunkt gerade ist und welcher Service da wohl auf welchen wartet, damit es weitergehen kann und irgendwann doch noch das "init-done" abgesetzt wird. Nachdem das erwähnte "watchdog_init_done" auch von keinem anderen Binary importiert wird (sagt jedenfalls mein "grep"), kann es eigentlich auch nur dieser Prozess sein, der dafür zuständig wäre, den Watchdog wieder abzuschalten.
