Zum Inhalt springen
Diese Seite wurde automatisch übersetzt. Englisches Original ansehen.

Fehlerbehebung

Diese Seite fasst seltene, hostspezifische Probleme zusammen, die die meisten Sailwright-Setups nicht betreffen.

Windows: Cygwin-Ansible wird von einer Host-Installation überlagert

Abschnitt betitelt „Windows: Cygwin-Ansible wird von einer Host-Installation überlagert“

Unter Windows mit Cygwin kann die Ansible-Installation innerhalb von Cygwin von einer anderen Python- oder Ansible-Installation des Windows-Hosts überlagert werden.

Wenn das passiert:

  • Installieren Sie Ansible nicht direkt auf dem Windows-Host.
  • Entfernen Sie widersprüchliche Ansible-Installationen auf Host-Ebene.
  • Installieren und betreiben Sie Ansible stattdessen über die Cygwin-Python-Umgebung.

Das Ausführen von Ansible unter macOS kann einen Fork-Safety-Absturz auslösen, der etwa so aussieht:

Terminal window
TASK [Gathering Facts] ***************************************************************************************************************************************
objc[9473]: +[NSNumber initialize] may have been in progress in another thread when fork() was called.
objc[9473]: +[NSNumber initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
ERROR! A worker was found in a dead state

Umgehen Sie das Problem, indem Sie vor dem Ausführen von Ansible diese Umgebungsvariable setzen:

Terminal window
export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

Das Linux-libvirt-Provisioning wartet darauf, dass virsh domifaddr eine IPv4-Adresse des Gasts meldet. Sailwright prüft zuerst den Guest Agent und danach die libvirt-DHCP-Leases. Liefern beide Quellen keine Adresse, kann das Provisioning das temporäre Ansible-Inventory nicht erstellen.

Bestätigen Sie zunächst, dass die VM läuft, und fragen Sie dieselbe libvirt-Verbindung ab, die Sailwright verwendet:

Terminal window
virsh --connect qemu:///system domifaddr <domain> --source agent
virsh --connect qemu:///system domifaddr <domain> --source lease

Ist die Agent-Abfrage leer, warten Sie, bis der Gast den Boot-Vorgang abgeschlossen hat, und stellen Sie sicher, dass im Image qemu-guest-agent installiert ist und läuft. Ist die Lease-Abfrage leer, stellen Sie sicher, dass die VM an ein von libvirt verwaltetes Netzwerk mit sichtbaren DHCP-Leases angeschlossen ist:

Terminal window
virsh --connect qemu:///system net-info default
virsh --connect qemu:///system net-dhcp-leases default

Existiert das Netzwerk default, ist aber inaktiv, aktivieren Sie es:

Terminal window
sudo virsh --connect qemu:///system net-start default
sudo virsh --connect qemu:///system net-autostart default

Bei DEV_ALCHEMY_LIBVIRT_URI=qemu:///session führen Sie dieselben Prüfungen gegen qemu:///session durch. Session-VMs verwenden standardmäßig das User-Mode-Networking von libvirt, weshalb die Sichtbarkeit über den Guest Agent in der Regel die zuverlässigste IP-Quelle ist.