Kann ein Prozess, der in einer tmux-Sitzung gestartet wurde, einschlafen?
338
dasWesen
Kann ein Prozess, der in einer tmux-Sitzung gestartet wurde, einschlafen? Wenn ja, was ist die Ursache, wie kann man das verhindern?
Beispiel für die Frage: Ich habe gestern einen Prozess auf einem Server gestartet (neuronale Netzwerke trainieren, die aktuelle Trainingsepoche wird in stdout gedruckt). Ich hatte ein geteiltes Fenster, und in dem Fenster, in dem der Prozess ausgeführt wurde, hatte ich den Bildlaufmodus aktiviert, bevor ich mich von der Sitzung löste.
Heute komme ich zurück, und es hat überhaupt keine Fortschritte gemacht.
Genauer gesagt ist die Epoche gleich. Nach dem Beenden des Bildlaufmodus wurde der Vorgang nun glücklich fortgesetzt.
Das Protokoll liest so etwas wie
... Epoche 40: 1h wenige Minuten Epoche 41: 12h wenige Minuten Epoche 42: 12h noch einige Minuten ... Epoche 73: 13h
Das heißt, die Zeit, die es brauchte, um von Epoche 0 bis 49 zu kommen, war definitiv weniger als zwei Stunden. Von Epoche 40 bis 41 dauerte es etwa 11 Stunden (!), von Epoche 41 bis 76 betrug die durchschnittliche Zeit pro Epoche etwa 1,7 Minuten. Die Epochen sind in einer Schleife, und es sollte keinen Grund geben, warum eine etwa 400 Mal länger dauert als die anderen.
Zusätzliche Informationen: Dieses "Schlafen" geschieht nicht jedes Mal, wenn ich mich im Bildlaufmodus löse. Aber es ist schon vorher passiert. Der Scroll-Modus hat möglicherweise überhaupt nichts damit zu tun.
Das Programm ist ein Python-Skript, einschließlich Tensorflow-Code, der auf einer GPU ausgeführt wird. Der Befehl zum Ausführen war:
python train_script.py 2>&1 | tee train_log.txt.
Für tmux verwende ich tmux attachdie Standardtastenzuordnung zum erneuten Anbringen und ctrl-b + dzum Trennen, ctrl-b + up(number block)zum Starten des Bildlaufs und qzum Beenden des Bildlaufmodus .
1 Antwort auf die Frage
0
Alex
Kann ein Prozess, der in einer tmux-Sitzung gestartet wurde, einschlafen?
Im Grunde müssen Sie nur tmuxeigene Dateideskriptoren anstelle von STDIN / STDOUT / STDERR an einen laufenden Prozess innerhalb tmuxdieses Prozesses anhängen, sodass dieser während der Trennung von der Konsole arbeiten kann.
Nachfolgend finden Sie ein einfaches Skript, das Sie mit demselben Workflow (Anhängen / Entfernen von tmuxSitzung) ausführen können, den Sie beschrieben haben:
#!/bin/sh c=1000 while [ $c -ne 0 ]; do date '+%Y-%m-%dT%H:%M:%S' | tee -a log.txt sleep 1 done
Selbst wenn Sie in den Bildlaufmodus wechseln und sich dann von der tmuxSitzung trennen, wird sie weiterhin ausgeführt. Sie können die log.txtDatei überprüfen und haben daher kein Problem tmux.
Ok, das passiert also normalerweise nicht. Ihr Beispiel schließt jedoch nicht aus, dass es passieren kann und dass tmux irgendwie Einfluss hat. Vielleicht verursacht es die Interaktion mit der GPU oder mit dem Python-Interpreter? Dieses "Schlafen" geschieht auch nicht jedes Mal, wenn ich mich im Bildlaufmodus löse.
dasWesen vor 5 Jahren
0
Eine Gruppe von Leuten, die GPU für das Mining von Bitcoins ohne Monitore verwenden, daher glaube ich nicht, dass es sich um ein Tmux- oder GPU-Problem handelt. Führen Sie vor der Verwendung von tmux eine virtuelle Python-Umgebung aus: Wenn ja, versuchen Sie, sie zu beenden und die virtuelle Python-Umgebung in tmux auszuführen. Auch wenn Sie Anaconda verwenden, unterstützen manche Versionen keine parallelen Umgebungen.
Alex vor 5 Jahren
0
Heute Nacht schreibe ich auf, wo genau der Prozess ist, um zu sehen, ob es sich nur um Tensorflows handelt, die zufällige Pausen machen. Aber ich glaube, Epoche 40 war heute Morgen das Letzte, was im Scrollmodus sichtbar war, aber ich versuche wirklich sicherzustellen, dass sie auf diese Weise mit tmux korreliert.
dasWesen vor 5 Jahren
0
Nein, ich verwende keine virtuelle Python-Umgebung auf dem Server. Aber Anaconda benutze ich. Vielleicht ist es das, aber dann kann ich wahrscheinlich nichts tun, außer regelmäßig nachzuschauen, was der Prozess tut. Danke für deine Vorschläge.
dasWesen vor 5 Jahren
0
Also wahrscheinlich Anaconda, lesen Sie diesen Schritt: https://github.com/openai/universe-starter-agent/issues/9. Jedes Mal, wenn ich ein bisschen dasselbe Problem untersuche, stellt sich heraus, dass es nicht "tmux" ist.
Alex vor 5 Jahren
0
Ein weiterer Hinweis: https://unix.stackexchange.com/questions/366553/tmux-is-causing-anaconda-to-use-a-different-python-source. Um "tmux" von der Schuld auszuschließen, können Sie auch versuchen, tensorflow mit "nohup" anstelle von "tmux" auszuführen, aber ich bin mir ziemlich sicher, dass es eine Pythont-Umgebung ist, die alles vermasselt.
Alex vor 5 Jahren
0
Wie gesagt, es ist keine Python-Umgebung involviert - keine Conda-Umgebung, keine Python-Virtualisierung. Python-Versionen und -Pfade sind innerhalb und außerhalb der tmux-Sitzung identisch. Aber ich werde es versuchen!
dasWesen vor 5 Jahren
0