ds-mod und debug.cfg

TheChaos

Mitglied
Mitglied seit
23 Apr 2004
Beiträge
479
Punkte für Reaktionen
0
Punkte
0
Hi,

ich habs gestern endlich geschafft mir ein eigenens Firmware-Image zu erstellen. Habe das gestern für eine FB 5010 alles nach Anleitung gemacht und am Ende Firmware-Version 23.04.15ds-0.2.9 raus bekommen. Ich will eigentlich die ds-mod Features garnicht, ich hab nur eine einfache Möglichkeit gesucht, ein eigens compiliertes Prog in die Box dauerhaft zu bekommen. Das hat auch wunderbar geklappt.

Das ds-mod war auch anfänglich über das Webinterface der Fritz.Box verlinkt und das zeigt ja auf http://fritz.box:81 . Allerdings als ich die debug.cfg auf der Box erstellte und meine benötigten Sachen eintrug war das ds-mod von nun an nicht mehr erreichbar. Lösche ich die debug.cfg wieder, läuft das ds-mod! Sehr merkwürdig, wie ich finde, da ich hier gelesen habe, dass das ds-mod eigentlich nix mit der debug.cfg zu tun hat.

Vielleicht kann mir ja jemand den Zusammenhang näherbringen!

Danke!
 

danisahne

Aktives Mitglied
Mitglied seit
30 Jul 2005
Beiträge
1,493
Punkte für Reaktionen
0
Punkte
0
Wie sieht denn deine debug.cfg aus? Sie sollte kein exit oder eine Endlosschleife enthalten, weil dann wird der ds-mod danach nicht mehr gestartet.

Mfg,
danisahne
 

olistudent

IPPF-Urgestein
Mitglied seit
19 Okt 2004
Beiträge
14,779
Punkte für Reaktionen
10
Punkte
38
Kann es sein, dass du was in die debug.cfg geschrieben hast, dass die Ausführung des dsmod verhindert?

MfG Oliver
 

TheChaos

Mitglied
Mitglied seit
23 Apr 2004
Beiträge
479
Punkte für Reaktionen
0
Punkte
0
olistudent schrieb:
Kann es sein, dass du was in die debug.cfg geschrieben hast, dass die Ausführung des dsmod verhindert?

MfG Oliver
ja nette Hypothese ;) dachte ich mir ja auch schon, wobei dagegen sprach, dass es ja heisst, dass die debug.cfg unabhängig vom ds-mod (und andersrum) ist.

die debug.cfg sieht so aus
Code:
sleep 15
echo "CMD=\"dbclient argument1 argument2\"" > /var/flash/dbClientCfg
studnetLogin.sh
kurze Erklärung: dbclient ist ein präparierter dropbear ssh client, der mir eine dauerhafte Verbindung zu einem Anmeldeserver herstellt, sonst kommt man hier nicht ins Uni-Netz. das Shell-Skript läuft nun in einer Endlosschleife um abgebrochene Verbindungen wieder aufzunehmen. Und da könnte jetzt der Fehler liegen: da es unendlich läuft wird die debug.cfg nicht abgearbeitet. Wusste nicht, dass sich das auf das mod auswirkt
Ein "studnetLogin.sh &" sollte doch dann reichen oder?

Danke schonmal!
 

olistudent

IPPF-Urgestein
Mitglied seit
19 Okt 2004
Beiträge
14,779
Punkte für Reaktionen
10
Punkte
38
Genau. Wenn du das Skript im Hintergrund startest, so dass die Startdateien weiterverarbeitet werden, dann sollte das klappen.
Code:
(sleep 15;echo "CMD=\"dbclient argument1 argument2\"" > /var/flash/dbClientCfg;studnetLogin.sh)&
Eventuell auch so. Musst du mal probieren.

MfG Oliver
 

TheChaos

Mitglied
Mitglied seit
23 Apr 2004
Beiträge
479
Punkte für Reaktionen
0
Punkte
0
vielleicht könntet ihr mir nochmal kurz helfen:
wenn ich mein dbclient in den hintergrund starten will, klappt mein login leider nicht. da dachte ich mir, screen ist doch DIE alternative. hab ich eben nochmal ein neues Firmware erstellt um screen auf der box zu haben. Wenn ich aber "screen" eingebe bekomme ich nur den error
Code:
Cannot access //.screen: No such file or directory
hab schon versucht unter /var/tmp ein File .screen anzulegen, aber es läuft einfach nich :(

biiittteee hilfe ;)
 

TheChaos

Mitglied
Mitglied seit
23 Apr 2004
Beiträge
479
Punkte für Reaktionen
0
Punkte
0
muss ich hierfür echt noch ein neues Thema eröffnen? Irgendjemand muss doch schonmal screen benutzt haben, vor allem danisahne vielleicht?! :)

daaaanke!!
 

olistudent

IPPF-Urgestein
Mitglied seit
19 Okt 2004
Beiträge
14,779
Punkte für Reaktionen
10
Punkte
38
Ich hab das Screen-Package testweise in meine Firmware gebaut. Und bei der Eingabe von "screen" startet alles wie es soll.

Mfg Oliver
 

jesus.christ

Mitglied
Mitglied seit
25 Jun 2005
Beiträge
494
Punkte für Reaktionen
0
Punkte
0
Das ist richtig. Im ds-mod läuft das Screen-Package tadellos.
Gruß Niko
 

TheChaos

Mitglied
Mitglied seit
23 Apr 2004
Beiträge
479
Punkte für Reaktionen
0
Punkte
0
olistudent schrieb:
Ich hab das Screen-Package testweise in meine Firmware gebaut. Und bei der Eingabe von "screen" startet alles wie es soll.

Mfg Oliver
danke dir vielmals. das verwundert mich jetzt umso mehr :( dann kann es doch fast nur an meiner 5010 liegen oder? na gut ich bastel dann mal weiter und meld mich bestimmt nochmal ;(
 

olistudent

IPPF-Urgestein
Mitglied seit
19 Okt 2004
Beiträge
14,779
Punkte für Reaktionen
10
Punkte
38
Ich hab jetzt keine Idee wo das herkommen könnte. Es gibt einmal das Wrapper-Skript "screen" und dann das eigentliche Binary "screen.bin". Schau mal von wo der Fehler kommt.

MfG Oliver
 

TheChaos

Mitglied
Mitglied seit
23 Apr 2004
Beiträge
479
Punkte für Reaktionen
0
Punkte
0
das kommt bei beidem, egal was ich starte. wenn dann müsste ich aber nur "screen" starten, weil das ja Variablen setzt, oder?! aber der fehler ist bei beiden da.
mir kam gerade noch die idee, dass es noch daran liegt, dass wie oben beschrieben, ds-mod aufgrund der "Ungereimtheiten" in der debug.cfg nicht richtig lädt. ich hatte heut noch keine Zeit das zu testen. werde ich spätestens am Montag machen können. ich meld mich nochmal! ;)
 

TheChaos

Mitglied
Mitglied seit
23 Apr 2004
Beiträge
479
Punkte für Reaktionen
0
Punkte
0
sooo, leider wie zu erwarten war, keine Verbesserung. Das dsmod Webinterface läuft und nix blockiert mehr den Ablauf der debug.cfg

Aber weiterhin, wenn ich mich per Telnet einlogge und auf der Console "screen" eingebe kommt
Code:
Cannot access //.screen: No such file or directory
Am Wrapperscript liegts nicht, da kann er meines Wissens nach alles finden. Also irgendwie geht die screen.bin-Anwendung nicht. Liegts an meinem Box-Typ oder hätte ich noch was ins Kernel compilieren müssen? Ist echt doof leider so und vor allem unverständlich.

Vielleicht habt ihr ja ne Idee!
Danke!
 

danisahne

Aktives Mitglied
Mitglied seit
30 Jul 2005
Beiträge
1,493
Punkte für Reaktionen
0
Punkte
0
In dem Wrapper Skript werden aber ein paar wichtige Umgebungsvariablen gesetzt. Geht es bei dir auch mit Wrapper Skript nicht?
 

TheChaos

Mitglied
Mitglied seit
23 Apr 2004
Beiträge
479
Punkte für Reaktionen
0
Punkte
0
vielleicht hab ich es ungeschickt formuliert. ich habe die Einträge
Code:
[ -f "$TERMINFO"/*/"$TERM" ] || export TERM=xterm
touch /var/run/utmp
überprüft. Wenn ich mit Putty eingeloggt bin, sehe ich das passende terminfo. auch /var/run/utmp existiert.
Starten tu ich das ganze natürlich über /usr/bin/screen und der besagte Fehler kommt!
 

danisahne

Aktives Mitglied
Mitglied seit
30 Jul 2005
Beiträge
1,493
Punkte für Reaktionen
0
Punkte
0
Die TERMINFO Variable auch? Das terminfo Verzeichnis ist auch dabei?
 

TheChaos

Mitglied
Mitglied seit
23 Apr 2004
Beiträge
479
Punkte für Reaktionen
0
Punkte
0
also
Code:
export TERMINFO=/mod/pkg/screen/usr/share/terminfo
setzt doch den Wert von terminfo eh, das kann ich ja auch schlecht überprüfen, da es ja nur für die laufende Shell gilt
und
Code:
TERM='vt102'
ist ja auch korrekt. demzufolge existiert auch /mod/pkg/screen/usr/share/terminfo/v/vt102
und wie gesagt /var/run/utmp existiert auch.
also weiss ich persönlich auch nicht mehr worans liegen soll :(
 

danisahne

Aktives Mitglied
Mitglied seit
30 Jul 2005
Beiträge
1,493
Punkte für Reaktionen
0
Punkte
0
TheChaos schrieb:
demzufolge existiert auch /mod/pkg/screen/usr/share/terminfo/v/vt102
Existiert es auch wirklich? Der Folgerung "demzufolge" kann ich irgendwie nicht ganz folgen.

Mfg,
danisahne
 

TheChaos

Mitglied
Mitglied seit
23 Apr 2004
Beiträge
479
Punkte für Reaktionen
0
Punkte
0
naja, mit demzufolge war gemeint, wenn das Termn so heisst muss auch die Datei so heissen und sie existiert
Code:
~ # ls -l /mod/pkg/screen/usr/share/terminfo/v/vt102
-rw-r--r--    1 root     root         1141 Jan  4  2005 /mod/pkg/screen/usr/share/terminfo/v/vt102
ein "cat" bringt mir cryptisches Output.

Kannst du dir wenigstens vorstellen, was die Fehlermeldung mit "//.screen" meint? Ist das irgendeine Settingsdatei die er sucht oder wie kann man das verstehen? Es ist echt zum verzweifeln ;(
 

kriegaex

Aktives Mitglied
Mitglied seit
7 Nov 2006
Beiträge
2,927
Punkte für Reaktionen
0
Punkte
0
Was es mit .screen auf sich hat

TheChaos schrieb:
Kannst du dir wenigstens vorstellen, was die Fehlermeldung mit "//.screen" meint? Ist das irgendeine Settingsdatei die er sucht oder wie kann man das verstehen?
Jein, keine Datei, sondern ein Verzeichnis. Es ist das sog. "socket directory" (vgl. Screen-Manual), welches standardmäßig im Home-Verzeichnis des Benutzers angelegt wird. Da der Benutzer normalerweise root und sein Home-Verzeichnis üblicherweise / ist, versucht screen, das Verzeichnis dort anzulegen, was scheitern muß - es handelt sich schließlich um ein Read-Only-Dateisystem.

Lösung: Sofern die Umgebungsvariable SCREENDIR existiert, verwendet screen das dort angegebene Verzeichnis als socket directory. Man muß es auch nicht manuell anlegen, Screen erledigt das. Automatisch gelöscht wird es nach Ende des Screen-Prozesses allerdings nicht, ist aber auch egal. Also in die debug.cfg oder das Startskript von Screen Folgendes eintragen (oder eben an der Kommandozeile eingeben):
Code:
export SCREENDIR=/var/tmp/.screen
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
231,870
Beiträge
2,016,188
Mitglieder
348,966
Neuestes Mitglied
bilgehz