[Vorschlag] Race-Condition bei .start und .end Files

[GetAway]

Hier geht es mir um das verhindern von Race-Conditions zwischen der
movieplayer.start/.end, audioplayer.start/.end und pictureviewer.start/.end
Datei, wenn schnell, mehrmals hintereinder die jeweilige Anwendung gestartet,
beendet und wieder gestartet wird.

Es müßte eine Abfrage eingebaut werden die verhindert das die .start bzw .end
schon losläuft bevor die jeweils andere abgearbeitet ist.

[seife]

Die werden mit system() aufgerufen und system wartet, bis sie beendet sind.
Zeig mal ein Beispiel von so einem skript, evtl. schickst du ja da drin Befehle in den Hintergrund, dann bist du aber auch selbst schuld

Wenn in so einem skript daemons gestartet werden oder so, dann müssen die dafür sorgen, dass sie erst dann fork()en, wenn sie auch fertig initialisiert sind. Da kann neutrino aber nicht wirklich was dran machen.

[GetAway]

Die werden mit system() aufgerufen und system wartet, bis sie beendet sind.

Dagegen ist ja auch nichts einzuwenden.

evtl. schickst du ja da drin Befehle in den Hintergrund

Ja, mach ich. Das ändert aber nichts an der tatsache das die .start aufgerufen wird,
obwohl die .end noch läuft. Sie soll aber erst gestartet werden, wenn die .end
beendet ist und umgekehrt. Das sollte man in Neutrino doch hinbekommen.

Zeig mal ein Beispiel von so einem skript

.start

Code: Alles auswählen

#!/bin/sh
run() {
sleep 20 && killall -9 sectionsd 
}
run &
exit

.end

Code: Alles auswählen

#!/bin/sh
run(){
sleep 20
if [ -e /proc/clock ]; then
	sectionsd -tc
else
	sectionsd
fi
}
run &
exit

Wenn du 2 mal den MP schnell startest und beendest, siehst du mit "Top"
das die Prozesse movieplayer.sta und movielplayer.end 2x vorhanden sind.

[seife]

Schicke run() nicht in den Hintergrund.
Ich könnte natürlich auf alle child-Prozesse warten, aber das wäre exakt dasselbe, wie wenn du das "&" wegmachen würdest.

Die *.start und *.end sind eh nur workarounds für Bugs IMHO, also sollte man eher dafür sorgen, dass die nicht benötigt werden.

Sorry, aber im Bugzilla wäre das entweder RESOLVED WONTFIX oder RESOLVED WORKSFORME

(Eigentlich sogar "RESOLVED INVALID", weil du in deinem Skript einen groben Fehler machst )

[GetAway]

Ne, klar. Dann müßte man ja 20 Sekunden auf starten des MP warten.
Das die Klamotten im Hintergrund laufen ist schon OK. Das stört den MP
überhaupt nicht. Es wird ja eh erst das Filmarchiv bzw. der Filebrowser
geöffnet. Das die Scripte im Hintergund laufen hat noch einen Vorteil. Der MP
öffnet sich sofort.

Ich will ja nur wissen ob es machbar ist, daß das Script erst gestartet wird,
wenn das andere beendet ist. Und zwar in Neutrino.Wie gesagt, für mich ist
das ne Art Race-Condition, je nachdem wie die einzelnen Scripte Aufgebaut sind
gibt das subtile Fehler.

Ich würds ja selber mit pidof machen, aber die .start und .end geben nixx
zurück. Ich weiß nicht ob es an der länge des Scriptnamens (movieplayer.start)
liegt oder an dem Punkt im Scriptnamen Mit Top kann ich sie sehen.

[rhabarber1848]

pidof -x

Scripts too - this causes the program to also return process id's of shells running the named scripts.

Leider unterstützt Busybox diese Option nicht.

[seife]

Und warum willst du unbedingt 20 sekunden warten, vor du den sectionsd startest? (Abgesehen davon, dass sectionsdneustarten so sowieso nicht funktioniert ;-)). Mach halt in deine Skripten ein locking rein:

movieplayer.start: da musst du gar nicht warten. Oder soll der film schon mal loslaufen, und sectionsd erst dann gekillt werden? Wozu?

movieplayer.end:

Code: Alles auswählen

#!/bin/sh

lock() {
        local COUNT=0
        while [ -d /tmp/lock -a $COUNT -lt 10 ]; do
                sleep 1;
                COUNT=`expr $COUNT + 1`
        done
        if [ $COUNT -gt 9 ]; then
                return 1
        fi
        mkdir /tmp/lock 2>/dev/null
}

unlock() {
        rmdir /tmp/lock
}

if lock; then
        echo "locked!"
        unlock
else
        echo "could not lock"
fi

Somit kannst du dafür sorgen, dass immer nur ein movieplayer.end läuft. Neutrino kann da nichts für dich tun.
(Natürlich solltest du aufpassen, dass das lock-verzeichnis auch immer am Ende weggeräumt wird etc. Am besten auch, wenn unbeabsichtigt beendet wird, z.B. mit einem trap auf EXIT.

[GetAway]

@seife, vielen Dank ich werd's mal testen.
Hat mkdir Vorteile gegenüber touch?

Und warum willst du unbedingt 20 sekunden warten

Das war doch nur ein Beispiel , damit kann man halt gut erkennen
das es so ist wie es ist.

[seife]

mkdir ist atomic, und es schlägt fehl, wenn es das verzeichnis schon gibt. Touch tut das alles nicht.

und

Code: Alles auswählen

if [ ! -e /tmp/lock ]; then
	touch /tmp/lock
fi

Ist selbst wieder eine race-condition

Generell sollte man langandauernde sachen nicht in den .start/.end-skripten machen, zumindest nicht, wenn es sich vermeiden lässt. Dafür ist der Mechanismus einfach nicht ausgelegt.

Und ja, ich kenne das Problem:

Code: Alles auswählen

/var/tuxbox/config $ cat recording.start
#!/bin/sh
wakeup.sh
echo "start $(date)" >> /tmp/automount/record/.$(hostname).record
/var/tuxbox/config $ cat /var/bin/wakeup.sh
#!/bin/sh
wget -O - http://192.168.200.1:54321 # triggert platte-anlaufen auf dem server

Und wenn ich aus versehen eine Aufnahme starte, dann muss ich auch 10 Sekunden warten, bis die Platte angelaufen ist, und solange reagiert die Box nicht. Aber das liesse sich nur durch architekturale Änderungen in neutrino wirklich fixen, und die wären nicht schön und schon gar nicht trivial. Also muss ich halt damit leben.