Also wie willst du es genau machen?

1. Soll das Script per FB ausgeführt werden?
2. Soll das Script über Telnet ausgeführt werden?
3. Soll das Script selbständig den Daemon überwachen?

Letzteres wird schwierig werden. Variante 1 erfordert ein Plugin geschrieben in C bzw. benötigst du ein Plugin (Name fällt mir gerade nicht ein) mit dem es möglich ist Scripte auszuführen. Allerdings ist die Frage, wenn der Daemon hängt, ob man dann noch die Box mit der FB bedienen kann? Keine Ahnung? Das mußt du wissen.

Der einfachste Weg wäre Variante 2, sofern du noch Zugriff via Telnet zur Box hast, unter deinen beschriebenen Bedingungen.

Das Script dafür sieht recht einfach aus, ersetze den Namen des Daemons (/sbin/dein_daemon) nur durch den richtigen Namen des Daemons auf der Box.

#!/bin/sh
DAEMON="/sbin/dein_daemon"


# Überprüfe Prozess und beende Daemon
while pidof $DAEMON >/dev/null ; do
 	killall -9 $DAEMON
	sleep 1
done
# Verweilzeit bevor der Daemon neu gestartet wird
sleep 1
# Starten des Daemons im Background
$DAEMON &


exit 0

Zitat

Wenn ich ein Skript hätte das automatisch den Tuxmail-Daemon
killt und dann gleich wieder startet wäre toll.

Die Frage ist, unter welchen Bedingungen das Script den Daemon killen soll.
Also kurz gesagt, wie macht man dem Script klar (erkennt das Script), daß der Daemon hängt. Über den sonst üblichen Weg der Prozess ID funzt das jedenfalls nicht.

cheers

Zitat

Liegt es vielleicht daran, das der Daemon das WebIF-Binary nicht gleich mitstartet? Wenn ja - könntest du bitte eine mit "--enable-webserver" compilierte Version bereitstellen?

Die Fehleraussage kannst du getrost ignorieren. Ich habe die Option --enable-webserver angegeben, sonst hättest du ja schliesslich auch keinen Webserver namens amuleweb oder.

Ich denke das größte Problem ist hier der Betrieb in einer chroot Umgebung. Da ich unmöglich vorher die Zustände eines jeden Images wissen konnte habe ich versucht das Startscript so kompatible wie möglich zu machen. Leider scheint das bei einigen nicht zu funzen. Herumprobieren mit anderen Pfaden und Verzeichnissen, ohne dabei das Startscript, bzw. die configs von amule anzupassen führen dann zu solchen Fehlermeldungen. Ich habe die Versionen auf verschiedenen Dreamboxen testen können. Bei mir gab es nie Fehler dergleichen, vorrausgesetzt, man konfiguriert und startet mittels Startscript amule auch korrekt.

Zitat

denke ma schon das der Pfad so ok ist da ich ja per telnet amule auch so starten kann...
swapfile habe ich auch aktiviert

Muß nicht zwangsläufig so sein, da zwischen der Pfaden des eingeloggten root via telnet und den Pfaden beim Hochfahren der Box ein Unterschied bestehen kann. Die Pfade für die telnet session stehen in /etc/profile und der export der Pfade bei der Startprozedur in /etc/init.d/rcS.

cheers

Zitat

Ich hab den Daemon mit chroot /hdd/amule amuled -f gestartet, da es die Funktion -q dort nicht gibt
Dieser arbeitet auch im Hintergrund - wenn ich dann aber versuche das WebIF per Hand zu starten kommt nur folgendes:

Ja sorry, ich meinte auch amuled -f

Hast du nach dem Starten mit

chroot /hdd/amule amuled -f

mal überprüft ob das webif schon läuft ?
amuled starte amuleweb automatisch mit, wenn die Pfade stimmen.

Hast du vor der Startprozedur auch wirklich das HOME-Verzeichnis exportiert.
Das ist wichtig, da dort die Konfigurationen gespeichert werden.

export HOME=/

ist hier nötig, da in der chroot Umgebung ( /hdd/amule ) das Home-Verzeichnis in "/" sitzt und die configs nach /.aMule geschrieben werden.

Sind die Passwörter in der /hdd/amule/.aMule/amule.conf die selben wie in der /hdd/amule/.aMule/remote.conf ?

Du hast in der remote.conf auch 2 unterschiedliche Passwörter verwendet, wenn man von der Länge der pwd's ausgehen kann. Versuche mal alle Passwörter gleich zu setzen. Vorher aber alle Prozesse von amuled und amuleweb beenden!!

Also in der amule.conf

Password=ECPassword

und in der remote.conf

Password=AdminPassword

Also kurz gesagt.

Password=ECPassword=AdminPassword

Dann versuche nochmal den Neustart von amuled -f.

PS: Die illegal instruction Ausgabe ist normal. Die kommt immer, wenn sich amuled bzw. amuleweb beendet. Warum das bei der statisch gelinkten Version so ist, habe ich bis heute nicht herausgefunden. Es beeinflußt aber die Funktion des Esel in keinster Weise.

cheers

amuled ist ja auch nicht das Webinterface, sondern der Daemon und der wird ja gestartet, so wie es die Fehlermeldung des Scriptes ausgibt.

Ich weiß nicht wo die Probleme bei einigen Images liegen. Bei mir klappte es bisher bei jedem Image, was ich nutzte, auch aktuelle.

Ein Versuch wäre aber mal folgendes.
Das /hdd/amule/dev/urandom löschen und nicht mounten, sonder mit mknod ein neues /dev/urandom in /hdd/amule erzeugen.
Danach den esel mal manuelle starten.

Also:

umount /hdd/amule/dev/urandom
rm -rf /hdd/amule/dev/urandom
mknod -m 755 /hdd/amule/dev/urandom c 1 9
cd /
export HOME=/
chroot /hdd/amule amuled -q

amuled startet normalerweise das webinterface automatisch mit.
ein ps -aux zeigt dann, welche Prozesse vom esel laufen.

By the way, warum nehmt ihr nicht die 2.13er Version zum testen?

cheers

PS: Ja ich weiß, ich wollte ein neues Release rausbringen und ein Plugin basteln. Leider sind mir ne Menge Arbeiten am Auto dazwischen gekommen. Ist halt Scheiße, wenn einem der Zahnriemen bei 150 reißt. Hat man ebend mal die Chance seinen Motor zu zerlegen.

Zitat

Meine init sieht so aus:

/var/wifi/wifistart.sh
# EPGRefresh starten
/var/bin/epgrefresh.sh &

Wenn dein Eintrag so aussieht kann amule auch nicht starten.
Ich nehme aber an, du hast die init wie folgt abgeändert und es damit mal versucht, wie schon beschrieben:

/var/wifi/wifistart.sh
# EPGRefresh starten
/var/bin/epgrefresh.sh &
/hdd/amule/bin/amule

Wenn das nicht geht mußt du evtl. vor dem Start von amule dein Swapfile aktivieren, sonst kommt es vor, daß das webif wegen fehlendem Speicher versagt.

By the way, welche Version benutzt du denn?
Bei den älteren Versionen, die ich portiert habe ist natürlich die Dateistruktur ein wenig anders. Dort befinden sich die Tools in /hdd/aMule.
Also wäre hier ein

/hdd/aMule/amule

angebracht.

Gruß

Bei der 7000er Box mußt du nur eine Datei /var/etc/init erstellen, wenn noch nicht vorhanden und die Rechte (755) vergeben. Füge dann folgende Zeile ein

/hdd/amule/bin/amule

und der esel wird bei jedem Hochfahrn der Box mitgestartet. Ob das allerdings auf Dauer gut geht, heißt daß man die Box auch weiterhin nutzen kann wofür sie gedacht ist (Fernsehen), wird sich herausstellen. Spätestens wenn ein paar Files im Download hängen, hat der esel gut zu tun.

Gruß

Auch meinerseits besteht auf jedenfall Interesse. Die Frage ist nur, ob sich Dream darauf einlässt.

cheers

Hey mamba0815 lies dir doch mal diesen Thread von Anfang an durch, dann wirst du zwangsläufig auf den Port für den ppc gestoßen. Habe ich schon vor 1/2 Jahr released, wenn man es so nennen kann, zumindest für die 7000er.

Gruss

Achso, dann habe ich das natürlich falsch verstanden. So macht das mit dem Plugin natürlich Sinn.

Warum hübsch verpacken? Wer es haben will, soll es nehmen wer nicht, der wird nicht wissen was ihm entgeht. Ich bin sowieso der Meinung, wer auf der Dream nicht wenigstens ein wenig mit der Konsole umgehen kann lernt die Vorzüge der Box nie kennen, es sei denn er hat sich die Box nur wegen den Laufvögeln gekauft.

Bezüglich Abhängigkeiten wirst du auf der Dreambox immer Probleme haben. Das liegt mit unter daran, daß du nie vorweg weißt auf welchem Image welche Funktionen aus den libs gestrippt wurden. So bleibt dir entweder ultimatives probieren oder gleich den ganzen Kram statisch zu linken, damit das Tool auf jedem Image rennt. Dadurch sinkt aber schnell die Performance und der freie Speicherplatz.

Ich habe lange überlegt wie ich das bewerkstelligen könnte bezüglich der Crossumgebung, bin dann aber zum Schluß gekommen, daß man für volle Kompatibilität das mitgelieferte Development Image nutzt, bzw. die Tools und libs aus dem Image + das Develpackage in einer chroot Umgebung verpackt und von beliebigem Image mountet. Bei mir laufen die meisten Prozesse sowieso in dieser chroot, denn ich habe das nervige libs tauschen in jedem Image satt, das manchmal auch zu Problemen führen kann. So kann ich beispielsweise Perlskripte, Pythonscripte wie auch das mklibs.py auf der Box von beliebigem Image aus laufen lassen.
Übrigens baue ich auch auf diese Weise aMule auf der Box.

cheers

Zitat

Was hälst Du denn von der Idee, GCC und co. so zu kompilieren, dass diese Pakete ihr "Root-Verzeichnis" in "/usr/local" haben?

Und "/usr/local" würde man dann per symbolischen Link auf die Festplatte legen.

/usr/local ist ne gute Sache, zählt zumindest zu den Standart Suchpfaden. Aber bitte keine Symlinks. Ich bin ein echter Hasser von Symlinks in diesem Zusammenhang, denn es bringt nur unnötig Ärger. Besser ist allemale "mount -o bind Quelle Ziel". Also erstelle einen Ornder local unter /usr und mounte den ganzen Kram auf beliebigem Medium dorthin. Ist ein Befehl und alles in einem Abwasch am richtigen Platz.

Zitat

Und ich würde auch gerne ein kleines Compiler Plugin basteln damit man es komfortabler beim installieren und verwenden des Ganzen hat.

Also das müsstest du mal erklären, wie das funktionieren soll. Geht es um das reine Compilieren ist man doch allemale schneller mit einer Crossumgebung bzw. via telnet auf der Dreambox. Warum ich die Entwicklungsumgebung gebaut habe war zum einem der Grund, dass man damit einige Sachen local compilieren kann, die nur mit viel Aufwand und Änderungen der Sourcen in einer Crossumgebung zu verwirklichen waren. Beispiel Perl und auch noch Python soweit ich das noch in Errinnerung habe. Ich kann mir aber beim besten Willen nicht vorstellen, das ich auch nur die geringste Lust dazu hätte via FB irgendwas auf der Box zu compilieren.

cheers

Zitat

Wegen des hohen Speicherbedarfs installiere ich die Pakete auf der Festplatte.
Ist ideal, so braucht man nach einem Imagewechsel den ganzen selbstgebauten Spass nicht neu zu installieren und konfigurieren.

Hatte ich anfangs auch so gemacht. Aber warum nicht gleich nach /usr.
Zumindest lässt sich ein /usr Verzeichnis ja irgendwie immer sinnvoll auf der Box mounten. Warum /usr ? Weil beim Bauen mit dem besagtem configure Script immer meist nur in den Standart Pfaden /usr, /bin, /usr/local usw. nach den benötigten Tools gesucht wird. Setzt man seinen gcc + Tools gleich in /usr an, ersparrt einem das im Nachhinein ne Menge unnötigen Arbeit bei der Configuration zum Bauen diverser Tools. Manche Sourcen akzeptieren auch keine anderen Suche Pfade trotzt richtig gesetzter Umgebungsvariablen. Also hilft dann nur noch patchen.

Ich habe meine Packages alle nach /usr installiert. Gepackt wird dann der ganze Kram auf USB oder CF und als /usr gemountet. Alternativ kann ich auch das ganze Package von jedem Images aus als chroot betreten und von dort aus wird der gcc etc. immer in /usr gehandelt. Ist wesentlich besser als vorweg den Pfad des gcc irgendwo in /hdd festzulegen. Ist nur ein Typ um etwas Zeit zu sparen.

cheers

Zitat

Jemand hat sich schon eine komplette Entwicklungsumegbung auf der Dream gebaut zum Compilieren und Linken, du müßtest also nicht das Rad neu erfinden.

Ja gut ich habe die Entwicklungsumgebung für dei Dream portiert. Allerdings für die 7000er. Da dort das komplette CVS noch mit Makefiles in einer Crossumgebung realisiert ist das doch ein Unterschied zum open embedded (mit monotone) etc.

Es ist nicht einfach damit getan ein paar Änderungen in diversen Files zu machen. Normalerweise ist es ja auch nicht von Nöten einen Compiler in das Image einzubinden. Somit ist das CVS auch dafür nicht vorbereitet. Es bedarf also einiger Änderungen und Patches. Die Fehler kommen evtl. davon, dass du versuchst einen Crosscompiler in dein Image einzubinden. Damit wirst du aber auf der Box keinen Spass haben, denn der Crosscompiler funktioniert nur auf dem PC. Was du tun musst nennt sich "Canadian Crosscompile" (na nicht ganz) und sieht vereinfacht wie folgt aus.

1. Baue Binutils für BUILD=x86 und HOST=ppc
2. Baue Stage1 crosscompiler für BUILD=x86 und HOST=ppc ohne Verwendung von glibc.
3. Baue glibc mit Stage1 cross-gcc für HOST=ppc
4. Baue Stage2 (finished) Crosscompiler für BUILD=x86 und HOST=ppc mit glibc für HOST=ppc.

Das sind in etwa die Schritte, die auch im CVS gemacht werden. Nun hast du den Crosscompiler der Codes für ppc erzeugt und auf deinem PC (x86) läuft. Damit baust nun einen localen Compiler der auf deinem TARGET=ppc läuft und Codes für das TARGET=ppc erzeugt.

Also der ganze Kram wie oben wiederholst, nur das diesmal nicht mit dem gcc deiner x86 Machine compiliert wird, sondern mit dem Crosscompiler. Quasi ein BUILD=x86, HOST=ppc, TARGET=ppc. -> Baue einen Crosscompiler mit dem du einen Compiler für die Dream bauen kannst.

Es ist also ein Unterschied, auf welcher Platform ein Compiler lauffähig ist und für welche Platform er Codes erzeugt (übersetzt -> compiliert). gcc eignet sich aber dafür am besten, da der gnu compiler für die meisten Platformen portierbar ist.

Das fertige Package gibt es übrigens unter h**p://imageonhd.info zum downloaden + Anleitung. Erfordert allerdings eine Registrierung im Forum.
In wie weit der ganze Kram (dazu gehört wesentlich mehr als nur gcc und die binutils) auf der 7020 funktionieren, habe ich nicht getestet. DXler hat dort im Forum aber die ganze Sache auf seiner 7020er zu laufen.

cheers

Zitat

Lediglich mit dem TUXBOX-Commander kann man Programme starten oder über das Scriptplugin Scripte starten.

Nein, du kannst alle Proggis (auch Scripte) der Dreambox problemlos mit einer Telnet Session vom PC aus starten. TUXBOX-Commander macht sicher nichts anders (Vermutung).

cheers

Hab das Problem mit dem kill von amuleweb gefunden. Erstaunlicherweise konnte man bei der ganzen configure-make Prozedur trotzt fehlender libgd den esel bauen. Genau aber libgd wird unter anderem zum dynamischen Erzeugen der besagten Dateien benötigt. Jetzt funzt auch die Graph Anzeige wieder. Ich werde in den nächsten 2 Wochen das Package nochmal zur Verfügung stellen.

cheers

Mhh, ich könnte bei Gelegenheit mal die Makefiles dafür reinstellen.
Allerdings ist das Makefile für das crosscompilen auf das opendreambox der dream 7020 abgestimmt, zumal hier auch ein paar Kleinigkeiten gepatched werden müssen, sonst gibts nen Error beim Builden.
Für die Dreambox 7000 compiliere ich alle amule Daemons local auf der Dreambox und nicht mit dem CVS. Deswegen wird das Makefiles dafür den wenigsten was bringen.

cheers

Habs dir mal schnell compiliert und in den Anhang gepackt. Ungetestet !
Entpacke das Archiv und schiebe sdparm nach /sbin. Rechte vergeben nicht vergessen. (chmod 755 /sbin/sdparm).

Wenn es Probleme mit irgendwelchen libs beim Starten gibt, sag Bescheid, dann baue ich sdparm nochmal schnell statisch für Dich.

Gruß

Die Fehlermeldungen sind nicht weiter tragisch, da die besagten Dateien in dem Chicane Skin nicht enthalten sind. Warum die Dateien fehlen kann ich nicht sagen. Vielleicht ein Fehler von mir oder von amule? Ist halt nicht so einfach den ganzen s*it wx Kram zu patchen.

"amuleweb" startet ja trotzdem, wie du schon sagtest mit der -w Option.
Das habe ich ja extra in das amule Script eingebaut, damit man amuleweb wahlweise beenden (amule -r) und und neu starten (amule -w) kann, ohne dabei jedesmal den Esel zu killen. Ein "amule -h" gibt noch mehr Auskunft über mögliche Optionen.

Nochmal im Klartext:
amuled und amuleweb sind zwei getrennte Sachen, die "unabhängig" funktionieren! Bzw. funktioniert "amuleweb" nur mit laufendem "amuled".

"amuleweb" dient hier nur zur Steuerung des amule Daemon "amuled". Hat man einmal die Downloads mit Hilfe des Webif "amuleweb" gestartet, kann man "amuleweb" getrost beenden. "amuled" downloaded bei jedem Start automatisch die Dateien in der Warteschlange. Das alles wird von einem Script "amule" gesteuert. Das habe ich dazu gepackt, damit der Esel einfacher zum laufen zu bekommen ist. Es erfordert ebend eine gewisse Anpassung der Umgebungsvariablen bzw. des /dev/urandom auf der Dreambox. Die ganze Startprozedur jedesmal manuell zu erstellen nervt gewaltig.

cheers

Eigentlich hatte ich das Script so angepasst, daß es vor Beginn der Startroutine die benötigten Tools überprüft und sich beendet, wenn nicht vorhanden.
Leider kann man ja nicht alles austesten und amule scheint sich auf einigen Boxen unterschiedlich zu verhalten. Bei XTC99 ist es aber ein anderes Problem. Aus irgendwelchen Gründen akzeptiert amuleweb das /dev/urandom in der chroot Umgebung nicht. Deswegen der Abbruch. Komisch, obwohl mittlerweile die gleichen Images sowohl im Flash, wie auch auf dem Stick.

Ich werde diese Woche noch einmal eine amule Version für die 7000 portieren. Mal schaun, ob ich das /dev/urandom aus amule rausschmeißen kann? Außerdem will ich die Version pfadunabhängig gestalten.

Gruss

Zitat

gibts nicht auch ein /etc/motd (message of the day) file so wie bei anderen Unix ?

So weit ich das sehe, auf der 7000er zumindest nicht.

cheers