"Universel", bedeutet, dass die Pseudoflash mit MIPS/MIPSEL und DualBoot und auch mit EoS/EoL Boxen zusammenarbeitet.
Nö ...
Das meint (nach meiner Lesart) nur, daß es das eine - von mir als Idee beschriebene - Image gibt, welches mehrere Funktionen erfüllen kann. Dabei spielt die Frage LE vs. BE, NAND-Flash ja/nein, usw. nur dann ein Rolle, wenn es darum geht, ob eine bestimmte Funktion überhaupt Sinn ergibt. Das sind auch keine endlosen Ketten von Abfragen (die CONFIG-Variablen sind auch schon vorhanden) und warum willst Du Dir über Firmware vor 06.30 überhaupt Gedanken machen? Die kann doch problemlos noch auf den Telnet-Daemon "out of the box" zurückgreifen.
Solange das alles nur Skript- und HTML-"Code" ist, was da zum Einsatz kommt (selbst Lua ginge ja noch), ist das alles von sich aus universell ... bei Binärdateien sieht es dann schon wieder anders aus, obwohl auch da problemlos eine Symlink-Liste für das jeweilige Modell (das muß ja kein einzelner alles testen) auf "shared binaries" ausreichen würde und man dann eben LE- und BE-Binaries in das Image mit hineinpacken und nur das richtige anhand von Boxtyp oder HWRevision auswählen könnte (habe ich in modfs auch so angelegt, bisher bloß noch nie wirklich gebraucht, weil die veröffentlichte Version ja NOR-Boxen nicht unterstützt).
Aber selbst wenn man das "nur" für ein bestimmtes Modell macht ... schon die Suche nach der richtigen Befehlsfolge für ein bestimmtes Problem und Modell setzt derzeit der Anwendung dieser Pseudo-Images eine recht deutliche Grenze, da es keine "zentrale Stelle" gibt und die Angaben in WHMF sind an dieser Stelle nun wirklich Asbach.
BTW: Hast Du mal den Unterschied zwischen "killall" und "kill" mit einem Trace untersucht? Irgendwie fehlt mir da "der Schlußpunkt" in dieser Diskussion, auch wenn ich sie nicht unbedingt unterhalb von "LCR" führen würde. Wenn das Abschalten der aktiven Watchdog-Timer notwendig sein sollte, kann man das ja problemlos schon vor dem "Wiedererwecken" der anderen Dienste machen, dann sollte ein watchdog-basierter Neustart seitens der firmwarecfg-Instanz ja auch erledigt sein. Da ich bei mir ja keine weiteren Services starten will (s. #46), habe ich das "disable" für aktive Watchdogs tatsächlich auch noch einmal nach dem "prepare_fwupgrade" von AVM in meinen Skripten an anderer Stelle drin, gut möglich, daß das tatsächlich ein entscheidender Unterschied ist.
Andererseits wird das vom "install"-Skript von AVM auch erst in "post_install" erledigt, unmittelbar vor dem Flashen einer neuen Version. Wenn dann aus irgendeinem Grund die davor in der "post_install"-Datei stehenden Aktionen (das install-Skript hängt seine Sachen dort ja nur an) mal etwas länger dauern sollten, schlägt wohl auch das Update fehl, wenn das über einen Watchdog läuft.
Nun gut, die "dismounts" sind bei lokalem Update tatsächlich schon durch, aber beileibe nicht in jedem anderen Update-Verlauf ebenfalls, das "USB-Stoppen" ist optional in "prepare_fwupgrade" und so ein Herunterfahren kann sich auch bei hängenden AVM-Daemons zäh gestalten, meiner Erinnerung nach wird da von termforcewait (oder wie das heißt) bis zu 999 Sekunden gewartet bei einigen Diensten.
Vielleicht ist also der entscheidende Punkt weniger das "kill" für den "delayed reboot process", sondern eher das Löschen eines weiteren Watchdogs. Der kann dann ja nur nach dem Löschen in "prepare_fwupgrade" erneut aufgesetzt worden sein, wäre aber ebenfalls eine plausible Erklärung ... eigentlich sogar die plausiblere. Wobei dann die Frage nach dem Signal beim "kill" immer noch bleibt ... auch ein "killall" mit "SIGTERM" anstelle von "SIGKILL" dürfte dann nichts helfen. Wenn das "normale kill" des Prozesses den Watchdog auch nicht abräumt, warum sollte es dann ein "killall" machen? Das ist auch nichts anderes als ein "kill" anhand des Prozessnamens anstelle der PID, ansonsten sind die weitgehend identisch. Nur kann eben beim "normalen kill" kein Name doppelt auftreten (ist ja die PID), bei einem "killall" eben schon.
Wenn es am Ende tatsächlich bei der 7360SL so sein sollte, wie Du es nach dem Test annimmst, stünde ja in der PID-Datei offenbar der falsche Prozess. Das ist zwar sicherlich auch nicht vollkommen auszuschließen, aber ich würde sogar tippen (und den AVM-Programmierern solche Überlegungen auch unterstellen), daß da anhand der Datei delayed_reboot.pid entschieden wird, ob nicht schon ein anderer Prozess auf ein solches Timeout wartet und man selbst (also die eigene Instanz) das gar nicht noch einmal gesondert tun muß (oder man den ggf. dort wartenden Prozess sogar killt, bevor man selbst ein solches Timeout initiiert). Das ließe sich ja durch ein einfaches "echo $$ >/var/run/delayed_reboot.pid" vor dem Upload eines Images (natürlich auf einer Box mit einem anderen Zugang) problemlos testen, ob das vielleicht tatsächlich so gemacht wird. Steht hinterher in der Datei immer noch die originale PID, wird das wohl getestet von firmwarecfg. Macht auch in gewisser Weise Sinn, ansonsten könnte man ja mit ständigen weiteren Requests für firmwarecfg, die rechtzeitig innerhalb der Timeout-Spanne erfolgen, den Reboot-Zeitpunkt immer weiter hinausschieben.
Ich habe bloß im Moment weder Zeit noch Muße für eigene Tests an dieser Stelle ... daher auch nur Kommentare/Meinungen von mir dazu und keine eigenen systematischen Ergebnisse auf der Basis aktueller Firmware. Alles was ich dazu hier herumliegen habe, basiert auf älterer Firmware, im günstigsten Falle auf 06.20 für 7390/7490 und ist max. aus dem Okt. 2014 - auch die Infos, was da von wem abhängt und wie man dieses "prepare_fwupgrade" wieder "rückgängig" machen kann durch das gezielte Starten von Diensten, stammen eigentlich alle aus diesem Zeitraum ... das muß also für aktuelle Firmware nicht mehr alles gelten.
