PID: Kontrollieren, ob Prozeß noch läuft

[ivka_sto]

Hallo zusammen


Ich versuch hier eine naive Lösung irgendwie besser zu machen, und unterwegs zu der genialen Lösung bin über folgendes gestolpert:
Wann gilt eigentlich ein Prozeß als beendet? Ich habe mit dem os.getpid() rumexperimentiert, da meine geniale Lösung über dem pid ging, und habe folgendes implementiert: Eine while-Schleife gibt den Inhalt einer Textdatei zeilenweise aus und die pid des Prozeßes aus, und ich ging davon aus, spätestens am Ende der Schleife (beim break angekommen) ist das Prozeß beendet, und die pid = 0. Soweit alles bestens. Als Probe hab ich nach der ersten Schleife noch eine hinzugefügt, die eigentlich analog funkitoniert, allerdings unter anderem Methodennamen eine andere Textdatei ausgibt. Aber in der Ausgabe bekommt die zweite Methode die gleiche pid zugewiesen .. woran liegt das? Gilt dann das Bearbeiten der zweiten Schleife als imemr noch das gleiche Prozeß? Oder bekommt das neue Prozeß die gleiche pid? Glaub ich wohl eher nicht .. Wann gilt ein Prozeß als beendet?

Ich hab mich die letzten paar Tage durch alles, was unter 'pid', 'prozeß' u. Ä. rauskam, wurde aber auch nicht schlauer ..

Also wenn mir einer weiterhelfen könnte, würd ich mich freuen


LG, ivka_sto

[Zap]

Ist zwar nett erklärt, aber vielleicht könntest du den Codesnippet den du da beschrieben hast mal posten.
Das wäre (zumindest für mich) um ein vielfaches klarer als diese textuelle Beschreibung.
Mich würde z.B interessieren ob du den Prozess von dem du redest selber aus python heraus gestartet hast oder nicht.
Man hätte in dem Fall die Möglichkeit mit dem subprocess modul den Status abzufragen usw.

[gerold]

Hallo ivka_sto!

Ich kann mir nicht vorstellen, dass die PID sofort neu vergeben wird.

Egal. Schau dir doch mal das mitgelieferte Modul "subprocess" an. Ganz besonders interessant für dich dürfte die Methode "wait" sein.

mfg
Gerold

[ivka_sto]

@zap:

Code: Alles auswählen

file = open('wieauchimmer.txt')
if os.getpid() != 0:
    while True:

        line = file.readline()

        print line, os.getpid(), '\n'
        print 'es kommt noch was\n'
    
        if not line: break
    
print 'fertig'


myfile = open('Restless.txt')

while True:

    line = myfile.readline()

    print line, os.getpid(), '\n'
    if not line: break

print 'komplett'

Den Prozeß wird aus Python heraus gestartet, ja. Wie kann man den Status abfragen? Das ist genau warum ich micht mit den pids überhaupt beschäftige:

Ich möchte aus Python ein äußeres Programm starten, das was berechnet, und die Ergebnisse an Python zurückgibt. Allerdings passiert es oft, daß dieses äußere Programm 'einschläft', deswegen möchte ich anhand der pid kontrollieren, ob noch Daten gesendet werden, oder (im Falle daß nicht) ob der Prozeß zu Ende ist und Python weitermachen kann, oder das Progrramm eingeschlafen ist.

@Gerold: über wait weiß ich auch Bescheid, allerdings ist es weniger wichtig für mich, daß ich auf das Ende des Subprozeßes warte, als daß ich den Status des Subprozeßes kenne.

Danke euch beiden für die Antworten

[Rebecca]

Code: Alles auswählen

if os.getpid() != 0:

os.getpid gibt die PID des aktuellen Prozesse aus. Das ist natuerlich, solange der Prozess laeuft, immer die gleiche, und wird niemals null. Wenn ein Prozess nicht mehr laeuft, kann er seine eigen Prozess-ID ja auch nicht mehr ausgeben... Ich verstehe sowieso nicht so genau, was du dir mit dem Snippet gedacht hast.

Aber du kannst z.B. ein Programm mit subprocess.Popen starten. Das Objekt, was du dabei erhaelts, hat ein returncode- und ein poll-Attribut, schau dir das mal an: http://docs.python.org/lib/node532.html

[Masaru]

... deswegen möchte ich anhand der pid kontrollieren, ob noch Daten gesendet werden, oder (im Falle daß nicht) ob der Prozeß zu Ende ist und Python weitermachen kann, oder das Progrramm eingeschlafen ist ...

1.) Erkennen, dass der gestartete Prozess beendet ist, lässt sich wie gerold und Rebecca schon sagten mit dem Überprüfen auf Vorhandensein eines Exitcodes (unter Verwendung des subprocess moduls) lösen.

2.) Erkennen, dass der Prozess noch läuft, erfolgt auf die gleiche Art und Weise ... nur andersrum

3.) Feststellen, dass ein Prozess "hängt" ... da musst du wohl oder übel plattformspezifisch dir eine Komponente schreiben, welche Prozesslisten und Prozessinformationen auslesen, sich merken und vergleichen kann (unter Windows recht schmuck mit den win32 Extentions realisierbar; unter linux ein lästiges parsen eines abgefeuerten "ps ..." shellcomands ... der natürlich auch wiederrum hängen könnte *hehe*, wovon wir aber mal natürlich nicht ausgehen).

Und selbst damit hat man keine 100%ige Gewährleistung, dass man tatsächlich einen Prozess als "hängend" deklarieren kann.

Du kannst natürlich auf der anderen Seite aber damit eine Art "timeout" realisieren ... dass wenn nach X-Sekunden keine Daten mehr z.B. in eine Pipe geworfen werden, angenommen wird, dass bei einem laufenden Prozess dieser folglich hängen muss.


>>Masaru<<

[Leonidas]

(unter Windows recht schmuck mit den win32 Extentions realisierbar; unter linux ein lästiges parsen eines abgefeuerten "ps ..." shellcomands ... der natürlich auch wiederrum hängen könnte *hehe*, wovon wir aber mal natürlich nicht ausgehen).

Nicht unbedingt, ``/proc`` existiert. ``ps`` bekommt ja seine Informationen nicht von ungefähr. Somit ist die Situation Win32API-Call der pywin32 erfordert oder einige Dateien im Dateisystem lesen was mit den eingebauten Funktionen problemlos möglich ist. Da blockiert auch nichts und wenn es das tut ist das System eh kaputt und muss mindestens neu gestartet werden.

[Masaru]

Nicht unbedingt, ``/proc`` existiert. ... Somit ist die Situation Win32API-Call der pywin32 erfordert oder einige Dateien im Dateisystem lesen was mit den eingebauten Funktionen problemlos möglich ist.

Nicht unbedingt ... jedenfalls nicht auf einer HP-UX Maschine. Da musste weiterhin 'ps' parsen.
Hin oder her wird man parsen müssen, was auch immer .

...Da blockiert auch nichts und wenn es das tut ist das System eh kaputt und muss mindestens neu gestartet werden. ...

... wovon wir aber mal natürlich nicht ausgehen (wollen)

[lunar]

Nicht unbedingt, ``/proc`` existiert. ... Somit ist die Situation Win32API-Call der pywin32 erfordert oder einige Dateien im Dateisystem lesen was mit den eingebauten Funktionen problemlos möglich ist.

Nicht unbedingt ... jedenfalls nicht auf einer HP-UX Maschine. Da musste weiterhin 'ps' parsen.

Woher nimmt ps denn da seine Informationen?

[Masaru]

Unter HP-UX werden hierfür spezielle C-Funktionen angeboten. Ein paar Beispiele findet man hier: http://docs.hp.com/en/B2355-90682/pstat.2.html

Und hier findest du ein paar mehr Informationen über HP-UX Process Management

>>Masaru<<

[lunar]

Unter HP-UX werden hierfür spezielle C-Funktionen angeboten. Ein paar Beispiele findet man hier: http://docs.hp.com/en/B2355-90682/pstat.2.html

Und hier findest du ein paar mehr Informationen über HP-UX Process Management

Was spricht dann gegen die Verwendung von ctypes, wenn dir das Parsen nicht behagt?

Im Übrigen dürfte es nicht so leicht sein, programmatisch zu erkennen, ob ein Prozess hängt. Nach welchen Kriterien willst du denn das beurteilen?

[Masaru]

Hallo lunar ...

Was spricht dann gegen die Verwendung von ctypes, wenn dir das Parsen nicht behagt?

Nichts ... kannst ja mal den TE fragen, ob er auf einer HP-UX Kiste arbeitet und Ihm verklickern wie das macht *hehe*. Es geht hier ja letztendlich nicht dadrum was "ich" mag oder nicht ... Ist es mein Problem? Ich denke nicht Tim .

Im Übrigen dürfte es nicht so leicht sein, programmatisch zu erkennen, ob ein Prozess hängt. Nach welchen Kriterien willst du denn das beurteilen?

Der TE ist in der lage händisch zu erkennen "... daß dieses äußere Programm 'einschläft' ...".

Was meinst du lunar *grübel*, ob es nicht vielleicht auch möglich wäre, entsprechendes in einer Programmlogik unterzubringen? Na?
Das zudem eine solche Erkennung keine 100%ige Garantie zur Bestimmung eines eingefrohrerenen Prozesses ist, hatte ich ebenfalls bereits erwähnt.

Und wie ich ebenfalls erwähnt hatte, könnte der TE einen Timeout-Mechanismus implementieren.

Meinst du, es gibt noch irgendetwas zu diesem Thema zu sagen, was dem TE bei seinem Problem helfen könnte ?

>>Masaru<<

[lunar]

Was spricht dann gegen die Verwendung von ctypes, wenn dir das Parsen nicht behagt?

Nichts

Noch vor zwei Tagen "musste man ps parsen":

Nicht unbedingt ... jedenfalls nicht auf einer HP-UX Maschine. Da musste weiterhin 'ps' parsen.

Entweder ist deine Meinung recht sprunghaft, oder war ein Aprilscherz.

Es geht hier ja letztendlich nicht dadrum was "ich" mag oder nicht ... Ist es mein Problem?

Es geht um deine Aussagen, die sich leicht widersprechen.

[Masaru]

Äh lunar

... was ist denn daran sprunghaft, dass ich vor 2 Tagen dachte, "ps" parsen sei die einzige Möglichkeit auf einem HP-UX System um an Prozessinformationen zu gelangen, und dann einer weiteren Option zustimme?

Erklär mir in zeitlicher Relation mal, wie sich diese beiden Aussagen wiedersprechen können?

Oh .... jetzt versteh ichs ... ha .... ich hätte vielleicht eher schreiben sollen:
"Ooooh, lunar *tanz*, du hast ja recht ... ich sehe auch ein, dass es ja noch eine weiiiiitere Möglichkeit gibt ... die Idee mit ctypes is sowas von grandios und ich ziehe meinen Hut. Da hast du mir jetzt aber ja eine viel bessere Möglichkeit gezeigt."?

Dir war das

Nichts

wohl ein wenig zu wenig an Kopfstreichelei was *g*?

>>Masaru<<

[lunar]