Zum Hauptinhalt springen

Fehlerbehebung

Runner gibt Fehler 404 aus​

Lösung​

Getting 401 error code from Runner

Problem mit Gathering Facts für localhost​

Das Problem kann bei Semaphore UI auftreten, wenn es über Snap oder Docker installiert wurde.

4:10:16 PM
TASK [Gathering Facts] *********************************************************
4:10:17 PM
fatal: [localhost]: FAILED! => changed=false

Warum das passiert​

Weitere Informationen zur Verwendung von localhost in Ansible finden Sie im Artikel Implicit 'localhost'.

Ansible versucht, Facts lokal zu sammeln, aber Ansible befindet sich in einem eingeschränkten, isolierten Container, der dies nicht erlaubt.

Lösung​

Es gibt zwei Möglichkeiten:

  1. Das Sammeln von Facts deaktivieren:
- hosts: localhost
  gather_facts: False
  roles:
    - ...
  1. Den Verbindungstyp explizit auf ssh setzen:
[localhost]
127.0.0.1 ansible_connection=ssh ansible_ssh_user=your_localhost_user

panic: pq: SSL is not enabled on the server​

Das bedeutet, dass Ihr Postgres nicht über SSL arbeitet.

Lösung​

Fügen Sie die Option sslmode=disable zur Konfigurationsdatei hinzu:

	"postgres": {
		"host": "localhost",
		"user": "postgres",
		"pass": "pwd",
		"name": "semaphore",
		"options": {
			"sslmode": "disable"
		}
	},

fatal: bad numeric config value '0' for 'GIT_TERMINAL_PROMPT': invalid unit​

Das bedeutet, dass Sie versuchen, über HTTPS auf ein Repository zuzugreifen, das eine Authentifizierung erfordert.

Lösung​

  • Öffnen Sie die Ansicht Schlüsselspeicher.
  • Erstellen Sie einen neuen Schlüssel vom Typ Login with password.
  • Geben Sie Ihren Login für GitHub/BitBucket usw. an.
  • Geben Sie das Passwort an. Für GitHub/BitBucket können Sie nicht Ihr Kontopasswort verwenden; stattdessen sollten Sie ein Personal Access Token (PAT) verwenden. Weitere Informationen finden Sie hier.
  • Öffnen Sie nach dem Erstellen des Schlüssels die Ansicht Repositories, suchen Sie Ihr Repository und geben Sie den Schlüssel an.

Git clone oder pull schlägt zeitweise fehl​

Task-Logs können Meldungen wie Git pull failed (...), retrying in 2s enthalten, gefolgt entweder von einem Erfolg oder einem endgültigen Fehlschlag nach mehreren Versuchen.

Warum das passiert​

Der Git-Server (GitHub, GitLab, Bitbucket oder eine selbst gehostete Instanz) war vorübergehend nicht erreichbar, hat einen vorübergehenden HTTP-Fehler zurückgegeben, oder das Netzwerk zwischen Semaphore und dem Server hatte einen kurzen Ausfall. Semaphore wiederholt Clone- und Pull-Vorgänge automatisch, bevor der Task als fehlgeschlagen markiert wird.

Lösung​

  1. Vorübergehende Ausfälle: Lösen sich in der Regel von selbst. Semaphore wiederholt den Vorgang bis zu git_attempts-mal (Standard 4) mit exponentiellem Backoff zwischen den Versuchen.
  2. Häufige Fehler: Erhöhen Sie die Anzahl der Versuche in Ihrer Konfiguration:
{
  "git_attempts": 8
}

Oder über eine Umgebungsvariable:

export SEMAPHORE_GIT_ATTEMPTS=8
  1. Sofortige, dauerhafte Fehler: Wiederholungen helfen hier nicht. Prüfen Sie Repository-URL, Branch-Name, Zugriffsschlüssel und die Netzwerkverbindung vom Semaphore-Server bzw. Runner-Host aus.

Siehe Git-Operationen für Details zu git_client und git_attempts.

Ausgabe eines Bash-Skripts fehlt oder ist unvollständig​

Ein Bash-Task wird erfolgreich abgeschlossen, aber das Log zeigt wenig oder keine Ausgabe von echo, printf oder anderen Befehlen – insbesondere, wenn das Skript schnell beendet wird.

Warum das passiert​

Semaphore erfasst stdout und stderr von Shell-Befehlen, während sie laufen. Sehr kurze Skripte können beendet sein, bevor die gesamte gepufferte Ausgabe gelesen wurde, sodass die letzten Zeilen im Task-Log fehlen können.

Lösung​

  1. Aktualisieren: Neuere Semaphore-Versionen lesen die Prozessausgabe vollständig aus, bevor ein Task als abgeschlossen markiert wird. Aktualisieren Sie Server und Runner, wenn Sie eine ältere Version verwenden.
  2. Ausgabe im Skript leeren (flush), wenn Sie eine garantierte Zustellung benötigen:
#!/bin/bash
echo "Starting deploy"
echo "Done" >&2

Für kritische Diagnosen schreiben Sie in eine Datei innerhalb des Repository-Arbeitsverzeichnisses und geben sie am Ende des Skripts mit cat aus. 3. Stilles vorzeitiges Beenden vermeiden: Verwenden Sie set -euo pipefail und explizite Fehlermeldungen, damit Fehler auch bei knapper Ausgabe sichtbar sind.

unable to read LDAP response packet: unexpected EOF​

Höchstwahrscheinlich versuchen Sie, sich über eine unsichere Methode mit dem LDAP-Server zu verbinden, obwohl dieser eine sichere Verbindung (über TLS) erwartet.

Lösung​

Aktivieren Sie TLS in Ihrer config.json-Datei:

...
"ldap_needtls": true
...

LDAP Result Code 49 "Invalid Credentials"​

Sie haben ein falsches Passwort oder einen falschen binddn.

Lösung​

Verwenden Sie das Tool ldapwhoami und prüfen Sie, ob Ihr binddn funktioniert:

ldapwhoami\
  -H ldap://ldap.com:389\
  -D "CN=/your/ldap_binddn/value/in/config/file"\
  -x\
  -W

Es fragt interaktiv nach dem Passwort und sollte den Code 0 zurückgeben und den angegebenen DN ausgeben.

Sie können auch die folgenden Artikel lesen:

LDAP Result Code 32 "No Such Object"​

Das Verzeichnis enthält keinen Eintrag unter dem Distinguished Name, nach dem Semaphore gefragt hat. Fast immer ist ldap_searchdn falsch, seltener ldap_binddn.

Lösung​

Prüfen Sie mit denselben Zugangsdaten, die Semaphore verwendet, ob die Suchbasis existiert:

ldapsearch\
  -H ldap://ldap.example.com:389\
  -D "CN=/your/ldap_binddn/value/in/config/file"\
  -b "/your/ldap_searchdn/value/in/config/file"\
  -x\
  -W\
  -s base
  • Ergebniscode 32 bei diesem Befehl bedeutet, dass die Basis selbst nicht existiert. Korrigieren Sie ldap_searchdn in config.json; die übliche Ursache ist ein Tippfehler in einer Komponente, etwa OU=Users statt des tatsächlichen OU=People.
  • Ergebniscode 0 bedeutet, dass die Basis in Ordnung ist und das Problem in ldap_searchfilter liegt: Er trifft auf keinen Eintrag unterhalb dieser Basis zu.

Die Bedeutung der einzelnen Optionen finden Sie unter LDAP und AD.