Frage zu ps / Prozesse bestimmen
Ich versuche mich mit der Problemstellung möglichst kurz zu erhalten und erkläre auf Wunsch gerne mehr. Ich habe mehrere bis auf 1 Variable idente Scripts zum Audio-CD auslesen. Die einzelnen Tracks werden mit cdda2wav in einer _Schleife_ ausgelesen und nicht mit "alltracks". Nachdem ein Track ausgelesen wurde, startet lame als Hintergrundprozess um diesen Track zu mp3 zu encodieren, worauf sofort cdda2wav den nächsten Track ausliest, usw. Beim letzten Track wird lame nicht als Hintergrundprozess gestartet, sondern "normal". Mit top kann ich nun beobachten, dass es durchaus sein kann, dass der letzte Titel bereits fertig encodiert ist und vorherige noch nicht. Solange nur mit _1_ CDROM ausgelesen wird, ist es noch relativ einfach festszustellen, ob noch ein lame-Prozess aktiv ist. Gibt es dafür eine bessere Möglichkeit im Script als zB alle 1/2 min. in einer Schleife nachzusehen, ob noch irgendein lame-Prozess aktiv ist? Komplizierter wird es nun, wenn von _2_ CDs gleichzeitig ausgelesen wird und es lame-Prozesse gibt, die von dem einen oder anderen Script stammen. Wie frage ich ab, ob eine CD bereits fertig encodiert ist oder anders formuliert, wie erkenne ich mit ps ob noch ein lame läuft, dass von Script1 bzw. Script2 stammt? Al
Moin,
* Al Bogner
Gibt es dafür eine bessere Möglichkeit im Script als zB alle 1/2 min. in einer Schleife nachzusehen, ob noch irgendein lame-Prozess aktiv ist?
while /bin/true do ps -ef | grep -v grep | grep lame sleep 30 done
Komplizierter wird es nun, wenn von _2_ CDs gleichzeitig ausgelesen wird und es lame-Prozesse gibt, die von dem einen oder anderen Script stammen. Wie frage ich ab, ob eine CD bereits fertig encodiert ist oder anders formuliert, wie erkenne ich mit ps ob noch ein lame läuft, dass von Script1 bzw. Script2 stammt?
Da kannst Du Dir zunutzen machen, daß ps(1) auch die PID des Elternprozesses mit angibt. Diese PID kennst Du im Skript natürlich und kannst auch danach greppen. Thorsten -- Der Optimist ist in der Regel ein Zeitgenosse, der ungenügend informiert ist. - John B. Priestly
Am Sonntag, 18. Januar 2004 22:45 schrieb Thorsten Haude:
ps -ef | grep -v grep | grep lame sleep 30
Da kannst Du Dir zunutzen machen, daß ps(1) auch die PID des Elternprozesses mit angibt.
f von ps -ef war das Geheimnis :-)
Diese PID kennst Du im Skript natürlich und kannst auch danach greppen.
Ok, ich könnte das abfragen, in dem ich nach dem Namen des Scripts grep. Gibt es dafür eine Syntax mit der ich die PID des _laufenden_ Scripts "automatisch" erhalte, ohne den Scriptnamen anzugeben? Al
Moin,
* Al Bogner
Gibt es dafür eine Syntax mit der ich die PID des _laufenden_ Scripts "automatisch" erhalte, ohne den Scriptnamen anzugeben?
$$, wenn ich mich recht erinnere. Thorsten -- As we enjoy great advantages from the inventions of others we should be glad of an opportunity to serve others by any invention of ours, and this we should do freely and generously. - Benjamin Franklin
Am Sonntag, 18. Januar 2004 23:26 schrieb Thorsten Haude:
Moin,
* Al Bogner
[2004-01-18 23:15]: Gibt es dafür eine Syntax mit der ich die PID des _laufenden_ Scripts "automatisch" erhalte, ohne den Scriptnamen anzugeben?
$$, wenn ich mich recht erinnere.
Ja. das funktioniert so: SCRIPTID=`ps -e | grep $$ | cut -f 1 -d" "` Gibt es noch eine schönere Syntax? So schrecklich finde ich sie gar nicht :-) Al
* On Sun, 18 Jan 2004 at 23:54 +0100, Al Bogner wrote:
Am Sonntag, 18. Januar 2004 23:26 schrieb Thorsten Haude:
* Al Bogner
[2004-01-18 23:15]: Gibt es dafür eine Syntax mit der ich die PID des _laufenden_ Scripts "automatisch" erhalte, ohne den Scriptnamen anzugeben?
$$, wenn ich mich recht erinnere.
Ja. das funktioniert so: SCRIPTID=`ps -e | grep $$ | cut -f 1 -d" "`
Gibt es noch eine schönere Syntax? So schrecklich finde ich sie gar nicht :-)
*stirnrunzel* Wo isn da jetzt der tiefere Sinn? Oder schmecke ich bloß den Witz nicht raus? /apm, der der Meinung ist, daß SCRIPTID=$$ einfacher wäre. -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Am Mon, 19 Jan 2004, Adalbert Michelic schrieb:
* On Sun, 18 Jan 2004 at 23:54 +0100, Al Bogner wrote:
Am Sonntag, 18. Januar 2004 23:26 schrieb Thorsten Haude: [..] SCRIPTID=`ps -e | grep $$ | cut -f 1 -d" "`
Gibt es noch eine schönere Syntax? So schrecklich finde ich sie gar nicht :-) [..] /apm, der der Meinung ist, daß SCRIPTID=$$ einfacher wäre.
Al, mach mal Pause! Du bist offenkundig verwirrt! -dnh, der der Meinung ist, dass $$ statt $SCRIPTID einfacher waere -- FAQs are like flatulence. Any asshole can produce them. -- Toni Lassila
Hallo, Am Sun, 18 Jan 2004, Al Bogner schrieb:
Am Sonntag, 18. Januar 2004 22:45 schrieb Thorsten Haude:
ps -ef | grep -v grep | grep lame sleep 30
Da kannst Du Dir zunutzen machen, daß ps(1) auch die PID des Elternprozesses mit angibt.
f von ps -ef war das Geheimnis :-)
Diese PID kennst Du im Skript natürlich und kannst auch danach greppen.
Ok, ich könnte das abfragen, in dem ich nach dem Namen des Scripts grep.
Gibt es dafür eine Syntax mit der ich die PID des _laufenden_ Scripts "automatisch" erhalte, ohne den Scriptnamen anzugeben?
echo "$$" echo "$PPID" # wohl bash-spezifisch Was du suchst sollte sich also irgendwie so loesen lassen: while test `ps -ef | awk '/lame/{print $3;}'` -eq $$ do sleep 5; done Oder irgendsowas in der Art. -- Besides, it would have so many uses. Rude cellphone user? ZOT! Dorm room pr0n server? ZOT! Suck-ass hardware that needs replacement? ZOT! -- Steve VanDevender, wishing himself a portable EMP gun
On Monday 19 January 2004 01:31, David Haller wrote:
echo "$$" echo "$PPID" # wohl bash-spezifisch
$$ ist die PID. kris@valiant:~> echo $PPID 23600 kris@valiant:~> echo $$ 32157 Und was Ihr sucht ist die $!, die ID des letzten Hintergrundprozesses: kris@valiant:~> sleep 10 & [1] 32351 kris@valiant:~> echo $! 32351 kris@valiant:~> kris@valiant:~> [1]+ Done sleep 10 kris@valiant:~> echo $! 32351 und natürlich wait: kris@valiant:~> help wait wait: wait [n] Wait for the specified process and report its termination status. If N is not given, all currently active child processes are waited for, and the return code is zero. N may be a process ID or a job specification; if a job spec is given, all processes in the job's pipeline are waited for. Zum Beispiel so: kris@valiant:/tmp> cat probe.sh #! /bin/sh -- LAME="sleep 3" RIP="echo 'Ich rippe...'" for i in 1 2 3 4 5 6 7 8 9 10 do $LAME & $RIP wait echo "Rip fertig, Encode fertig..." done Kristian -- http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG
participants (5)
-
Adalbert Michelic
-
Al Bogner
-
David Haller
-
Kristian Köhntopp
-
Thorsten Haude