Box startet bei "reboot" nicht neu

[Benny]

Hallo,

Wenn ich über die Konsole "reboot" oder "reboot -f" ausführe, startet meine Box nicht neu. Ich werde lediglich aus der Konsole rausgeschmissen, kann mich aber bei Bedarf sofort wieder anmelden. Es sieht so aus, als würden nur die Shellzugriffe gekappt.

Das gleiche gilt für den Button "Reboot" in der DS-Mod Weboberfläche: Es kommt die Meldung, dass ich mich nach dem Neustart hier wieder anmelden kann - Die Box startet aber nicht neu, sondern ich kann sofort wieder auf die Weboberfläche zugreifen.

Es ist aber nicht so, dass der Reboot generell nicht geht. Manchmal funktioniert es auch einwandfrei. Ich konnte noch nicht feststellen, warum es manchmal geht und manchmal nicht (also welche Prozesse laufen bzw. nicht laufen). Lediglich kann ich hier mal die ps Ausgabe posten, falls das weiter hilft:

  PID  Uid        VSZ Stat Command
    1 root       1432 S   init
    2 root            SWN [ksoftirqd/0]
    3 root            SW< [events/0]
    4 root            SW< [khelper]
    5 root            SW< [kthread]
    6 root            SW< [kblockd/0]
   23 root            SW< [pdflush]
   24 root            SW< [pdflush]
   26 root            SW< [aio/0]
   25 root            SW  [kswapd0]
   62 root            SW  [pm_info]
   69 root            SW  [mtdblockd]
   95 root            SW  [tffsd_mtd_0]
  423 root            SW< [capi_oslib]
  424 root            SW< [capi_oslib]
  425 root            SW  [capitransp]
  436 root            SW< [khubd]
  507 root      10784 S N ctlmgr
  529 root       1988 S   wpa_authenticator
  577 root       5584 S N websrv
  597 root       5584 S N websrv
  598 root       5584 S N websrv
  599 root       5584 S N websrv
  628 root       6340 S   dsld -i -n -g
  636 root       3136 S   telefon a127.0.0.1
  640 root       9240 S < voipd
  646 root        948 S   /bin/run_clock -c /dev/tffs -d
  840 root            RWN [kdsld_token]
  863 root       1544 S   /bin/ash /usr/sbin/callmonitor
  864 root       1432 S   logger -t callmonitor -p daemon.info
 1082 root       1432 S   init
 2386 root            SWN [scsi_eh_0]
 2387 root            SWN [usb-storage]
  741 root        844 S N dnsmasq -p 53
  747 root       5728 S N multid -u
 1296 root       1448 S N httpd -p 81 -c /mod/etc/httpd.conf -h /usr/mww/ -r DS-MOD (use
 1909 root       1124 S N dropbear -p 22
 2538 root       1432 D N mount /dev/sda1 /mod/mnt/device1/
  974 root       1424 D N reboot
  975 root       1188 S N dropbear -p 22
  976 root       1452 S N -sh
 1026 root       1424 D N reboot -f
 1027 root       1192 S N dropbear -p 22
 1028 root       1452 S N -sh
 1073 root       1424 D N reboot -f
 1074 root       1188 S N dropbear -p 22
 1075 root       1452 S N -sh
 1122 root       1544 S   /bin/ash /usr/sbin/callmonitor
 1123 root       1424 S   sleep 20000d
 1124 root       1544 S   /bin/ash /usr/sbin/callmonitor
 1126 root       1544 S   /bin/ash /usr/sbin/callmonitor
 1125 root       1428 S   busybox nc 127.0.0.1 1012
 1128 root       1424 D N reboot -f
 1129 root       1192 S N dropbear -p 22
 1130 root       1452 S N -sh
 1226 root        996 S N matrixtunnel -A /usr/share/matrixtunnel-key.pem -p /usr/share/
 1612 root       1528 S N syslogd -L -C100
 1700 root       1424 D N reboot
 1848 root       1448 S N httpd -p 81 -c /mod/etc/httpd.conf -h /usr/mww/ -r DS-MOD (use
 1849 root       1444 S N /bin/sh /usr/mww/cgi-bin/exec.cgi
 1858 root       1424 D N reboot
 1942 root       1192 S N dropbear -p 22
 1943 root       1452 S N -sh
 1999 root       1432 R N ps

Die 6 Reboot-Prozesse kann ich mit kill PID nicht killen... es kommt aber auch keine Ausgabe.

 

[RalfFriedl]

Die Ausgabe von "logread" wäre interessant, und evtl. "strace reboot", dazu ein strace im ds-mod erzeugen.

 

[Benny]

Also in der Syslog steht nix darüber soweit ich das sehe. Allerdings hatte ich sie der Übersichthalber nochmal geleert...
Das sind die Ausgaben, die jetzt kommen - ein "reboot" oder Ähnliches bringt aber keinen neuen Eintrag in der Syslog

Jan 17 11:57:22 fritz syslog.info syslogd started: BusyBox v1.5.1
Jan 17 12:03:37 fritz authpriv.notice dropbear[1942]: password auth succeeded for 'root' from xxx.xxx.xxx.xxx:6772
Jan 17 12:18:33 fritz daemon.info dnsmasq[741]: DHCPREQUEST(lan) 10.5.1.41 00:08:0d:ca:a1:63 
Jan 17 12:18:33 fritz daemon.info dnsmasq[741]: DHCPACK(lan) 10.5.1.41 00:08:0d:ca:a1:63 server1

und evtl. "strace reboot", dazu ein strace im ds-mod erzeugen

Damit kann ich jetzt noch überhaupt nix anfangen. Was is das denn? Muss ich das beim Mod Erstellen erzeugen? Ich bin ja momentan nicht Zuhause - also kann ich momentan auch keinen neuen Mod aufspielen. Außerdem muss ich dann erstmal wieder warten, bis der Fehler wieder auftritt... tritt ja nicht ständig auf. Aber gerade hab ich das Problem ;-)

 

[RalfFriedl]

"strace" ist ein Programm, mit dem man verfolgen kann, welche Systemaufrufe ein anderes Programm macht. "strace" kann man beim Erstellen des ds-mod mit auswählen. Es ist nicht notwendig, die neu erstellte Firmware dann auf die Box zu flashen, man kann auch einfach das erstellte strace Programm auf die Box kopieren.

Die "reboot" Prozesse hängen auf jeden Fall alle im Status "D", der für Festplattenzugriffe steht. Genauso der mount-Prozeß "mount /dev/sda1 /mod/mnt/device1/". Ist irgend ein Dateisystem nicht mehr verfügbar? Ein NFS-Mount oder ein Dateisystem auf einem USB Speicher?

Was kommt bei

echo $PATH
echo $LD_LIBRARY_PATH
cat /proc/mounts
df
mount
/sbin/reboot -f

Falls etwas interessantes im Syslog kam, dann vermutlich nach dem ersten Versuch eines Neustarts.

 

[Benny]

/var/mod/root $ echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/mod/sbin:/mod/bin:/mod/usr/sbin:/mod/usr/bin
/var/mod/root $ echo $LD_LIBRARY_PATH
/mod/lib
/var/mod/root $ cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / squashfs ro 0 0
dev /dev tmpfs rw,nosuid 0 0
proc /proc proc rw,nodiratime,nosuid,nodev,noexec 0 0
ramfs /var ramfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0
usbfs /proc/bus/usb usbfs rw 0 0
/var/mod/root $ df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock1            5632      5632         0 100% /
/var/mod/root $ mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
dev on /dev type tmpfs (rw,nosuid)
proc on /proc type proc (rw,nodiratime,nosuid,nodev,noexec)
ramfs on /var type ramfs (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
usbfs on /proc/bus/usb type usbfs (rw)
/var/mod/root $ /sbin/reboot -f

(bleibt hängen)

Ich weiß nicht, ob es an der Ausführung der eben genannten Befehle liegt (glaub ich ja eher nicht), oder daran, dass so viele offene Sitzungen vorhanden sind: Jetzt kommt direkt nach dem Einloggen folgende Fehlermeldung seitens Puttys: "Server refused to start a shell/command"
Kurz: Ich kann mich per SSH nicht mehr einloggen :-(
Jetzt gehts nur noch per Rudi-Shell

Die "reboot" Prozesse hängen auf jeden Fall alle im Status "D", der für Festplattenzugriffe steht. Genauso der mount-Prozeß "mount /dev/sda1 /mod/mnt/device1/". Ist irgend ein Dateisystem nicht mehr verfügbar? Ein NFS-Mount oder ein Dateisystem auf einem USB Speicher?

Ich habe mit dem NTFS-3G rumgespielt. Habe es aber nicht hinbekommen. Dazu hatte ich einen Ordner /mod/mnt/device1 erstellt und in der Web-Konfiguration von NTFS-3G folgendes eingetragen:
bei Device1:
Device: /dev/sda1
Mountpoint: /mod/mnt/device1
die anderen Devices sind nicht belegt (nix eingetragen)

Beim versuch den Dienst "ntfs" zu starten, kam zwar "mount NTFS...done." aber dann war der Dienst laut der Weboberfläche vom DS-Mod noch immer nicht gestartet.

Meinst du daran liegt der Fehler?

 

[RalfFriedl]

Das Problem mit dem Login wird sein, daß auch alle anderen Versuche für einen Reboot dazu geführt haben, daß die Session hängen bleibt. Wahrscheinlich sind jetzt alle pty's belegt.

Der Status "D" ist auf jeden Fall ungewöhnlich, da Zugriffe auf Dateisysteme normalerweise schnell ablaufen und Prozesse diesen Zustand daher nur kurz haben, außer wenn es ein ernstes Problem mit dem Dateizugriff gibt. Das scheint hier aber nicht der Fall zu sein. Der einzige Prozeß außer den reboot Aufrufen ist ein mount. Ein normales Mount wird aber sofort wieder beendet und bleibt nicht laufen. beim NTFS-Mount könnte das aber auch anders sein.

Es ist möglich, daß es irgendwo einen Zugriffsfehler im Kernel gab (Kernel Panic). Da das Log gelöscht ist, wird sich das nicht mehr feststellen lassen.

Um einen Neustart der Box wird du vermutlich nicht herumkommen. Ich vermute mal, daß Du Dich nicht vor Ort befindest. Wenn Du aber eine Gelegenheit hast, wo jemand für Dich die Box neu starten könnte, kannst Du vorher versuchen, über die Rudi-Shell nacheinander alle eigenen Prozesse zu killen. Ich würde dabei mit dem mount Prozeß anfangen. Es kann aber gut sein, daß es trotzdem nicht hilft. Du kannst dann noch versuchen, die AVM-Prozesse mit "kill -9", also nicht mit normalem "kill", zu stoppen. Dies könnte den Watchdog zu einem Reboot veranlaßen. Falls das auch nicht hilft, muß jagend vor Ort die Box ausschalten.