Hier finden Sie gebündelte Prüfpfade für Verbindung, Builds, Runner, Netzwerk und Speicher dedizierter physischer Apple-Silicon-Nodes. Jeder Schritt nennt das Prüfobjekt, den Befehl und das Ergebnis, anhand dessen Sie den nächsten Schritt bestimmen können.
Wenn Sie bereits einen Node haben, notieren Sie zuerst Node-ID und Zeitraum des Problems. Vor der Bestellung können Sie sich die drei verfügbaren Konfigurationen und vier wählbaren Nodes ansehen.
Ändern Sie nicht gleichzeitig Konfigurationen auf mehreren Ebenen. Wählen Sie zuerst die Kategorie, die am besten zum beobachteten Verhalten passt, führen Sie deren Basisprüfungen durch und gehen Sie anschließend mit den Ergebnissen zur nächsten Ebene.
Beginnen Sie mit Adresse, Port, Schlüsselberechtigungen, Hostschlüssel-Fingerabdruck und Gültigkeit der Zugangsdaten. Wenn SSH funktioniert, die grafische Sitzung aber fehlerhaft ist, prüfen Sie anschließend Auflösung, Sperrstatus und Sitzungswiederherstellung.
Fixieren Sie zuerst die Xcode-Version und sichern Sie die Original-Logs. Prüfen Sie anschließend Signieridentität, Provisioning-Profil, Schlüsselbundberechtigungen, DerivedData und Arbeitsverzeichnis des Runners.
Prüfen Sie im Control Panel Bestellnummer, Mietzeitraum, Node-ID und Zahlungsstatus. Senden Sie in Tickets weder private Schlüssel noch vollständige Zahlungsdaten.
Notieren Sie freien Speicher, Volume-Bezeichnung, Netzwerkqualität und den Thunderbolt-Gerätebaum. Formatieren Sie Datenträger oder erstellen Sie Volumes nicht ohne vorherige Sicherung neu.
Ein Verbindungsfehler bedeutet nicht zwangsläufig, dass der Node offline ist. Unterscheiden Sie zunächst zwischen falscher Adresse, nicht erreichbarem Port, unzulässigen lokalen Schlüsselberechtigungen, geändertem Hostschlüssel-Fingerabdruck und einer serverseitig abgelehnten Authentifizierung.
$ chmod 600 ~/.ssh/orbvps_node
$ ssh-keygen -F node-address
$ nc -vz node-address 22
$ ssh -vvv -p 22 \
-i ~/.ssh/orbvps_node \
node-user@node-addressBestätigen Sie, dass Benutzername und privater Schlüssel zum aktuellen Node gehören, und prüfen Sie, ob ein anderes IdentityFile in der lokalen SSH-Konfiguration den Schlüssel überschreibt.
Prüfen Sie die im Control Panel angezeigte Adresse und den Port, deaktivieren Sie testweise lokale Proxy-Regeln und wiederholen Sie den Test. Notieren Sie Zeitpunkt und verwendetes Netzwerk.
Bewahren Sie die vollständige verbose-Ausgabe auf und löschen Sie Hosteinträge nicht wiederholt. Prüfen Sie zunächst, ob der Port mit den Node-Übergabedaten übereinstimmt.
Ignorieren Sie die Warnung nicht direkt. Vergleichen Sie zuerst den angezeigten Fingerabdruck mit den Übergabedaten im Control Panel und aktualisieren Sie den lokalen Eintrag erst nach Bestätigung der Node-Daten.
Lesen Sie Adresse, Port und Benutzernamen erneut aus dem Control Panel aus. Verwenden Sie keine aus dem Verlauf alter Terminals abgeleiteten Adressen.
Der private Schlüssel sollte für den aktuellen Benutzer les- und schreibbar sein. Auch SSH-Konfiguration und übergeordnete Verzeichnisse dürfen nicht von unbeteiligten Benutzern geändert werden können.
Wiederholen Sie den Versuch im verbose-Modus, bewahren Sie die vollständige Ausgabe vom Verbindungsaufbau bis zur Fehlerstelle auf und anonymisieren Sie die Adresse.
Grafische Sitzung und SSH sind getrennte Verbindungswege. Eine funktionierende SSH-Verbindung garantiert keine korrekte Konfiguration der grafischen Sitzung; dokumentieren Sie die beiden Fälle daher separat.
Verwenden Sie ausschließlich die für den aktuellen Node bereitgestellten Zugangsdaten für die grafische Sitzung. Nach einem Wechsel der Zugangsdaten sollten Sie gespeicherte alte Passwörter im Client löschen, damit keine wiederholten automatischen Anmeldeversuche erfolgen.
Bei schwarzem Bildschirm oder eingefrorener Anzeige verbinden Sie sich zunächst mit niedrigerer Auflösung und nur einem Monitor. Erhöhen Sie die Auflösung erst nach dem Öffnen des Desktops schrittweise, um einen Zusammenhang mit den Anzeigeparametern zu prüfen.
Wenn der Sperrbildschirm sichtbar ist, Sie aber nicht fortfahren können, prüfen Sie zunächst Tastatureingabe und Fokus. Kontrollieren Sie anschließend per SSH Systemlast und freien Speicher.
Schließen Sie die Clientverbindung aktiv, warten Sie, bis die Sitzung freigegeben wurde, und verbinden Sie sich anschließend erneut. Erstellen Sie nicht schnell hintereinander mehrere parallele grafische Sitzungen, da dies die aktive Desktop-Sitzung unübersichtlich macht.
Geben Sie an, ob SSH funktioniert, an welchem Schritt der grafische Client stoppt, welche Auflösung verwendet wurde, den originalen Clientfehler und den Zeitraum der letzten erfolgreichen Verbindung. Senden Sie keine vollständigen Zugangspasswörter.
Bestätigen Sie zuerst den tatsächlich verwendeten Xcode-Pfad und die Version. Prüfen Sie anschließend verfügbare Signieridentitäten, Provisioning-Profile, Schlüsselbundzugriff und Projektcache. Aktualisieren Sie Abhängigkeiten und wechseln Sie Signiermaterial nicht innerhalb derselben Prüfung gleichzeitig.
xcodebuild -version .xcode-select -p das aktuelle Developer-Verzeichnis..xcresult und senden Sie nicht nur die letzten Terminalzeilen ein.$ xcode-select -p
$ xcodebuild -version
$ security find-identity \
-v -p codesigning
$ profiles show \
-type provisioning
$ xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
-resultBundlePath Build.xcresult \
buildBewahren Sie Befehl, Scheme, Configuration, fehlgeschlagenes Ziel, den ersten Fehler und dessen Kontext auf. Entfernen Sie vor dem Einreichen Repository-Zugangsdaten, Tokens und Geschäftsdaten.
Ein als online angezeigter selbst gehosteter Runner bedeutet nicht, dass die Aufgabenumgebung vollständig ist. Prüfen Sie Runner-Prozess, Berechtigungen des Arbeitsverzeichnisses, Cache-Auslastung, parallele Aufgaben und den Wiederherstellungspfad nach einem Neustart.
Bestätigen Sie, dass der Runner-Dienst unter dem erwarteten Benutzer läuft und die Startparameter auf die richtige Konfiguration verweisen. Wenn der Prozess wiederholt beendet wird, sichern Sie zuerst Exit-Code und aktuelle Logs.
ps aux | grep -i runner
Prüfen Sie Eigentümer, freien Speicher und Sperrdateien alter Aufgaben. Löschen Sie kein Arbeitsverzeichnis, das noch von einer laufenden Aufgabe verwendet wird.
df -h && du -sh ./work
Unterscheiden Sie Abhängigkeitscache, DerivedData und Build-Artefakte. Ermitteln Sie zuerst den fehlerhaften Cache-Schlüssel und bereinigen Sie nur das betreffende Projekt, statt alle wiederverwendbaren Inhalte zu löschen.
du -sh ~/Library/Developer/Xcode/DerivedData
Prüfen Sie, ob mehrere Aufgaben denselben Schlüsselbund, Simulator oder dasselbe Arbeitsverzeichnis verwenden. Starten Sie nach einem Neustart zuerst eine kontrollierte Testaufgabe und setzen Sie erst danach die normale Warteschlange fort.
uptime && sysctl -n hw.memsize
Wenn die Testaufgabe erfolgreich ist, parallele Aufgaben jedoch fehlschlagen, geben Sie zusätzlich Parallelitätszahl, Aufgaben-Tags und eine Liste gemeinsam genutzter Ressourcen an.
Sinkender Durchsatz, langsamere Builds und ein verschwundenes externes Volume können ähnlich aussehen. Erfassen Sie zuerst die integrierten Diagnosedaten des Systems und bestimmen Sie anschließend, ob das Problem im Netzwerk, Dateisystem oder Pfad zum externen Gerät liegt.
Verwenden Sie die integrierten Netzwerkqualitätstools, um Upstream, Downstream und Reaktionsfähigkeit zu dokumentieren, und notieren Sie den Testzeitraum. Ergebnisse über Regionen hinweg können durch lokale Anbieter und Routing beeinflusst werden.
networkQuality -v
route -n get default
ifconfigPrüfen Sie zunächst den freien Speicher auf System- und Datenvolume und ermitteln Sie anschließend die größten Arbeitsverzeichnisse. Bei Build-Fehlern sollten Sie insbesondere temporäre Verzeichnisse und DerivedData kontrollieren.
df -h
diskutil list
du -sh ~/Library/Developer/*Prüfen Sie Datenträgerliste und Thunderbolt-Gerätebaum getrennt. Wenn das Gerät sichtbar, das Volume aber nicht eingehängt ist, erfassen Sie zuerst den Status. Löschen oder partitionieren Sie den Datenträger nicht sofort neu.
diskutil list external
system_profiler SPThunderboltDataType
diskutil info /Volumes/VolumeNameOrbVPS-Nodes laufen 365 Tage im Jahr kontinuierlich. System-Upgrades, Toolchain-Wechsel und erforderliche Neustarts plant der Benutzer passend zur Arbeitslast selbst; notwendige dringende Infrastrukturänderungen werden im Control Panel dokumentiert.
Dokumentieren Sie aktuelle macOS-, Xcode- und Runner-Versionen, wichtige Abhängigkeiten sowie rücksetzbare Build-Logs. Überschreiben Sie die Toolchain nicht ohne Ausgangsbasis.
Sichern Sie Repository, Signiermaterial, Runner-Konfiguration, Cache-Strategie und erforderliche Build-Artefakte. Prüfen Sie an einem unabhängigen Speicherort, ob die Sicherung gelesen werden kann.
Pausieren Sie neue Aufgaben, warten Sie das Ende laufender Aufgaben ab und starten Sie erst nach dem Speichern der Logs neu. Ändern Sie während des Neustarts nicht gleichzeitig Netzwerk-, Signier- und Build-Konfiguration.
Prüfen Sie nacheinander SSH, grafischen Desktop, Datenträger-Mounts, Xcode-Version und eine kontrollierte Build-Aufgabe. Stellen Sie erst danach die normale parallele Warteschlange wieder her.
Geben Sie Node-ID, Zeitraum des Auftretens, betroffene Aufgaben, ausgeführte Befehle, Originalausgaben und bereinigte Screenshots an. Bei bestehender Bestellung erstellen Sie das Ticket im Control Panel. Fragen zu Konfiguration oder Region vor dem Kauf können Sie über die Kontaktseite an support@orbvps.com senden.