tmux auf einem Remote-Mac: Stoppen Aufgaben bei Abbruch? Konfigurationsleitfaden 2026

Zwei getrennte Prozessrollen sind für tmux entscheidend: Der tmux-Client zeigt ein Terminal an, während der tmux-Server die Sitzung und ihre Fenster verwaltet. Diese Trennung ist in der offiziellen tmux-Einführung beschrieben. Daraus folgt die wichtigste Entscheidung: Ein SSH-Abbruch beendet eine laufende Aufgabe in einer korrekt getrennten tmux-Sitzung normalerweise nicht. Schlafmodus, Neustart, ein beendeter Prozess oder ein zurückgezogener Knoten liegen jedoch außerhalb dieser Schutzfunktion.

Zeitplan für diese Woche: Richten Sie zuerst eine benannte Sitzung ein, führen Sie einen ungefährlichen Testlauf aus und prüfen Sie danach gezielt Netzwerkabbruch, Leerlauf, Schlafmodus und kontrollierten Neustart. Verwenden Sie tmux für interaktive Langläufer; übergeben Sie Aufgaben mit Autostart, Wiederholungslogik oder verbindlicher Verfügbarkeit an launchd oder einen CI-Runner.

Diese Anleitung richtet sich an Sie, wenn Sie über SSH auf einem entfernten Mac kompilieren, testen, Daten verarbeiten oder einen AI-Agenten laufen lassen. DevOps-Ingenieure finden hier die Abgrenzung zwischen Sitzungsfortsetzung und echtem unbeaufsichtigtem Dienst. Plattformverantwortliche erhalten eine Abnahmeprüfung für Netzwerk, Energieverwaltung und Neustartverhalten.

Fehlergrenzen zwischen SSH und Aufgabe

Ein leerer Terminalbildschirm nach der erneuten Anmeldung ist kein Beweis dafür, dass der Build beendet wurde. Mehrere Ebenen müssen getrennt untersucht werden:

• SSH-Verbindung: Der Transport zwischen Ihrem Rechner und dem Remote-Mac ist unterbrochen.
• Login-Shell: Die Shell kann beendet worden sein, ohne dass ein Prozess in tmux betroffen ist.
• tmux-Client: Das sichtbare Terminal wurde getrennt oder geschlossen.
• tmux-Server: Dieser hält Sitzung, Fenster und Pane offen.
• Aufgabenprozess: Compiler, Testprogramm, Skript oder Agent kann unabhängig davon weiterlaufen oder abgestürzt sein.

Die tmux-Handbuchreferenz beschreibt Sitzungen als serverseitig verwaltete Objekte. Ein Client kann sich an eine Sitzung anhängen und später wieder trennen; die sichtbare SSH-Verbindung ist deshalb nicht dasselbe wie der Lebenszyklus des eigentlichen Prozesses.

Beginnen Sie nach einem Abbruch nicht sofort mit demselben Befehl. Prüfen Sie zuerst:

tmux ls
tmux attach-session -t build-ios

Falls die Sitzung nicht gefunden wird, kontrollieren Sie außerdem das verwendete Konto:

id -un
echo "$HOME"
ps -axo user,pid,ppid,etime,command | grep -E 'xcodebuild|swift|python|node'

Ein Prozess kann unter einem anderen Benutzer laufen, wenn Sie sich nach dem Abbruch mit einem anderen Konto anmelden. Auch ein falsches Socket- oder Sitzungsziel kann den Eindruck erwecken, die Aufgabe sei verschwunden. Löschen Sie daher weder tmux-Sockets noch Prozesse, bevor Sie Benutzerkonto, Prozessliste, Arbeitsverzeichnis und Logdatei verglichen haben.

Läuft eine Aufgabe nach einem SSH-Abbruch weiter?
In einer korrekt gestarteten und getrennten tmux-Sitzung meistens ja. Das gilt nur, solange der tmux-Server, der Aufgabenprozess und der Host selbst weiterlaufen. Ein SSH-Abbruch schützt nicht vor einem Prozessfehler, einem Systemneustart oder einer Energieverwaltung, die den Mac schlafen legt.

Benannte Sitzungen und überprüfbare Zustände

Eine reproduzierbare Sitzung beginnt mit einem eindeutigen Namen. Dadurch vermeiden Sie, dass Sie versehentlich eine alte Sitzung öffnen oder in einem falschen Pane arbeiten:

tmux new-session -s build-ios
cd /PFAD/ZUM/PROJEKT
export LOG_FILE="$HOME/logs/build-ios.log"
mkdir -p "$HOME/logs"

Starten Sie eine Aufgabe mit sichtbarer und dauerhaft gespeicherter Ausgabe:

script -q "$LOG_FILE" xcodebuild \
  -workspace /PFAD/ZUM/PROJEKT/Projekt.xcworkspace \
  -scheme PROJEKT_SCHEME \
  test

Die genaue Syntax hängt vom Projekt ab. Verwenden Sie für Pfade, Scheme-Namen, Konten, Socket-Namen und Schlüssel ausschließlich Ihre echten Werte; Platzhalter dürfen nicht unverändert in einer Produktionssitzung bleiben.

Trennen Sie anschließend den Client mit der tmux-Tastenkombination Ctrl-b gefolgt von d. Danach prüfen Sie von einer neuen SSH-Verbindung aus:

tmux ls
tmux capture-pane -pt build-ios -S -80
pgrep -fl xcodebuild
pwd

Diese Prüfung beantwortet vier verschiedene Fragen:

1. Existiert die Sitzung noch?
2. Gibt es im Pane neue Ausgabe?
3. Existiert der erwartete Prozess noch?
4. Befindet sich die Sitzung im richtigen Arbeitsverzeichnis?

Das erneute Anhängen erfolgt erst nach dieser Bestandsaufnahme:

tmux attach-session -t build-ios

Wie lesen Sie das Build-Protokoll nach einer erneuten Anmeldung?
Für den aktuellen Bildschirminhalt verwenden Sie tmux capture-pane. Für eine vollständige Nachverfolgung ist eine Logdatei robuster, etwa mit tee oder script. Prüfen Sie zusätzlich Dateigröße, Änderungszeit und die letzten Zeilen:

tail -n 80 "$HOME/logs/build-ios.log"
stat "$HOME/logs/build-ios.log"

Eine vorhandene Logdatei beweist allerdings nicht, dass die Aufgabe noch läuft. Sie zeigt nur, dass irgendwann Ausgabe geschrieben wurde. Prozessstatus und aktuelle Änderungszeit müssen zusammen betrachtet werden.

Hinweis: Wenn eine leere Sitzung angezeigt wird, starten Sie den Build nicht reflexartig erneut. Sichern Sie zuerst tmux ls, ps, das Arbeitsverzeichnis und die letzten Logzeilen. So vermeiden Sie doppelte Tests, konkurrierende Artefakte und schwer erklärbare Dateisperren.

Umgebung, Konten und Zugangsdaten

Nach einer neuen SSH-Anmeldung oder einem neuen Pane kann sich die Umgebung anders anfühlen, obwohl die Sitzung selbst erhalten blieb. Besonders häufig sind Unterschiede bei Login-Shell, PATH, Homebrew-Pfad, Arbeitsverzeichnis und SSH-Agent.

Prüfen Sie die Umgebung innerhalb der bestehenden Sitzung und in einer neuen Shell:

echo "$SHELL"
echo "$PATH"
command -v tmux
command -v brew
env | sort > "$HOME/logs/env-current.txt"

Wenn brew oder ein Compiler nicht gefunden wird, ist die Aufgabe nicht automatisch verloren. Ein nicht interaktiver Start lädt nicht zwingend dieselben Konfigurationsdateien wie eine interaktive Login-Shell. Die Homebrew-Formula-Seite für tmux dokumentiert den Installationsweg, ersetzt aber keine Prüfung Ihres tatsächlichen Pfads.

Legen Sie für reproduzierbare Aufgaben ein explizites Startskript an:

#!/bin/zsh
set -u

export PATH="/PFAD/ZU/HOMEBREW/bin:/usr/bin:/bin"
cd /PFAD/ZUM/PROJEKT || exit 1

exec /PFAD/ZUM/BEFEHL

Vermeiden Sie es, geheime Tokens oder private Schlüssel direkt in die tmux-Befehlszeile zu schreiben. Eine Sitzung kann von weiteren Clients eingesehen werden, und Shell-Historien können Befehle speichern. Für SSH-Schlüssel prüfen Sie den Agent-Zustand nur so weit wie nötig:

ssh-add -l
ssh -T git@HOST-PLATZHALTER

Wenn der Agent nach einer erneuten Verbindung nicht verfügbar ist, handelt es sich um ein Zugangsproblem, nicht um einen tmux-Verlust. Der Build kann trotzdem weiterlaufen, sofern er seine Quellen bereits geladen hat. Für den nächsten Start benötigen Sie dann einen dokumentierten Schlüsselweg, eine passende Agent-Weiterleitung oder einen sicheren nichtinteraktiven Credential-Mechanismus.

Für die Verbindung selbst müssen Sie Remote Login auf dem Zielsystem korrekt aktivieren. Die Dokumentation zu Remote Login beschreibt die dafür relevanten Systemeinstellungen. Verwenden Sie für die Abnahme dasselbe Konto, denselben Projektpfad und dieselbe Schlüsselkonfiguration wie im späteren Betrieb.

Schlafmodus, Netzwerk und Neustart

tmux verhindert weder den Schlafmodus noch einen Neustart. Das ist die wichtigste Grenze zwischen „Verbindung geschützt“ und „Host dauerhaft verfügbar“.

Ein ausgeschaltetes Display ist nicht automatisch dasselbe wie ein schlafender Mac. Ebenso bedeutet aktiviertes Aufwachen für Netzwerkzugriffe nicht, dass ein interaktiver Compilerprozess unter allen Bedingungen weiterarbeitet. Prüfen Sie die Energieoptionen des konkreten Knotens anhand der aktuellen Dokumentation zu Schlafen und Aufwachen.

Für einen zeitlich begrenzten Test können Sie einen Befehl verwenden, der den Schlafmodus während seiner Laufzeit verhindert. Das ist keine dauerhafte Plattformkonfiguration:

caffeinate -dimsu -- /PFAD/ZUM/LANGEN-BEFEHL

Testen Sie damit nur eine Aufgabe, deren Verhalten Sie kontrollieren können. Eine dauerhafte Änderung der Energieverwaltung sollte dokumentiert, auf den Zweck des Knotens abgestimmt und nach dem Wartungsfenster wieder überprüft werden. Bei gemeinsam genutzten oder gemieteten Systemen dürfen Sie solche Einstellungen nicht ohne Freigabe verändern.

Warum stoppt eine tmux-Aufgabe, wenn macOS schläft?
Weil tmux nur Prozesse innerhalb der laufenden Betriebssystemsitzung verwaltet. Wenn der Host schläft, kann die CPU-Ausführung pausieren, die Netzwerkverbindung abbrechen oder ein abhängiger Dienst nicht mehr erreichbar sein. Nach dem Aufwachen kann der Prozess weiterlaufen, blockiert sein oder bereits beendet worden sein. Das lässt sich nicht aus der Existenz der tmux-Sitzung ableiten.

Ein kontrollierter Neustart beendet den tmux-Server. Eine normale getrennte Sitzung ist kein Wiederherstellungsmechanismus über einen Systemstart hinweg. Sichern Sie vor einem Neustart deshalb:

tmux list-sessions
tmux capture-pane -pt build-ios -S -200 > "$HOME/logs/build-ios-pane.txt"
ps -axo pid,ppid,etime,command > "$HOME/logs/processes-before-reboot.txt"

Notieren Sie den exakten Startbefehl, Commit oder Arbeitsstand und das erwartete Ergebnis. Bei einem fehlgeschlagenen Test müssen Sie entscheiden können, ob ein sicherer Neustart, ein erneuter Build oder eine manuelle Bereinigung erforderlich ist.

Für Aufgaben, die nach dem Boot automatisch starten sollen, ist launchd die passendere Systemebene. Die offizielle Anleitung zum Erstellen von launchd-Aufträgen erklärt, wie Hintergrundaufgaben registriert und verwaltet werden. Für moderne App-nahe Dienste bietet die Service-Management-Dokumentation weitere Orientierung. Definieren Sie dabei ausdrücklich:

• welches Konto den Dienst ausführt,
• welches Arbeitsverzeichnis verwendet wird,
• wohin Standardausgabe und Fehler geschrieben werden,
• wann ein Neustart erlaubt ist,
• wann ein Fehler endgültig an CI oder Monitoring gemeldet wird.

Soll ein dauerhaft laufendes Skript in tmux oder als macOS-Dienst betrieben werden?
Für manuelle Entwicklung, einmalige Migrationen und interaktive Diagnose ist tmux geeignet. Für Autostart, Überwachung, definierte Wiederholungen und nachweisbare Statusmeldungen sollten Sie launchd oder einen CI/CD-Runner einsetzen. tmux kann dabei weiterhin als Diagnosewerkzeug dienen, aber nicht als alleinige Betriebssteuerung.

Wiederherstellungstest und Abnahme

Führen Sie die Tests in einer Reihenfolge durch, die den Schaden begrenzt. Verwenden Sie zunächst einen reproduzierbaren, nicht destruktiven Auftrag und schreiben Sie die Ausgaben in ein separates Verzeichnis.

1. Ausgangszustand sichern: Erfassen Sie Konto, Host, Arbeitsverzeichnis, Commit, Startbefehl, Sitzungsname und Logpfad.
2. Aktive Trennung prüfen: Starten Sie die Aufgabe in tmux, trennen Sie den Client und hängen Sie ihn erneut an.
3. Netzwerkabbruch simulieren: Unterbrechen Sie nur den SSH-Client, nicht den Host. Prüfen Sie anschließend Sitzung, Prozess und Log.
4. Längeren Leerlauf prüfen: Lassen Sie die Aufgabe ohne Eingabe laufen und kontrollieren Sie, ob Ausgabe, Prozessstatus und Dateiänderungen konsistent bleiben.
5. Schlafverhalten testen: Verwenden Sie einen kontrollierten Test mit dokumentierter Energieeinstellung. Prüfen Sie vor und nach dem Aufwachen Prozess, Log und Netzwerkzugriff.
6. Neustart kontrollieren: Sichern Sie Beweise, starten Sie den Mac mit Freigabe neu und prüfen Sie, dass die alte tmux-Sitzung erwartungsgemäß nicht mehr als vorhanden angenommen wird.
7. Wiederanlauf dokumentieren: Führen Sie den Task nur nach einer klaren Entscheidung erneut aus. Halten Sie fest, ob Artefakte wiederverwendbar, beschädigt oder zu löschen sind.

Verwenden Sie diese Abnahmeliste:

• [ ] Sitzungsname und Konto sind eindeutig dokumentiert.
• [ ] Arbeitsverzeichnis und Commit sind vor dem Start festgehalten.
• [ ] Der Prozess lässt sich unabhängig von der Terminalanzeige finden.
• [ ] Die Logdatei enthält Start, Fortschritt und Exit-Status.
• [ ] Ein reiner SSH-Abbruch wurde ohne Doppelstart getestet.
• [ ] Schlafmodus und ausgeschaltetes Display wurden nicht verwechselt.
• [ ] Ein kontrollierter Neustart wurde separat bewertet.
• [ ] Der Startbefehl ist ohne private Zugangsdaten reproduzierbar.
• [ ] Für Fehler und Wiederholungen existiert eine Grenze.
• [ ] Für Autostart wurde launchd oder ein CI/CD-Mechanismus bewertet.

Entscheidung nach Fehlerklasse

Die folgende Zuordnung trennt die drei Betriebsarten, statt alle Probleme mit tmux lösen zu wollen:

VPSMAC kann für diese Tests sinnvoll sein, wenn Sie keinen eigenen Mac dauerhaft bereitstellen möchten und eine zugängliche Remote-Umgebung für Build-, Test- oder Wartungsaufgaben benötigen. Prüfen Sie vor der Auswahl eines Knotens die gewünschte Remote-Mac-Variante von VPSMAC und dokumentieren Sie, über welchen Zugang Sie im Fehlerfall noch auf das System gelangen.

Der Unterschied zu einem eigenen Mac mini liegt nicht nur im Preis. Beim eigenen Gerät tragen Sie Stromversorgung, Netzwerkausfall, Ersatzhardware und physische Wiederherstellung selbst; bei einer gewöhnlichen Linux-Cloud fehlen dagegen macOS-spezifische Werkzeuge und ein echter Mac-Ausführungspfad. Eine gemietete Umgebung löst diese Punkte nicht automatisch: Schlafprofile, Wartungsfenster, Zugriffsrechte und Datenhaltung müssen weiterhin geprüft werden. Für eine zeitlich begrenzte Testumgebung kann die Auswahl eines passenden M4-Knotens von VPSMAC jedoch praktischer sein als der spontane Kauf zusätzlicher Hardware.

Wenn Sie langfristig unveränderte Hochlast benötigen, physische Schnittstellen kontrollieren müssen oder eigene Ersatz- und Backup-Prozesse voraussetzen, ist ein selbst betriebenes Gerät möglicherweise die bessere Wahl. Benötigen Sie dagegen vor allem eine erreichbare macOS-Umgebung für interaktive Langläufer, wiederholbare Tests und klar dokumentierte Wiederherstellung, sollten Sie die Mietumgebung zuerst mit genau den oben beschriebenen Abbruch-, Schlaf- und Neustarttests abnehmen. So entscheiden Sie anhand von Logdaten und Prozesszuständen, nicht anhand eines leeren Terminals.