[Gelöst] usbroot und lighttpd funktionieren nicht zusammen

[linuxuli]

Hallo,

ich habe 7270_labor_wlan_04.98freetz-devel-3163.de unter anderem mit den Paketen usbroot und lighttpd. Das Datenverzeichnis von lighttpd ist auf der 2. Partition der USB-Platte.
Ist usbroot nicht aktiv, funktioniert alles prächtig.

Aktiviere ich usbroot und die Box startet von der USB-Platte passiert folgendes:

• Die Partitionen der Platte sind nicht gemountet.
• lighttpd wird nicht mehr automatisch gestartet. rc.lighttpd hängt, weil das Datenverzeichnis nicht gefunden wird.

Ich kann das Problem beheben, in dem ich in /etc/static.pkg entweder usbroot an den Anfang setze oder lighttpd ans Ende.
Ist es möglich, die Reihenfolge der Einträge in der /etc/static.pkg beim build festzulegen? Entwicklungstechnisch habe ich keine Ahnung, bin aber gerne bereit, einen Patch auszuprobieren.

Danke und Grüße
Uli

 

[RalfFriedl]

USB-Root funktioniert derzeit nicht in Verbindung mit Auto-Mount.

Die Reihenfolge wird festgelegt durch die Werte von $(PKG)_STARTLEVEL (default 40, ganz aus 99).

 

[derheimi]

USB-Root funktioniert derzeit nicht in Verbindung mit Auto-Mount.

Was ist da genau das Problem? Bei mir werden diverse FAT-Partitionen trotz USB-Root eingebunden, weil USB-Root die Hotplug-Ereignisse abfängt, zwischenspeichert und später beim Starten des USB-Root Skriptes dann erst verarbeitet. Das würde sich auch mit der Beobachtung (es geht wenn USB-Root als erstes läuft) decken.

@linuxuli:
Ralf meint, dass Du in der Datei make/usbroot/usbroot.mk in der zweiten Zeile mal folgendes hinzufügst:
$(PKG)_STARTLEVEL=01

Dann Image neu bauen, etc. Bitte Rückmeldung hier geben.

 

[RalfFriedl]

Was ist da genau das Problem?

Ich kann mich nur erinnern, davon gelesen zu haben, ich verwende kein USB-Root. Vielleicht ist das Problem inzwischen auch gelöst,

 

[Silent-Tears]

Ich hab irgendwie in Erinnerung, dass bei Verwendung ovn USB-Root alle anderen Partitionen nicht gemounted werden automatisch. Allerdings steht einem nachträglichen Mount per debug.cfg oder rc.custom nichts im Wege.

 

[olistudent]

@derheimi
Du hattest doch diese Serialisierung eingebaut? Wann werden die Abgefangenen Ereignisse denn ausgeführt?

MfG Oliver

 

[linuxuli]

Hallo,

@derheini
auf Grund Ralfs Antwort habe ich in make/usbroot/usbroot.mk in der ersten Zeile $(PKG)_STARTLEVEL=10 eingetagen, ohne Erfolg. Die genaue Position wird wohl keine Auswirkung haben, oder?
Die Startreihenfolge blieb danach anscheinend gleich (static.pkg) und es hat dadurch nicht funktioniert. Auch nicht nach dirclean.
In der Buildumgebung steht in ".static" immer noch "S99usbroot-0.2" drin.
Werde noch einen Versuch machen, mit genau deinem Eintrag in einem neuen Verzeichnis.

Vielleicht noch ein ergänzender Hinweis:
Das Problem ist, dass beim Systemstart rc.lighttpd hängen bleibt, weil das Datenverzeichnis nicht gefunden wird. Das Startskript geht dann in eine Schleife, die alle 5 Sekunden nach dem Datenverzeichnis sucht und sich erst beendet, wenn dieses gefunden wird. Dadurch werden alle nachfolgenden Startskripte nicht mehr ausgeführt, auch usbroot nicht. Kille ich rc.lighttpd, werden die nachfolgenden Startskripte ausgeführt und damit auch usbroot.
Die Platten sind dann auch richtig gemountet.
Vielleicht ist damit das gravierendere Problem das Startskript von lighttpd, welches bei fehlendem Datenverzeichnis den Start der nachfolgenden Skripte verhindert. Ist es möglich, dass sich das Startskript in diesem Fall selbst in den Hintergrund schickt, damit die nachfolgenden Startskripte auch noch ausgeführt werden?

Gruß Uli

 

[olistudent]

http://trac.freetz.org/changeset/3167

MfG Oliver

 

[linuxuli]

Fehler mit changeset 3167 behoben.
Danke an alle Helfer.

Gruß Uli

 

[mehle]

Vielleicht noch ein ergänzender Hinweis:
Das Problem ist, dass beim Systemstart rc.lighttpd hängen bleibt, weil das Datenverzeichnis nicht gefunden wird. Das Startskript geht dann in eine Schleife, die alle 5 Sekunden nach dem Datenverzeichnis sucht und sich erst beendet, wenn dieses gefunden wird. Dadurch werden alle nachfolgenden Startskripte nicht mehr ausgeführt, auch usbroot nicht.
Gruß Uli

Dies ist ja gar nicht fein. Danke für den Hinweis. Ich werde das Startskript noch überarbeiten, damit es im Hintergrund läuft.

Ciao
Stephan

 

[mehle]

Hier ein Patch des Startskripts, welcher den Startvorgang von lighttpd in den Hintergrund schiebt. Damit sollten die Probleme mit dem Blocken grundsätzlich nicht mehr auftreten.

Ein weiterer kleiner Update ist drinnen, damit die Konfigdatei nicht immer sofort gelöscht wird, falls ein Fehler auftritt.

Dieser Patch ist unabhängig von meinem anderen -24 Patch gegen trunk 3185.

Patch getested.

Danke
Stephan

 

[olistudent]

[SIZE=2]
[LEFT]while [ ! -d "$LIGHTTPD_DOCROOT" ]; do
echo "Docroot $LIGHTTPD_DOCROOT not yet available, sleeping"
sleep 5[/LEFT]
done

Schleifen ohne Abbruchbedingung sind nicht gut... ;-)

MfG Oliver
[/SIZE]

 

[mehle]

Schleifen ohne Abbruchbedingung sind nicht gut... ;-)

Nunja, hast du einen Vorschlag, was ich machen soll? 10 Durchläufe?

Ciao
Stephan

 

[linuxuli]

Hallo,
bitte auch ins error.log protokollieren.
Das erleichtert die Fehlersuche.
Gruß Uli

 

[mehle]

Hier ein neuer Versuch, er ersetzt den alten -25 Patch und ist gegen trunk, unabhängig von -24.

- start() wird nicht im Hintergrund ausgeführt
- jedes Verzeichnis, welches geprüft wird, wird nur 10 mal geprüft, danach wird der Start von lighttpd abgebrochen

@linuxuli: was meinst du mit logging und error.log?

Ciao
Stephan