-
Fortsetzung von #959 Der ctlmgr crashte nicht mit libctlmgr weil die lib nicht im Suchpfad lag :] Avm verwendet für den ctlmgr libs in /usr/share/ctlmgr/ . Probier es nochmal nach
Ob die lib wirklich geladen ist kann man prüfen mit: "cat /proc/$(pidof ctlmgr)/maps | grep ctlmgr" Ein typischer Crash
PS: "ldd /usr/share/ctlmgr/libfon.so" o_o Zum testen diese Zeile löschen https://github.com/Freetz-NG/freetz-ng/blob/master/config/avm/features.in#L306 |
Beta Was this translation helpful? Give feedback.
Replies: 23 comments 13 replies
-
Hier müsste man sich jetzt tiefer mit Programmierung in C auskennen. Um das debuggen zu können. Da bin ich nicht besonders fit drin. Es sieht aber irgendwie so aus als könnte der ganze Rest ein Folgefehler von dem hier sein? Oder kommt das auch ohne den Preload?
|
Beta Was this translation helpful? Give feedback.
-
Die Zeile fand ich auch komisch. Ohne die libctlmgr erscheint sie nicht. |
Beta Was this translation helpful? Give feedback.
-
Ich kann das mit der 7590 irgendwie nicht nachstellen. Nutze gerade
Man sieht auch an dieser Zeile, dass die libctlmgr geladen wurde: Auch dein vorheriger Befehl zum prüfen, zeigt, dass die Lib geladen wurde:
Kein Crash, kein Bootloop. Allerdings sehe ich auch keine weiteren Debug-Meldungen der libctlmgr. Hätte Einträge zu den |
Beta Was this translation helpful? Give feedback.
-
Interessant, danke fürs testen. Vielleicht sollte ich mal ohne Remove Patches testen. Welche FOS Version hast du denn verwendet? (7490 die ich nutze hat max 7.5x)
Welche Meldungen erscheinen sollten sieht man hier, der Code ist kurz: https://github.com/Freetz-NG/freetz-ng/blob/master/make/libs/libctlmgr/src/libctlmgr.c |
Beta Was this translation helpful? Give feedback.
-
Bei mir ist auch "max 7.5x" eingestellt. Es ist also ein FOS 7.57
Ja, ist auch aktiv. Aber entsprechende Debugmeldungen dazu kamen nicht. Scheint also, vom ctlmgr, nicht aufgerufen zu werden. EDIT2:
EDIT3: Die 7590 und 7490 nutzen auch andere libc Varianten. Möglicherweise macht das den Unterschied, ob crash oder nicht. 7590:
7490:
EDIT4: Mit leeren environment siehts bei mir ähnlich, wie bei dir aus.
|
Beta Was this translation helpful? Give feedback.
-
Ich hab jetzt mal einige Configteile meiner anderen 7590 auf die DevBox restored. Und jetzt bekomme ich auch deinen Fehler. Hängt dann wohl mit der Config zusammen, obs auftritt oder nicht.
EDIT: EDIT2: EDIT3: EDIT4: EDIT5: EDIT6: |
Beta Was this translation helpful? Give feedback.
-
Ich hatte auf der 7490 einmal komplett ohne remove-patches probiert, es crashte auch
Es dürfte keine gute Idee ohne ENV sein, das sah man ja an den anderen crash-meldungen. Es könnte aber sein dass irgend etwas fehlt! (kam schon öfter mal vor mit freetz) Siehe /var/env*, die sind teilweise von avm
Früher hat avm überall uclibc(ng) verwendet, dann kamen manche geräte mit glibc und musl dazu, alle in verschiedenen versionen. Das hat Freetz nicht mitgemacht, sondern für SEINE binaries eine eigene libc dabei, uclibc-ng.
Das muss ich mal ausprobieren!!
AVM hat auch im Bereich Linux-Benutzerverwaltung eine sehr komisch herangehensweise...
Ja, das hatte ich auch getestet. Aber ich hatte nur nur in der Config.in beide auskommentiert |
Beta Was this translation helpful? Give feedback.
-
Ist aber keine Lösung. Sollte nur ein Hinweis sein das ganze etwas einzugrenzen. Wenn Wo ich jetzt stehe, ist die Erkenntnis, dass, egal was ich preloade, der Crash kommt. Das heißt an der libctlmgr.c irgendwas zu ändern macht keinen Sinn. Es ist der Preload-Vorgang an sich. Man muss sich womöglich komplett von dieser Variante verabschieden, da die Ursache, aufgrund von Closed Source, wohl nicht zu finden sein wird. Und wenn das rename eh schon keine Rolle mehr spielt. Und das chmod auch nur noch dazu da ist, die korrekten Rechte für "/var/tmp" zu setzen, dann muss es doch möglich sein, da einen anderen Ansatz zu finden, oder? |
Beta Was this translation helpful? Give feedback.
-
Man weiss nur leider nicht wann AVM den Quatsch ändert! Aus der Erinnerung: Nach dem Systemstart, bei Internet-Verbindungsaufbau, bei Änderungen an der Benutzerverwaltung, und vermutlich noch anderes. |
Beta Was this translation helpful? Give feedback.
-
So wie das vorhin in meinen Recherchen gesehen habe, hast du mit PeterPawn schon mal an dieser Baustelle gebastelt. Nur gings damals um die EDIT:
Alternativ könnte man sich auch einen Ordner innerhalb von |
Beta Was this translation helpful? Give feedback.
-
Ich glaube das Ergebnis war dann dass man die freetz-libs mit jeder libc verwenden kann da diese sehr einfach sind, man muss nur den pfad mit patchelf (in der .mk) anpassen. |
Beta Was this translation helpful? Give feedback.
-
Keine eigenständige Version nötig. Einfach Busybox Applet
Etwas robuster würde es dann wohl so aussehen: #!/bin/sh
tmp_dir="/var/tmp"
has_perm() {
local perm=$1
local target=$2
if [ "$(stat -c '%a' $target 2>/dev/null)" != "$perm" ]; then
return 1
else
return 0
fi
}
while true; do
if [ ! -d "$tmp_dir" ]; then
continue
fi
has_perm 1777 "$tmp_dir"
if [ $? -ne 0 ]; then
chmod 1777 "$tmp_dir"
fi
inotifyd - "${tmp_dir}:e" | \
while read l; do
has_perm 1777 "$tmp_dir"
if [ $? -ne 0 ]; then
chmod 1777 "$tmp_dir"
fi
done
done |
Beta Was this translation helpful? Give feedback.
-
Wenn inotify gut läuft wäre das ja auch okay. Das ist jedenfalls kompatible als libctlmgr und auch für die Zukunft. |
Beta Was this translation helpful? Give feedback.
-
Ja, das kam mir auch schon in den Sinn. Aber wie du sagst. Das ist dann so. Muss man schauen, ob das wirklich relevant werden könnte.
Beim ersten ˋchmodˋ wäre das sogar kontraproduktiv. Wir wollen danach so schnell wie möglich inotify starten, damit es weitere Änderungen mitbekommt. Wenn in dieser 1sek das Verzeichnis wieder geändert werden würde, dann würde inotify das nachträglich nicht mehr merken. Beim zweiten ˋchmodˋ, also das, was durch inotify aufgreufen wird, könnte man das zwar machen, aber damit verlangsamtst du die Schleife. Und wenn innerhalb dieser 1 Sekunde dann was auf das Verzeichnis zugreifen wollte und die Rechte wieder falsch wären, dann wäre das wieder ein Problem.
Ja, genau. Das ˋchmodˋ würde wieder das inotify triggern. Deshalb prüfen, ob die Rechte schon korrekt sind und nur wenn nicht, dann ˋchmodˋ ausführen. Sonst hätte man eine Endlosschleife. Vielleicht nochmal kurz erklärt, welchen Sinn bestimmte Teile des Scriptes haben:
|
Beta Was this translation helpful? Give feedback.
-
Teste mal, mit Logdatei im Webinterface, Anzeige des Services unter "Freetz" (oder lieber nicht anzeigen??) und automatischem Start wenn installiert. Das für alle Geräte seit supervisor also 7.2. Auch sehen die "PIDs" gut aus. |
Beta Was this translation helpful? Give feedback.
-
Scheint super zu funktionieren.
Scheint ja zu funktionieren. Ich wollte halt nur sicher gehen, weil ich bei meinen Tests, bei dem anderen Thema, wo ich mit dem Logging gespielt hatte, auch mal einen Ordner in /var/tmp angelegt hatte, der dann plötzlich, im Verlauf des Bootvorgangs, wieder weg war. Deshalb war ich mir nicht so sicher, ob da vielleicht zwischendurch doch mal der /var/tmp Ordner verschwindet. |
Beta Was this translation helpful? Give feedback.
-
Mit fos 7.2 bis zur aktuellen lief es bislang ja ohne größere Problem mit den seltsamen Rechten, dann wird es das auch noch wenn die "im Betrieb" behoben werden. cron läuft nur als root man man kann zu "normalem" keine Bentzer angeben, telnetd ist ein (ehemaliger) avm service, mit login des avm-webif Passwortes und das webcfg ist das freetz webif. Keines davon legt eigene Benutzer an.
/var gibt es leer im Image, beim booten mountet avm das ins ram und entpackt /var.tar dorthin. Wenn du vorher das prüfst ist das Verzeichnis nicht da. Aber Freetz wird bekanntlich am Ende des Bootvorgangs nach dem ganzen AVM Zeug gestartet. Da muss es /tmp schon geben. Abe dieser Test gibtes ja nocht, nur keine mehr wenn man var/tmp im Betrieb löschen sollte Und beobachte mal wann AVM die Rechte überschreibt, das wurde bislang noch nicht untersucht. Ich hab immer die ganzen AVM-Daemons removed :) |
Beta Was this translation helpful? Give feedback.
-
Ich weiß nicht ganz, ob es in diese Diskussion passt, aber ich befürchte, dass die Commits zu "rc-scripts"/"rc-wrapper"/"svc" vom 9. April bei mir nicht wie geplant funktionieren. Ich habe eine FritzBox 5491 mit Firmware 7.31. Commit 6a05f61 vom 8. April läuft. Nach Commit 6a05f61 vom 9. April startet die Box zwar noch, die Power-Lampe geht an, WLAN-Lampe blinkt und leuchtet konstant und es wird auch ein WLAN erzeugt, aber ich bekomme keine IP mehr zugewiesen (ich benutze dnsmasq). Die LAN-Ports sind tot und ich kann damit keinen Zugriff auf die Box erhalten. Dieser Zustand bleibt erhalten, d.h., die Box startet nicht von selbst neu. Wie kann ich das weiter debuggen? |
Beta Was this translation helpful? Give feedback.
-
Am einfachsten ne Console dran und lesen was da an Output kommt |
Beta Was this translation helpful? Give feedback.
-
Die 7.1x hat noch keinen avm-supervisor, und verhält sich somit komplett anders - es sollte unverändert zu vorher sein |
Beta Was this translation helpful? Give feedback.
-
Ich habe gerade mal ein image für die 5491 gebaut und mir die resultierende Dateistruktur, im Buildsystem, angeschaut. So wie es aussieht, nutzt die Box mit FOS 7.31 zwar schon den systemd, aber der multid wird in der Version noch klassisch, ohne systemd gestartet. Das Problem ist jetzt, wir prüfen in dem modifizierten Init-Script ( Vielleicht könnte man einfach überall dort wo es sinnvoll ist von |
Beta Was this translation helpful? Give feedback.
-
Eure Arbeit gefällt mir immer. |
Beta Was this translation helpful? Give feedback.
Ich habe gerade mal ein image für die 5491 gebaut und mir die resultierende Dateistruktur, im Buildsystem, angeschaut. So wie es aussieht, nutzt die Box mit FOS 7.31 zwar schon den systemd, aber der multid wird in der Version noch klassisch, ohne systemd gestartet.
Das Problem ist jetzt, wir prüfen in dem modifizierten Init-Script (
rc.multid
) nur auf"$FREETZ_AVM_HAS_SVCTL" == "y"
. Konnte ja keiner ahnen, dass es noch ein Zwischending gibt, wo zwar systemd vorhanden ist, aber multid noch nicht damit gestartet wird.Vielleicht könnte man einfach überall dort wo es sinnvoll ist von
[ "$FREETZ_AVM_HAS_SVCTL" == "y" ]
auf[ -f "/lib/systemd/system/${DAEMON_SVC}.service" ]
ändern. oder beides …