[Problem] debug.cfg auf FritzBox 7390 mit Firmware 84.05.20

[fabianhu]

Hallo zusammen,

nachdem ich mir jetzt 3 Nächte um die Ohren gehauen habe, klage ich euch mal mein Leid:

Irgendwie scheint mit der neuesten FW die debug.cfg nicht korrekt ausgeführt zu werden.

Mein "startup.sh" script mit allen Programmen (SVN, openVPN) geht wunderbar, wenn man es "zu Fuß" im Telnet aufruft.
Wenn es über die /var/flash/debug.cfg aufgerufen wird, läuft es nicht richtig.
Es wird immer nur ein oder gar kein Befehl ausgeführt.
Oder das Startup-Script wird angestartet, aber nur eine Zeile davon scheint zu funktioneren.
Wenn ich im "ps" nachsehe, ist zum Teil der "sleep" meines dyndns-checkers am laufen (letztes im Script)
oder ich sehe nur den sleep am Anfang der dabug.cfg, danach passiert nix mehr.
Die echos kommen auch nicht.
SVN oder openVPN werden nicht gestartet. (wie gesagt,geht das script "zu Fuß")


Weiß jemand die genauen Einschränkungen, die es bei der neuen FW für die debug.cfg gibt?
Welche Signale werden gesendet etc..


Ich habe schon folgendes versucht:

- Recherche (reichlich davon)
- Recovery der Box
- unterschiedliche debug.cfg "tricks"
- Aufrufe der Unterscripten mit sh und ohne
- Aufrufe der Unterskripten mit und ohne &
- Traps in den unterscripten

# debug.cfg im Voll-Ausbau (alles auch teil-getestet)
trap "" SIGHUP
trap "" SIGTERM
sleep 60
i=0
while ! [ -e /var/media/ftp/startup.sh ]; do
  sleep 5
  let i++
  [ $i -lt 36 ] && continue
  break
done
[ $i -lt 36 ] && /var/media/ftp/startup.sh &

# oder als Einzeiler ohne &

while !(/var/media/ftp/startup.sh); do sleep 5; done

startup.sh

# startup script FB 7390
# to be placed into /var/media/ftp (the root of the internal storage)

echo USB startup script running in 15s
sleep 15
echo starting extended services NOW

# start openVPN
echo "start openVPN"
cd /var/media/ftp/openvpn
sh ./server.sh &

# start SVN server
echo "start SVN"
let i=0
while ! [ -e /var/media/ftp/Storage-01/svn/svnserve ]; do
  sleep 5
  let i++
  [ $i -lt 12 ] && continue
  break
done
[ $i -lt 12 ] && cd /var/media/ftp/Storage-01/svn/
[ $i -lt 12 ] && ./svnserve -d -r ./

echo "USB Startup script finished."
sleep 1

# start the Dyndns-checker loop
sh /var/media/ftp/dyndnstest.sh &  

echo 
echo "dyndns watcher started"
sleep 1

Falls schon eine Lösung bekannt ist, sagt mir bitte, wo, ich hab nix gefunden!

Vielen Dank!!!

Fabi

 

[edward]

Ich glaube es hackt am trap "" SIGHUP es soll trap '' SIGHUP (2*einfaches Hochkomma)sein. Ich würde den trap noch in starup.sh noch vor der while-Schleife einbauen,

 

[controlletti2]

Hallo fabianhu,

Hast Du den Fehler gefunden? Ich habe gerade ein ähnlich Problem und auch kurz vorm verzweifeln. Script läuft von Hand aufgerufen einwandfrei, aber aus debug.cfg gestartet werden nur Teile ausgeführt :-(.

Gruß

controlletti2

 

[fabianhu]

Hi!

Nach einem "Update" auf Firmware 05.20-22192 BETA scheint es bei mir jetzt mehr oder weniger durch Zufall zu klappen:

debug.cfg:
# cat /var/flash/debug.cfg

trap '' SIGHUP
trap '' SIGTERM
sleep 120
i=0
while ! [ -e /var/media/ftp/startup.sh ]; do
  sleep 5
  let i++
  [ $i -lt 36 ] && continue
  break
done
[ $i -lt 36 ] && /var/media/ftp/startup.sh &

und mein startup-script:
# cat /var/media/ftp/startup.sh

trap '' SIGHUP
trap '' SIGTERM
# startup script FB 7390
# to be placed into /var/media/ftp (the root of the internal storage)

echo USB startup script running in 15s
sleep 15
echo starting extended services NOW

# start openVPN
echo start openVPN
cd /var/media/ftp/openvpn
sh ./server.sh &


# start SVN server
echo start SVN
cd /var/media/ftp/Storage-01/svn/
./svnserve -d -r ./

cd /var/media/ftp

# start the Dyndns-checker loop
/var/media/ftp/dyndnstest.sh &
echo "dyndns watcher started"
echo

echo "USB Startup script finished."
sleep 1

Wenn ich für den svnserve auch ein extra script wie für den openvpn mache, läuft es nicht bzw. wird gekillt.
Wenn ich irgendwas an der Reihenfolge oder den sleeps drehe läuft auch nix mehr.
Auf jeden Fall fass ich die FB jetzt momentan nicht mehr an, da es so läuft.

Für eine fachlich versierte Erklärung des Verhaltens (vor Allem wo die Kill-Signale herkommen) wär ich auch dankbar.

Aufgrund der Probleme muss ich auf meinen geliebten dyndns-checker-scriptloop verzichten. :-(

Beste Grüße!

Fabi