Noch mal zum "Kontext" nachgefragt ... das ist also ein "Minimal-Image", das auf einer Box läuft, wo das Timeout für den System-Start auf sechs Minuten gesetzt wurde? Und die (es ist nicht die von
@JokerGermany, sondern irgendeine andere von jemandem, der das jetzt testen will) stürzt danach dann mit dem Watchdog-Timeout im "untrustedd" ab? Soweit richtig?
Wenn ja - stürzt die denn dann auch erst an dieser Stelle ab, wenn man den Start-Watchdog nicht verlängert? Was passiert, wenn man diese Box jetzt auf die Werkseinstellungen zurücksetzt, damit man sicher sein kann, daß der "untrustedd" nicht wegen irgendwelcher Artefakte in den Einstellungen stirbt? Denn wenn das auch mit den Werkseinstellungen passiert bei einem Freetz-Image, aber bei der originalen Firmware nicht, müßte es ja irgendeine Änderung seitens Freetz(-NG) sein, die das bewirkt.
Ich habe das mit den Watchdog-Handles jetzt mal auf einer 7490 angesehen - der erste Prozess mit einem Handle ist der "supervisor" selbst. Leider kommt nach dem Initialisieren der Systemüberwachung für den Start wohl kein weiteres Handle dazu und man findet die Infos wohl doch nur in der "dmesg"-Ausgabe, wo für den Start etwas wie:
Rich (BBCode):
[ ss.nnnnn] AVM_WATCHDOG: System Init Ueberwachung nnn Sekunden
und für das Ende dann:
Rich (BBCode):
[ ss.nnnnn] AVM_WATCHDOG: System Init Ueberwachung abgeschlossen (nnn s noch verfuegbar)
stehen sollte. Dieser "init"-Watchdog wird wohl doch gesondert im wdt-Treiber behandelt und taucht in der Liste im procfs nicht auf - daher kann man dort auch nicht ermitteln, ob der nun deaktiviert wurde und wann das war. Dazu muß man in die "dmesg"-Ausgabe schauen.
Bei der 7490 war das - nebenbei bemerkt - bei Sekunde 77 vorbei - obwohl der am Beginn auf 240 Sekunden gesetzt wurde (176 Sekunden waren noch übrig). So etwas müßte sich ja (wenn die Box nicht wegen des "init"-Watchdogs abstürzt) auch in der Ausgabe bei der 7590 finden lassen, sofern der "supervisor" sich dazu entschließen kann, den Watchdog zu beenden - ich rate mal, daß das von einem:
Rich (BBCode):
[Supervisor] Info: all Services loaded.
begleitet ist auf "/dev/console". Unmittelbar davor kommt bei mir (wie gesagt, eine 7490 zum Test) noch der Start des "voipkpid.service" - aber selbstverständlich gehen alle möglichen asynchronen Aktivitäten parallel dazu noch weiter (USB-Mounts, WLAN-Suchen, etc.).
Eigentlich passiert ja (in der Theorie zumindest) rein gar nichts von der Freetz-Seite, wenn man den Mod mit dem "emergency off" (ds_off=y) abschaltet ... interessant wäre es halt, ob dann auch der Start-Watchdog (bei kleinerem Wert für das Timeout) beendet wird, nur ist es schwerer, da an die "dmesg"-Ausgabe zu gelangen.
Wobei ich bei diesem "emergency off" ohnehin meine Zweifel habe im Moment (und nicht nur für NG, sondern auch für Freetz) ... ich finde einfach die Stelle nicht, wo jemals die Variable "ds_off" von den "kernel_args" in das Shell-Environment überführt wurde. Denkbar, daß das über den Init-Prozess aus "/proc/cmdline" ins Environment exportiert wird - das muß ich mir erst noch einmal genau ansehen und vor allem auch, ob das beim "supervisor" auch noch so ist (der wird ja seinerseits von "init" gestartet und sollte das damit auch erben).
Aber ich denke, daß ich dabei trotzdem noch ein Problem in NG gefunden habe ... schreibe ich gleich noch ein EDIT zu. Ich will den Teil bisher aber erst mal loswerden.
EDIT: OK, ist doch kein Problem in NG (jedenfalls nicht so, wie gedacht) - mir war doch glatt entgangen, daß Du den "debug.cfg"-Support dauerhaft entsorgt hast für "supervisor"-basierte Versionen und er auch danach nicht mehr angefaßt wurde - das findet sich auch nicht in NEWS, ich habe extra noch einmal nachgesehen. Ich weiß zwar nicht genau, warum Du das machst und dachte zuerst, das wäre nur eine zeitweilige Änderung, bis Du die notwendigen Patches dafür zusammen hast - aber so, wie es jetzt ist, stimmt's dann doch.
Nur daß eben für jemanden, der ein Update von 07.12 auf 07.2x macht, das Feature jetzt eigentlich "silently" abgeschaltet wird, oder irre ich mich da? Wenn ich mit einer 07.12-Konfiguration mit "FREETZ_RESTORE_DEBUG_CFG_SUPPORT=y" ein "make menuconfig" aufrufe und auf 07.2x umstelle, ist der Patch halt "weg" und ich merke nichts davon (außer ich prüfe die Liste sehr, sehr genau), sondern wundere mich hinterher nur, warum meine "debug.cfg" nicht mehr will.
Wie auch immer ... ich würde jetzt bei der Eingrenzung des Watchdog-Problems noch klären, warum der "untrustedd" sich verabschiedet. Wenn das nicht das System von
@JokerGermany ist und er das mit AVM-Firmware nicht macht, muß es ja einen Unterschied geben. Dazu muß aber erst einmal klar sein, daß das - auch auf diesem Gerät und mit einer definierten AVM-Konfiguration, die möglichst kein Mesh o.ä. beinhaltet - mit der AVM-Firmware nicht auch passiert.
Es sind offenbar zwei Probleme, die sich halt in demselben Verhalten zeigen ... einmal schlägt der Start-Watchdog zu, wenn die Freetz-Initialisierung erfolgt und das sollte sich eben vom "supervisor" irgendwie entkoppeln lassen - notfalls auch durch komplett andere Änderungen, wo dann eben die "rc.mod" nicht per "dot command" eingelesen, sondern als gesonderte und "detached" Instanz gestartet wird. Denn ohne Freetz ist da ja auch bei der 7590 wohl noch massig Zeit übrig, wenn der Watchdog abgeschaltet wird in der originalen Firmware.
Das zweite Problem ist unter bestimmten, noch unklaren Umständen dann der "untrustedd" ... auch dessen Watchdog schlägt irgendwie zu, wenn er die Chance dazu erhält (und das System nicht schon vorher neu gestartet wurde vom Start-Watchdog). Hier wäre die Frage, warum er das macht und ob man das (als alternativen Workaround, der nicht gleich alle anderen Watchdogs auch killt) einfach auch verhindern kann, wenn man den gar nicht erst starten läßt oder ihn (vor dem Watchdog) wieder beendet. Die Frage wäre halt, welche Funktion man damit verliert ... ich habe den bisher noch nie wirklich in Aktion erlebt, was mich eben zu der Vermutung brachte, daß der irgendetwas mit dem Mesh zu tun haben müßte, was bei mir nicht genutzt wird. Daher auch die Bedingung oben, daß für weitere Tests erst mal kein Mesh aktiv sein sollte ... klappt das auch schon nicht und macht sich da schon das Fehlen des "untrustedd" bemerkbar (weil er gar nicht gestartet wurde oder schon wieder beendet ist), ist meine Theorie mit dem Zusammenhang zwischen Mesh und "untrustedd" auch hinfällig.
EDIT2:
Ja, der "init-start"-Watchdog ist tatsächlich gesondert behandelt (aus drivers/char/avm_new/include/avm/watchdog/watchdog.h):
Code:
7 #define MAX_WDT_APPLS 63 /*--- letzte Position ist fuer init-Ueberwachung reserviert ---*/
- da wird also der letzte Eintrag in der Tabelle genutzt (das wäre dann Nr. 64 - der wird über "array[MAX_WDT_APPLS] adressiert) und bei der Anzeige über "/proc/avm/wdt" wird nur bis "< MAX_WDT_APPLS" iteriert:
Code:
1023 for (idx = 0; idx < MAX_WDT_APPLS; idx++) {
