recording start / end

Anlaufschwierigkeiten? Was ist was? Worum geht's?
palace
Erleuchteter
Erleuchteter
Beiträge: 441
Registriert: Dienstag 11. März 2003, 03:42

recording start / end

Beitrag von palace »

Hallo,

kann einer von euch Profis folgendes mal auf Sinn/Funktion begucken:
(habe das Problem, dass derzeit nach einer Aufnahme die "udpstreampes" Prozesse weiterlaufen)

recording.start

Code: Alles auswählen

#!/bin/sh
sleep 2 && renice -15 `pidof neutrino` &
kill -12 `pidof tuxmaild`
recording.end

Code: Alles auswählen

#!/bin/sh
sleep 30 && renice 0 `pidof neutrino` &
if pidof udpstreampes > /dev/null; then killall -q udpstreampes; fi &
kill -10 `pidof tuxmaild`
Merci,

Chris.
PS: Was bedeuten "&", "&&", ";" jeweils?
saruman
Erleuchteter
Erleuchteter
Beiträge: 682
Registriert: Samstag 13. Juli 2002, 10:05

Beitrag von saruman »

Also syntaktisch ist das korrekt. Ich würde in Deiner recording.end aber das '&' hinter der Zeile "if pidof udpstreampes > /dev/null; then killall -q udpstreampes; fi" rausnehmen. Und wenn ich Du wäre würde ich auch gleich die komplette Abfrage rausnehmen und die Zeile abändern zu "killall -q udpstreampes".

Mit "&&" kann man Prozesse in Abhängigkeit des Rückgabewertes anderer Prozesse ausführen. Abstrakt gesprochen heißt "A && B" nichts anderes, als dass B nur dann aus geführt wird wenn A erfolgreich beendet wurde (Rückgabewert 0).

Kannst ja mal zur Verdeutlichung ein "ls" und in der nächsten Zeile sofort ein "echo $?" ausführen. Da müsste dann 0 erscheinen. Ein "ls blaflasel" gefolgt von einem "echo $?" müsste irgendwas ungleich 0 liefern. Ergo würde "ls blafasel && echo okay" keine Zeile okay ausgeben, da die Datei blafasel nicht existiert. Legst Du sie aber an, so erscheint ein okay.

'&' macht was anderes. Mit '&' kannst Du Prozesse in den Hintergrund schicken und sofort mit der weiteren Bearbeitung des Scriptes weitermachen. In Deiner recording.end heißt das konkret, dass nicht erst 30 Sekunden gewartet wird, bis die nächste Zeile mit dem udpstreampes abgearbeitet wird. Stattdessen wird das sleep und der Rest der Zeile in den Hintergrund geschickt und die udpstreampes-Zeile kann sofort ausgeführt werden (im Hintergrund wird aber trotzdem 30 Sekunden gewartet, bis der neutrino-Prozess reniced wird).

Konnte ich mich irgendwie verständlich ausdrücken? :)

Ach ja: ';' trennt zwei Befehle voneinander. Sprich: "A ; B" ist dasselbe als wenn Du A und B in eigene Zeilen schreibst.
mogway
Semiprofi
Semiprofi
Beiträge: 1287
Registriert: Montag 30. Dezember 2002, 08:02

Re: recording start / end

Beitrag von mogway »

palace hat geschrieben:

Code: Alles auswählen

#!/bin/sh
sleep 2 && renice -15 `pidof neutrino` &
kill -12 `pidof tuxmaild`
Was mich in dem Zusammenhang einmal interessieren würde: Bringt das renice aktuell überhaut einen positiven Effekt?

Gruß
mogway
palace
Erleuchteter
Erleuchteter
Beiträge: 441
Registriert: Dienstag 11. März 2003, 03:42

Beitrag von palace »

@saruman: Vielen Dank für diese ausführliche Erklärung! *verneig
Denn mitunter will ich, dass auch die Streamprozesse erst nach dem Sleep beendet werden und nicht sofort...

Code: Alles auswählen

#!/bin/sh
sleep 30
renice 0 `pidof neutrino` 
killall -q udpstreampes
kill -10 `pidof tuxmaild`
sollte also reichen...

@mogway: Ich weiss es nicht genau - will beobachten, ob ich subjektiv weniger "Buffer Overflows / lost packets" bekomme.

Wenn ich das richtig verstehe, bekommt Neutrino während der Aufnahme eine niedrigere Prio - könnte mir eigentlich nur vorstellen, dass es Einfluss hat, wenn man mit der FB rumfuchtelt (Menues) oder sowas...
Für mich ist wichtiger, das der Maildaemon schweigt und anschliessend die Streamprozesse gekillt werden.
saruman
Erleuchteter
Erleuchteter
Beiträge: 682
Registriert: Samstag 13. Juli 2002, 10:05

Beitrag von saruman »

Also ein "renice 0" bringt nix weil Prozesse sowieso immer mit nice-level 0 gestartet werden. Ein renice mit negativen Werten priorisiert die Prozesse höher, sprich: Sie bekommen mehr Ressourcen-Zeit. Erst mit positivem nice-level werden Prozesse niedriger priorisiert:
man renice hat geschrieben:Users other than the super-user may only alter the priority of processes they own, and can only monotonically increase their ``nice value'' within the range 0 to PRIO_MAX (20). (This prevents overriding administrative fiats.) The super-user may alter the priority of any process and set the priority to any value in the range PRIO_MIN (-20) to PRIO_MAX. Useful priorities are: 20 (the affected processes will run only when nothing else in the system wants to), 0 (the ``base'' scheduling priority), anything negative (to make things go very fast).
Du müsstest also - um bei Deinem Beispiel zu bleiben - dem tuxmaild eine Priorität >0 geben, damit der nicht mehr so vordergründig arbeitet.