Stoppt eine Python-Aufgabe nach einem SSH-Abbruch auf einem Remote-Mac? 2026

Das Handbuch von tmux beschreibt zwei zentrale Möglichkeiten: Eine Sitzung kann getrennt werden und später wieder zugänglich sein. Diese Woche sollten Sie vor dem nächsten längeren Lauf prüfen, ob Ihr Python-Prozess in einer tmux-Sitzung auf dem Remote-Mac läuft, und Logs sowie Ausgaben kontrollieren. Ein SSH-Abbruch allein sagt nicht, ob die Analyse weiterläuft: Entscheidend sind der Startkontext auf dem entfernten Rechner und der Zustand von Prozess und Host. Das tmux-Handbuch erläutert das Trennen und erneute Verbinden mit Sitzungen.

Dieser Leitfaden richtet sich an:

• Studierende und Forschende, die Python-Skripte per SSH auf einem Remote-Mac starten.
• Personen, die macOS-Umgebungen für Forschungssoftware benötigen und nachvollziehbare Logs sowie Ergebnisse sichern müssen.
• Hochschul-Supportteams, die zwischen einer noch aktiven Sitzung und einer erfolgreichen Berechnung unterscheiden müssen.

SSH stellt eine Verbindung zum entfernten System her; die Verbindung ist kein Erfolgsnachweis für ein gestartetes Programm. Das OpenSSH-Handbuch beschreibt die Verbindung und ihre Sitzungskanäle. Was nach einem Verbindungsabbruch mit einem Python-Prozess geschieht, hängt davon ab, wie und in welchem Kontext er gestartet wurde. Ein lokales Terminalfenster zu schließen, eine entfernte Shell zu beenden, eine tmux-Sitzung zu trennen und den Host neu zu starten sind unterschiedliche Ereignisse.

Ein gewöhnlicher Befehl in einer interaktiven Shell ist typischerweise an deren Lebenszyklus gebunden. Wird die entfernte Shell beendet, kann der Prozess ein Hangup-Signal erhalten oder aus einem anderen Grund enden. Die Python-Dokumentation erklärt, wie Programme Signale behandeln; sie garantiert nicht, dass jedes Skript nach dem Ende seiner Shell weiterläuft. Die Python-Dokumentation zu Signalen ist deshalb eine Referenz für das Verhalten eines Programms, aber keine Zusicherung für den Zustand eines konkreten Laufs.

Ein in tmux gestarteter Prozess bleibt dagegen in einer Sitzung, die von der SSH-Terminalansicht getrennt werden kann. Das ist ein Schutz gegen den Verlust der Verbindung, nicht gegen alle Fehler. Ein Host-Neustart, ein Prozessabsturz, eine Beendigung durch die Administration oder das Ende des bereitgestellten Dienstes kann die Sitzung und den Prozess beenden. Für die konkrete macOS-Umgebung müssen außerdem die Verfügbarkeit von tmux und die Regeln des Host-Anbieters geprüft werden.

Bevor Sie erneut starten, halten Sie fest, was tatsächlich beobachtet wurde: den ausgeführten Befehl, eine mögliche Fehlermeldung, den letzten Logeintrag und den erwarteten Speicherort der Ergebnisse. Ein geschlossenes Terminal ist ein Hinweis auf eine unterbrochene Anzeige oder Verbindung, aber kein Beleg dafür, dass die Forschungsaufgabe fehlgeschlagen oder erfolgreich beendet ist.

Nach einer neuen SSH-Verbindung sollten Sie den Status nicht anhand eines einzigen Signals beurteilen. Eine Sitzung kann noch existieren, während der Prozess beendet ist; ein Prozess kann sichtbar sein, aber auf Eingaben warten oder nicht mehr sinnvoll vorankommen. Umgekehrt kann ein abgeschlossenes Programm seine Ergebnisse korrekt geschrieben haben, obwohl keine Sitzung mehr angezeigt wird.

Ordnen Sie die Beobachtungen in drei Ebenen ein:

• Shell: Eine gewöhnliche interaktive Shell zeigt die zuvor beendete Sitzung nicht automatisch wieder an. Ein neuer Login ist eine neue Terminalverbindung.
• Prozess: Prüfen Sie, ob das erwartete Programm auf dem entfernten Host noch vorhanden ist. Die Prozessanzeige sagt für sich allein weder etwas über den fachlichen Fortschritt noch über die Ergebnisqualität aus. Unter macOS kann die Aktivitätsanzeige Prozesse und deren Aktivität darstellen.
• Sitzung und Dateien: Prüfen Sie, ob tmux die erwartete Sitzung auflistet und ob die Logdatei oder vorgesehene Ausgabedateien neue Inhalte enthalten.

Für die Prüfung einer laufenden Analyse sind mindestens zwei voneinander unabhängige Beobachtungen sinnvoll: Prozesszustand und Log- oder Dateiveränderung. Bei einem Prozess, der sichtbar bleibt, während Logs und erwartete Ausgaben nicht weiter wachsen, ist „läuft“ keine ausreichende Diagnose. Untersuchen Sie dann, ob das Programm auf eine Eingabe wartet, eine Ressource nicht erreicht oder bereits in einen Fehlerzustand geraten ist.

Prüfen Sie außerdem die Pfade im Startbefehl. Ein Skript, das nach einem erneuten Login aus einem anderen Arbeitsverzeichnis gestartet wird, kann Eingaben oder Ausgaben an einer unerwarteten Stelle suchen. Auch fehlende Schreibberechtigungen, ein nicht verfügbares Volume oder ein anderes Python-Umfeld können dazu führen, dass ein Lauf nicht wie vorgesehen arbeitet. Starten Sie den Job nicht einfach erneut, bevor Sie kontrolliert haben, ob ein erster Prozess noch aktiv ist: Sonst riskieren Sie doppelte Berechnungen oder konkurrierende Schreibzugriffe.

Wenn der Auftrag auf einem Remote-Mac interaktiv und über die Kommandozeile läuft, kann tmux die Verbindung vom Prozesskontext trennen. Der entscheidende Punkt: Die Sitzung muss auf dem entfernten Host eingerichtet und der Auftrag darin gestartet werden. Eine tmux-Sitzung auf dem lokalen Windows- oder Linux-Rechner schützt keinen Prozess, der auf dem Remote-Mac läuft.

Prüfen Sie zuerst, ob tmux in der Zielumgebung verfügbar ist. Nehmen Sie nicht an, dass es auf jedem macOS-System vorinstalliert oder für jede Nutzerrolle freigegeben ist. Klären Sie gegebenenfalls die Installationsmöglichkeit mit der zuständigen Administration. Die tmux-Einführung beschreibt das Erstellen, Auflisten und Wiederverbinden von Sitzungen; konkrete Befehle sollten Sie gegen die lokal verfügbare Version prüfen.

Ein typischer Ablauf sieht so aus:

1. Verbinden Sie sich per SSH mit dem Remote-Mac und wechseln Sie in das Projektverzeichnis.
2. Erstellen Sie auf dem Remote-Mac eine benannte tmux-Sitzung, zum Beispiel mit tmux new -s analyse.
3. Starten Sie den Python-Befehl innerhalb dieser Sitzung. Prüfen Sie vorher, ob Eingabe- und Ausgabepfade sowie das verwendete Python-Umfeld stimmen.
4. Trennen Sie die Terminalansicht mit Ctrl-b und anschließend d. Die Sitzung bleibt dadurch im Hintergrund bestehen, sofern Host und Dienst weiterlaufen.
5. Melden Sie sich später erneut per SSH an und verbinden Sie sich mit tmux attach -t analyse.
6. Kontrollieren Sie in der wieder geöffneten Ansicht die letzte Ausgabe und gleichen Sie diese mit Logdatei und Ergebnisdateien ab.

Die genannten tmux-Kommandos und das Verhalten beim Trennen sind im offiziellen Handbuch beschrieben. Tastenkombinationen können im Kontext eines Terminalprogramms oder einer geänderten tmux-Konfiguration anders wirken; testen Sie den Ablauf daher zunächst mit einem unkritischen Beispiel und nicht erst beim einzigen Lauf einer wichtigen Analyse.

Wichtig: tmux ersetzt weder eine Jobverwaltung noch einen Checkpoint-Mechanismus. Es hält eine Terminal-Sitzung verfügbar, solange die dafür nötigen Prozesse und der Host bestehen; es kann keine Ergebnisse rekonstruieren, die ein Skript nicht gespeichert hat.

Eine wiederverbindbare tmux-Sitzung belegt nur, dass die Sitzung noch zugänglich ist. Sie beweist nicht, dass das Python-Skript fachlich korrekt läuft. Bei einer Forschungsanalyse müssen daher auch Fehlermeldungen, Eingabedaten, Schreibrechte und die Plausibilität der Ausgaben geprüft werden.

Leiten Sie bei einem erneuten Lauf die Ausgabe in eine eindeutig zuordenbare Datei um oder konfigurieren Sie Python-Logging. Die Python-Logging-Dokumentation zeigt, wie Anwendungen Logs unter anderem in Dateien schreiben. Verwenden Sie einen Dateinamen, der Projekt, Datensatz und Lauf unterscheidbar macht, und vermeiden Sie, dass ein neuer Versuch unbemerkt das Log eines früheren Laufs überschreibt. Lassen Sie Fehlerausgaben nicht unbeachtet: Eine Datei mit regulären Ausgaben kann neben einer Fehlermeldung in der Fehlerausgabe entstehen.

Prüfen Sie beim Wiederanlauf:

• Eingaben: Liegen die erwarteten Dateien am angegebenen Ort, und kann das Skript sie lesen?
• Umgebung: Wird das vorgesehene Python-Umfeld mit den passenden Abhängigkeiten verwendet?
• Ausgaben: Werden Dateien tatsächlich im Zielverzeichnis angelegt, und sind sie lesbar?
• Fortschritt: Gibt es neue Logeinträge oder geänderte Ausgaben, die zum erwarteten Arbeitsschritt passen?
• Plausibilität: Stimmen ausgewählte Resultate mit einem bekannten Testdatensatz oder einer reproduzierbaren Referenz überein?

Wenn das Skript keine Checkpoints unterstützt, kann ein Abbruch bedeuten, dass die Analyse von vorn beginnen muss. Speichern Sie Zwischenstände nicht einfach durch Kopieren einer teilweise geschriebenen Datei; prüfen Sie, ob das Programm einen konsistenten Wiederaufnahmepunkt erzeugt und wieder einlesen kann. Für sensible Forschungsdaten gehören zudem Zugriffsrechte, Speicherort, Aufbewahrung und Übertragungsweg in die Prüfung. Die Verfügbarkeit einer Remote-Umgebung ist keine automatische Freigabe, personenbezogene oder vertrauliche Daten dort abzulegen; maßgeblich sind die Datenschutzvorgaben Ihrer Hochschule und Ihres Projekts.

Ein lokales Terminal wird geschlossen: Das beendet nicht automatisch jeden Prozess auf einem Remote-Mac. Wenn das Skript in einer noch aktiven tmux-Sitzung läuft, kann es weiterarbeiten. War es hingegen direkt an eine entfernte Shell gebunden, kann das Ende dieser Shell den Prozess beeinträchtigen. Nach der Rückkehr sollten Sie deshalb Sitzung, Prozess und Dateien prüfen, bevor Sie einen neuen Lauf starten.

SSH-Verbindung ist weg, aber der Remote-Host ist erreichbar: Melden Sie sich erneut an und verbinden Sie sich mit der tmux-Sitzung, sofern Sie den Prozess dort gestartet haben. Ohne tmux kann die ursprüngliche Terminalansicht fehlen, selbst wenn ein Prozess noch existiert. Verlassen Sie sich nicht auf eine einzelne Prozessanzeige: Ein fehlender Fortschritt in Logs oder Ausgaben erfordert weitere Fehlersuche.

Der Remote-Mac wurde neu gestartet: tmux ist keine Wiederherstellung nach einem Neustart. Eine Sitzung, die nur im Speicher des Hosts existierte, ist dadurch nicht automatisch wieder verfügbar. Prüfen Sie zuerst, ob die Eingaben, Logs und eventuell gespeicherten Checkpoints erhalten sind; danach entscheiden Sie anhand der Anwendung, ob ein Fortsetzen möglich ist oder ein kontrollierter Neustart erforderlich ist.

Die Analyse dauert lange: Legen Sie vor dem Start fest, welche Logs, Zwischenergebnisse und Checkpoints das Skript erzeugt und wie Sie einen Wiederanlauf testen. Wenn die Berechnung eine Jobplanung, festgelegte Ressourcenlimits oder einen HPC-Cluster benötigt, richten Sie sich nach den Regeln Ihrer Hochschule. Ein Remote-Mac ist keine pauschale Alternative zu einem verwalteten HPC-System.

Bevor Sie eine Analyse wieder aufnehmen, arbeiten Sie diese Punkte ab:

• [ ] Die SSH-Verbindung führt zum erwarteten Host und Benutzerkonto.
• [ ] Sie wissen, ob der ursprüngliche Prozess in tmux, einer normalen Shell oder einem anderen Startkontext lief.
• [ ] Eine bestehende Sitzung wurde geprüft, bevor ein weiterer Prozess gestartet wurde.
• [ ] Prozessanzeige und Logfortschritt wurden gemeinsam bewertet.
• [ ] Eingabe-, Ausgabe- und Arbeitsverzeichnisse stimmen mit dem ursprünglichen Lauf überein.
• [ ] Es gibt keine ungeprüften Fehlermeldungen oder konkurrierenden Schreibvorgänge.
• [ ] Die Ausgabedateien sind vollständig und entsprechen einem bekannten Testfall oder einer fachlichen Plausibilitätsprüfung.
• [ ] Bei einem langen Lauf ist geklärt, ob Checkpoints existieren und ob sie tatsächlich wieder eingelesen werden können.
• [ ] Host-Neustart, administrative Beendigung und Dienstlebenszyklus wurden als mögliche Ursachen berücksichtigt.
• [ ] Ressourcenbedarf und Hochschulregeln wurden geprüft, bevor ein HPC-geeigneter Auftrag auf einem Remote-Mac fortgesetzt wird.

Treffen Sie die Entscheidung nach dem Befund, nicht nach dem Wunsch, möglichst schnell weiterzurechnen. Ist der Prozess aktiv, das Log wächst plausibel und die Ausgaben sind konsistent, können Sie die bestehende Sitzung beobachten. Ist der Prozess beendet, aber ein geprüfter Checkpoint vorhanden, testen Sie den Wiederanlauf mit den vorgesehenen Eingaben. Fehlen verlässliche Logs oder sind Ausgaben widersprüchlich, sichern Sie vorhandene Dateien und starten Sie erst nach Klärung der Ursache neu.

Wenn Windows- oder Linux-Rechner im Labor den macOS-spezifischen Teil des Workflows nicht abdecken, ist ein eigener Mac nicht automatisch die wirtschaftlichste Wahl: Anschaffung und Wartung binden Budget, während eine Hochschul-HPC zwar für verwaltete Batchläufe ausgelegt sein kann, aber nicht zwingend die benötigte macOS-Umgebung bereitstellt. Für macOS-spezifische Software oder Kompatibilitätstests kann ein Remote-Mac daher eine passende Ergänzung sein; für große, planungsabhängige Berechnungen sollten Sie die HPC-Regeln vorziehen. Einen Überblick über Zugangswege und Einsatzbedingungen für Remote-Macs bei JEXCLOUD finden Sie online; die verfügbaren Bestellmöglichkeiten für einen Remote-Mac sollten Sie erst prüfen, wenn die macOS-Anforderung feststeht und die HPC-Richtlinien Ihre Aufgabe nicht besser abdecken.

• Remote-Mac-Aufgaben nach einem SSH-Abbruch zuverlässig weiterführen
• SSH-Verbindungsprobleme zum Remote-Mac systematisch beheben