[Frage] custom.rc hintergrundprozess nicht möglich?

[johndd]

Hallo,

die custom.rc ruft nur ein einziges Skript auf, in dem dann die weiteren Befehle vorhanden sind. Ein paar Befehle sollen aber ihren eigenen Hintergrundprozess erhalten, nur leider scheinen diese nie gestartet zu werden:

custom.rc:

/var/media/ftp/uStor01/start/start

start:

trap '' SIGHUP
HDD='/var/media/ftp/uStor01/start'
TEMP=/var/tmp
cd $TEMP
cp $HDD/lights_off $TEMP
chmod +x lights_off
openvpn --config $TEMP/openvpn.conf --daemon start < /dev/null > /dev/null 2>&1 &
cd $TEMP
ash lights_off < /dev/null > /dev/null 2>&1 & # ./ oder sh geht auch nicht

lights_off:

sleep 60
/bin/led-ctrl wlan_off
/bin/led-ctrl power_off

Darf das & nicht verwendet werden? Irgendwo hab ich noch gelesen, dass man das Problem mit dem auffangen von SIGHUP umgehen kann, das bringt aber auch nichts.

Ideen an was das liegen kann, dass lights_off nie ausgeführt wird bzw. sofort beendet wird? Das VPN davor startet ohne Probleme, aber ich vermute das --daemon startet einen neuen Prozess mit einer anderen Methode.

Danke

 

[er13]

Ist der Inhalt von lights_off in Deinem Post oben irgendwie gekürzt? Wenn nein, dann fehlt die shebang-Zeile

Und warum startest Du openvpn händisch, wenn Du schon freetz auf der Box hast?

 

[olistudent]

Das USB-Verzeichnis ist schon da, wenn der Aufruf aus der rc.custom stattfindet?

Ansonsten habe ich auch schon öfter die Erfahrung gemacht, dass Background-Prozesse beendet werden, wenn der Parent fertig ist. Im Besonderen hatte ich diese Problem auch mit den Startskripten bei AVM. Es gibt ein busybox applet (dessen Name mir gerade entfallen ist) mit dem man Prozesse wirklich losgelöst vom Parent laufen lassen kann...

Gruß
Oliver

 

[koyaanisqatsi]

Abend

Ich würd das Ganze erstmal auf der Kommandozeile testen, bevor es einbetoniert wird.

Es stellt sich mir auch die Frage: Startet openvpn nicht als Deamon?
Sind diese Umleitungen und die Löslösung nicht überflüssig?
Kannst du die LEDs nicht sofort und mit nur einen Befehl auschalten?

/bin/led-ctrl display_suspend

...warum so kompliziert?

Ansonsten fällt mir noch ein:
Ein cd $TEMP reicht.
Mach mal am Ende von /var/media/ftp/uStor01/start/start: sleep 65
Damit /var/media/ftp/uStor01/start/start nicht vor /var/tmp/lights_off beendet wird.
Ich weiß, das ist sinnfrei, aber dann weißt du, dass es daran liegt.

 

[johndd]

Hallo,

schon mal danke für die vielen Hinweise.

Ich hab die LEDs nur als Beispiel genommen, ich hab auch nebenher einen SSH-Proxy-Tunnel am laufen der durch das Skript immer neu gestartet wird, und da ist die Nebenläufigkeit unumgänglich, bei den LEDs ist es nur nützlich damit die erste Minute nach dem Booten die LEDs wie gewohnt arbeiten, damit man noch eine Möglichkeit hat Fehler zu erkennen. Die shebang-Zeile macht auch keinen Unterschied, da ash bzw. sh oder sogar der direkte Aufruf aus der Kommandozeile das Skript schon richtig interpretieren.

Ich vermute das liegt wirklich daran, dass der ablebende Eltern-Prozess auch gleich seine Kinder mit in den Tot reißt, auch wenn der Trap das eigentlich verhindern sollte. Weiß denn wer wie der Busybox-Befehl heißt? Einfach nohup verwenden, oder irgendetwas anderes?

Werd's mal mit nohup am Wochenende probieren.

PS: Das USB-Verzeichnis muss schon da sein, da z.B. auch der OpenVPN-Aufruf über das Skript auf der Platte gestartet wird. Wenn die Platte beim Ausführen der custom.rc noch nicht da ist, passiert einfach Garnichts. Bei bis jetzt jedem Versuch war die Platte aber schon davor anwesend, wodurch ich mit dem Restrisiko, dass sie vielleicht doch mal nicht da ist gut leben kann.

 

[RalfFriedl]

Bevor Du mit nohup und ähnlichem anfängst, solltest Du erstmal den Tipp aus #4 befolgen und das Skript von Hand starten, ohne Ausgabeumleitung und Hintergrund, statt dessen ggf. mit "sh -x". Dann siehst Du, ob das Skript als solches funktioniert.

Außerdem, was ist der Grund für die Option "--daemon start", speziell das "start"?

 

[PeterPawn]

Ein paar Befehle sollen aber ihren eigenen Hintergrundprozess erhalten, nur leider scheinen diese nie gestartet zu werden

Ich habe beim Start von asynchronen Prozessen eigentlich nur gute Erfahrungen mit einem AVM-Kommando gemacht: delay.

Das setzt per msgsend einen Request an den multid ab und der startet dann nach einer angegebenen Anzahl von Sekunden das angegebene Kommando ... und zwar als eigenständigen Prozess, der sich auch vom Ableben des multid (es kann bei bestimmten Aktionen schon mal passieren, daß der gekillt und neu gestartet wird) nicht beeindrucken läßt.

delay -d 1 OVPN "openvpn --config $TEMP/openvpn.conf --daemon start < /dev/null > /dev/null 2>&1"
delay -d 5 LOFF "ash lights_off < /dev/null > /dev/null 2>&1"

sollte das "Problem" lösen (die Kommandos sind ohne Berücksichtigung der Hinweise der anderen, die solltest Du noch beachten).

Die einzige "Falle", die man vermeiden muß, ist die geforderte Eindeutigkeit der verwendeten ID. Existiert bereits ein "wartender" Eintrag mit dieser ID, wird er ersetzt. Auch beim wiederholten Start eines Skripts über diesen Mechanismus (z.B. im 5-Minuten-Abstand), was sich immer wieder selbst für den nächsten Start registriert, funktioniert es nicht mit jeder Version der Firmware, wenn man dabei dieselbe ID verwendet. Ich hänge dann aus Gewohnheit immer noch die letzten 4 Stellen der Linux-Zeit dran ... einige Versionen mochten keine IDs mit mehr als 8 Zeichen.

Man hat natürlich auch keinen "unmittelbaren" Zugriff auf die PID des gestarteten Prozesses aus dem startenden Skript heraus ... und es setzt den gestarteten multid voraus, was zu früh im Bootprozess auch in die Hose geht.
Die (aktuelle) Firmware startet ja zuerst die Kommandos in den "S{xy}"-Skripten per "source"-Kommando und anschließend die "E{xy}"-Files mit explizitem "sh"-Aufruf, das für alle x in aufsteigender Folge.
Der multid wird erst im Rahmen von "rc.net" gestartet, das wieder aus "E46-net" heraus aufgerufen wird und somit steht der multid erst den Skripts ab '(S|E)5y' zur Verfügung.
Da ich zugegebenermaßen keine Ahnung mehr habe, wo und wann die "rc.custom" inzwischen im mod gestartet wird, kann der ganze Hinweis also auch nur heiße Luft sein (früher lief rc.custom mal in zeitlicher Nähe zur debug.cfg, wenn ich mich nicht irre, aber das wissen die anderen garantiert genau).

PS: Meist klappt das sogar sehr gut, wenn die Uhrzeit in der "Warteperiode" neu gesetzt wird (was beim Start der Box ja leicht mal passieren kann), der multid berücksichtigt offenbar diese Änderungen. Beim crond klappt das nicht immer. Dafür überleben cron-Jobs dann eben auch den Neustart des Daemons (was für "wartende" Jobs beim multid nicht gilt und ein Aufruf z.B. von ar7cfgchanged startet auch den multid neu, keine Ahnung, ob das in freetz noch irgendwo verwendet wird).