Freetz trunk / 7390: kein Reboot und kein weiteres Update mehr möglich

[olistudent]

Ich denken nicht, dass die AVM debug Frickelei was damit zu tun hat. Angeblich ist es seit dem busybox Update auf 1.18.

Gruß
Oliver

 

[cando]

Kann sein, dass die Konsole damit nichts zu tun hat, der syslog / klog ist aber definitiv davon betroffen. Es gab doch früher einen Patch im freetz um die Konsole zum "schweigen" zu bringen im AVM Bereich unter Patches - der war sogar von Haus aus selektiert.

In der aktuellen Trunk Version ist der verschwunden - vielleicht hängt es ja mit dem neuen Menuconfig / der Umstrukturierung zusammen?

 

[RalfFriedl]

Müsste strace auf den hängenden Prozess was bestimmtes ausspucken?

Ich denke, daß hier eher lsof auf init weiter hilft. Bei mir sieht das so aus:

# lsof -nPc init
COMMAND  PID USER   FD   TYPE DEVICE   SIZE NODE NAME
init       1 root  cwd    DIR   31,1    229  181 /
init       1 root  rtd    DIR   31,1    229  181 /
init       1 root  txt    REG   31,1 551900  273 /bin/busybox
init       1 root  mem    REG   31,1  22728 1004 /lib/ld-uClibc-0.9.29.so
init       1 root  mem    REG   31,1 456212 1124 /lib/libuClibc-0.9.29.so
init       1 root    0u   CHR    5,1         405 /dev/console
init       1 root    1u   CHR    5,1         405 /dev/console
init       1 root    2u   CHR    5,1         405 /dev/console

Alle drei FDs sind mit /dev/console verbunden. Wenn das auf dieser Box auch so ist, bleibt die Frage, ob init dies für das gestartete Programm ändert. Evtl. läßt sich das so feststellen:

# cat /etc/inittab
shutdown:/sbin/run_post_install
# cat /sbin/run_post_install
lsof -nPp $$ &> /var/tmp/lsof.txt
cat /var/tmp/lsof.txt > /dev/console
/bin/sh -c /var/post_install

Sofern es kein grundsätzliche Problem mit der Console gibt, kann man auch explizit die Ausgabe auf /dev/console statt /dev/null leiten. Wenn /dev/console nicht mehr funktioniert, mu0 man anderweitig nachsehen, was lsof ausgegeben hat.

 

[olistudent]

Da kam auf meiner 7270 jetzt sowas bei raus:

COMMAND  PID USER   FD   TYPE DEVICE   SIZE NODE NAME
COMMAND    PID USER   FD   TYPE DEVICE   SIZE NODE NAME
run_post_ 3200 root  cwd    DIR   31,0    224  258 /
run_post_ 3200 root  rtd    DIR   31,0    224  258 /
run_post_ 3200 root  txt    REG   31,0 552032  261 /bin/busybox
run_post_ 3200 root  mem    REG   31,0  22536 1332 /lib/ld-uClibc-0.9.29.so
run_post_ 3200 root  mem    REG   31,0 460172 1317 /lib/libuClibc-0.9.29.so
run_post_ 3200 root    0u   CHR    5,1         457 /dev/console
run_post_ 3200 root    1w   REG   0,11      0 4631 /var/tmp/lsof.txt
run_post_ 3200 root    2w   REG   0,11      0 4631 /var/tmp/lsof.txt
run_post_ 3200 root   10r   REG   0,11    110 4555 /var/run_post_install
run_post_ 3200 root   11u   CHR    5,1         457 /dev/console
run_post_ 3200 root   12u   CHR    5,1         457 /dev/console

So soll das aussehen?

Gruß
Oliver

 

[RalfFriedl]

Es überrascht mich zwar etwas, daß da /var/tmp/lsof.txt mit auftaucht, aber es scheint richtig zu sein. Anscheinend wird die Ausgabe-Umlenkung schon im Parent-Prozess gemacht und die FDs 1 und 2 als 11 und 12 gesichert. Jedenfalls ist die Ausgabe mit der Konsole verbunden.

Gibt /var/post_install danach gar nichts mehr aus, oder kommt eine Ausgabe und das Skript hängt irgendwann?

Ist die Zeile COMMAND... tatsächlich doppelt?

 

[olistudent]

Die doppelte Command Zeile war ein Copy&Paste Fehler. Bei mir geht das dann mit folgendem weiter:

unmounting '/var/media/ftp/*' ..
unload dsl and dependend driver ..
Jan 21 01:22:50 telefon[1371]: SIGTERM received!
Jan 21 01:22:50 pbd[1403]: received signal: Terminated.
Jan 21 01:22:50 pbd[1404]: received signal: Terminated.
Jan 21 01:22:50 pbd[1405]: received signal: Terminated.
Jan 21 01:22:50 pbd[1398]: received signal: Terminated.
Jan 21 01:22:50 pbd[1398]: terminating.
killall: dect_manager: no process killed
...

Aber das Problem tritt ja auch auf einer 7270 nicht auf.

Gruß
Oliver

 

[RalfFriedl]

Wenn das Problem bei der 7270 nicht auftaucht, dann muß jemand das auf einer 7390 ausprobieren.

 

[cuma]

... oder 7170. Und ja, mit BusyBox v1.17.4 hab die das Problem nicht

 

[Toadie]

Hilfe - da sind zwei inits

Kann sich das jemand erklären:
Beim Ausführen des lsof ist mir aufgefallen, dass ich hier 2 inits habe. Der zweite ist mit ttyS0 verbunden.
System: 7170 mit trunk 6417
Ich überprüf' das aber noch'mal - nicht dass ich den Bock selbst geschossen habe.

root@fritz:/var/media/ftp/uStor00/debug# ./lsof -nPc init
COMMAND  PID USER   FD   TYPE DEVICE   SIZE    NODE NAME
init       1 root  cwd    DIR   31,1    140 3697702 /
init       1 root  rtd    DIR   31,1    140 3697702 /
init       1 root  txt    REG   31,1 486448      39 /bin/busybox
init       1 root  mem    REG   31,1  22536  626646 /lib/ld-uClibc-0.9.29.so
init       1 root  mem    REG   31,1 460172  627818 /lib/libuClibc-0.9.29.so
init       1 root    0u   CHR    5,1            479 /dev/console
init       1 root    1u   CHR    5,1            479 /dev/console
init       1 root    2u   CHR    5,1            479 /dev/console
init    1836 root  cwd    DIR   31,1    140 3697702 /
init    1836 root  rtd    DIR   31,1    140 3697702 /
init    1836 root  txt    REG   31,1 486448      39 /bin/busybox
init    1836 root  mem    REG   31,1  22536  626646 /lib/ld-uClibc-0.9.29.so
init    1836 root  mem    REG   31,1 460172  627818 /lib/libuClibc-0.9.29.so
init    1836 root    0u   CHR   4,64            219 /dev/ttyS0
init    1836 root    1u   CHR   4,64            219 /dev/ttyS0
init    1836 root    2u   CHR   4,64            219 /dev/ttyS0

 

[Toadie]

Die FD's beim reboot scheinen (trotz der zwei inits) ok zu sein:

root@fritz:/var# ./lsof -nPp 1896,1897,2144
COMMAND  PID USER   FD   TYPE DEVICE   SIZE    NODE NAME
sh      1896 root  cwd    DIR   31,1    140 3695910 /
sh      1896 root  rtd    DIR   31,1    140 3695910 /
sh      1896 root  txt    REG   31,1 486448      39 /bin/busybox
sh      1896 root  mem    REG   31,1  22536  626134 /lib/ld-uClibc-0.9.29.so
sh      1896 root  mem    REG   31,1 460172  627306 /lib/libuClibc-0.9.29.so
sh      1896 root    0u   CHR    5,1            479 /dev/console
sh      1896 root    1u   CHR    5,1            479 /dev/console
sh      1896 root    2u   CHR    5,1            479 /dev/console
sh      1897 root  cwd    DIR   31,1    140 3695910 /
sh      1897 root  rtd    DIR   31,1    140 3695910 /
sh      1897 root  txt    REG   31,1 486448      39 /bin/busybox
sh      1897 root  mem    REG   31,1  22536  626134 /lib/ld-uClibc-0.9.29.so
sh      1897 root  mem    REG   31,1 460172  627306 /lib/libuClibc-0.9.29.so
sh      1897 root    0u   CHR    5,1            479 /dev/console
sh      1897 root    1u   CHR    5,1            479 /dev/console
sh      1897 root    2u   CHR    5,1            479 /dev/console
sh      1897 root   10r   REG   0,11    883     630 /var/post_install
sh      2144 root  cwd    DIR   31,1    140 3695910 /
sh      2144 root  rtd    DIR   31,1    140 3695910 /
sh      2144 root  txt    REG   31,1 486448      39 /bin/busybox
sh      2144 root  mem    REG   31,1  22536  626134 /lib/ld-uClibc-0.9.29.so
sh      2144 root  mem    REG   31,1 460172  627306 /lib/libuClibc-0.9.29.so
sh      2144 root    0u   CHR    5,1            479 /dev/console
sh      2144 root    1u   CHR    5,1            479 /dev/console
sh      2144 root    2u   CHR    5,1            479 /dev/console
sh      2144 root   10r   REG   31,1   6151    1983 /etc/init.d/rc.dsl.sh

allerdings scheint /dev/console nicht richtig verbunden zu sein. Gibt's eine Möglichkeit, auszugeben wohin das umgelenkt wird? Ich hab kein showconsole gefunden.

reboot ohne setconsole:

root@fritz:/var# reboot
root@fritz:/var# <<<< es passiert einfach nix >>>>

reboot mit setconsole:

root@fritz:/var/mod/root# setconsole
root@fritz:/var/mod/root# reboot
root@fritz:/var/mod/root# stopping USB-Subsystem ..
unload dsl and dependend driver ..
   ...

system is going down ..
The system is going down NOW!
Connection closed by foreign host.

Scheint tatsächlich an dem setconsole zu liegen

 

[RalfFriedl]

Beim Ausführen des lsof ist mir aufgefallen, dass ich hier 2 inits habe.

Prozeß 1 ist der normale init-Prozeß.
Der andere kommt von diesem Eintrag in inittab:

ttyS0::[B]askfirst[/B]:-/bin/sh

 

[hermann72pb]

Kann es sein, dass es an der Benennung /dev/console liegt? Mir war dies bei der Aktualisierung meiner libmodmount.sh aufgefallen. Früher hatte AVM in ihren Skripten /dev/ttyS0 benutzt. Nun stand plötzlich überall /dev/console. Die Änderung kam irgendwo zwischen 80-ger und 86-ger Version der Firmware. Ich hatte bei meiner 7170 damals /dev/console gefunden und sagte mir: naja, dann dürfen wir es generell verwenden. Es hat auch alles angeblich funktioniert, obwohl ich es natürlich nicht mit der richtigen Konsole gecheckt hatte, weil ich keine habe.
libmodmount.sh beinhaltet Fragmente aus neuen AVM-Schöpfungen in deren hotplug-Skripten (Stand: 86-Firmware). Um alles einfacher zu halten, hatte ich eben irgendwann mal gesagt, dass libmodmount.sh die hotplug-Skripte an einigen Stellen in den älteren Boxen mit den neuen Inhalten überschreibt. An sich ist es nicht schlimm, denn meistens waren bis jetzt die hotplug-Skripte eher besser geworden und waren an sich halbwegs abwärtskompatibel.
Jetzt spinnen wir mal weiter. Angenommen, früher hat alles prima funktioniert, weil bei busybox 1.17 und der hier schon angesprochener Umleitung aller Meldungen die /dev/console gar nicht angesprochen war. Jetzt hat sich im aktuellen trunk etwas geändert (busybox 1.18, Umleitung weg), sodass /dev/console nun plötzlich gebraucht wird.
Was kann man weiter testen/überprüfen?
1. Kann bitte jemand ein Image mit aktuellem Trunk aber OHNE FREETZMOUNT-Patch für eine 7170 bauen? 7170 ist wichtig, weil gerade da dieser Tausch von /dev/ttyS0 zu /dev/console statt finden sollte.
2. Kann man irgendwie /dev/console an /dev/ttyS0 umleiten? Das wäre mir lieber, als eine Sonderbehandlung in libmodmount.sh einzuführen. Denn diese Geschichte mit libmodmount.sh ist gerade dafür entstanden, um Wartungsaufwand zu minimieren.

Ich bin leider heute und morgen ziemlich geerdet, sonst würde ich es selbst austesten. Bin aber generell online und auf eure Rückmeldungen gespannt.

MfG

 

[RalfFriedl]

Kann es sein, daß das Problem nur dann auftritt, wenn folgendes zusammen kommt?

- Es wird eine Shell-Verbindung über das Netzwerk aufgebaut (Telnet oder SSH)
- Mit setconsole wird die Konsole umgeleitet auf /dev/pts/x
- Die Netzwerk-Verbindung wird wieder getrennt
- Beim Reboot werden Meldungen für /dev/console generiert, die Verbindung zu /dev/pts/x besteht aber nicht mehr

 

[hermann72pb]

@Ralf: Kannst du bitte etwas detaillierter für Einige etwas langsam Denkende wie mich erklären? Ich kann da deinen 4. Punkten nicht ganz folgen, z.B.:
1. Warum und wann wird es mit setconsole umgeleitet? Immer, oder nur wenn man den entsprechenden Umleitungs-Patch hat?
2. Warum wird die Netzwerkverbindung getrennt? Und wobei überhaupt?

Ich habe mit dem Ganzen etwas Verständnisproblemme, weil das eigentliche Updaten läuft doch immer über FREETZ WebIF und nicht über ssh oder telnet? Was ich konkret in meinem Fall hatte, war eine über putty und dropbear getunnelte Verbindung. Sie stand aber erstmal und wurde gar nicht getrennt.

MfG

 

[cuma]

Meine Beobachtungen aus dem Ticket, dann funktioniert "reboot" auch ohne Workaround vom Terminal aus

"rc.crond stop"
alternativ
"rmmod capi_codec isdn_fbox_fon4 ubik2 tiatm"

@ralf: "Die Netzwerk-Verbindung wird wieder getrennt" ist jedenfalls nicht nötig

 

[olistudent]

Der getcons Patch ist derzeit nicht auswählbar. Also kann es das eigentlich nicht sein. Und cuma's Beobachtungen kann ich mit dem Problem und den Symptomen nicht in Verbindung bringen...

Gruß
Oliver

 

[hermann72pb]

@Oliver: Kannst du bitte mit dem getcons-Patch aufklären? Wie rum ist er nicht auswählbar? So rum, als ob er nicht da wäre oder so rum, dass er immer aktiviert ist? Warum ist getcons nun weg? Ich habe eher die Befürchtung, dass es doch damit wenigstens teilweise zusammen hängt. Eher würde ich sagen, dass wir mit einer Pallette misslungener Zustände zu kämpfen haben.
@cuma: Bei mir war cron.d nie aktiv. Also, es ist kein cron an sich. Dennoch kann ich auch bestätigen, dass die rmmod-Geschichte scheint da auch was beizutragen. Was passiert denn eigentlich in "rc.crond stop" ? Vielleicht werden da irgendwelche sonstigen Aktionen durchgeführt, die das Problem lösen?

@all: Hat es jemand ohne FREETZMOUNT ausprobiert? Denn in FREETZMOUNT steht an einigen Stellen die Umleitung zu /dev/console, die eigentlich in der Usrprungsversion von AVM für 7170 /dev/ttyS0 hieß.

MfG

 

[cuma]

"killall crond" hat den gleichen Effekt wir per rc-Skript zu stoppen.
Ich hatte es mal ohne USB-Stickt aber mit Freetz-mount getestet, hing aber

 

[hermann72pb]

ohne USB-Stick hing bei mir auch. Ich meinte komplett ohne FREETZMOUNT ausprobieren. Denn ich weiß nicht mehr wie da alle hotplug-Skripte verzahnt sind. Es kann sein, dass es trotzdem zu /dev/console geleitet wird.

MfG

 

[RalfFriedl]

Kannst du bitte etwas detaillierter erklären?

Normalerweise geht die Ausgabe der von init gestarteten Skripte auf die Konsole, wenn man diese nicht umleitet. Wenn es hilft, die Ausgabe des Reboot-Skripts auf /dev/null umzuleiten, dann hängt anscheinend die Ausgabe auf die Konsole. Die Konsole geht normalerweise auf die serielle Schnittstelle. Es gibt also keinen Grund, warum eine Ausgabe auf die Konsole hängen sollte.

Warum mit setconsole umgeleitet werden soll, kann ich Dir nicht sagen. Ich persönlich finde es lästig, die Konsole auf mein Terminal umzuleiten und mache das nicht. Das Standard-Skript von AVM tut das aber. Wenn man sich über telnet oder SSH anmeldet und setconsole nicht deaktiviert ist, dann wird die Konsole auf /dev/pts/0 umgeleitet. Irgendwann meldet man sich ab, dann wird die Netzwerk-Verbindung von telnet oder SSH getrennt. Dies hat zunächst nichts mit dem Reboot zu tun. Das Problem ist nach den Beschreibungen auch allgemein der Reboot und nicht speziell ein Update. Es ist nur so, daß ein Update einen funktionierenden Reboot benötigt.

Meine Überlegung war, daß die Konsole vielleicht hängt, wenn man sie auf ein anderes Gerät umgeleitet hat, konkret beim Anmelden auf /dev/pts/0, das nachher nicht mehr verfügbar ist. Diese Vermutung stimmt aber anscheinend nicht.