Überwachen und Behandeln von Problemen mit selbstgehosteten Runnern

Du kannst deine selbst gehosteten Runner überwachen, um ihre Aktivität einzusehen und gängige Probleme zu diagnostizieren.

Platform navigation

In diesem Artikel

Verwenden von selbstgehosteten Runnern auf Repositoryebene

Möglicherweise kannst du keinen selbstgehosteten Runner für ein Repository im Besitz deiner Organisation erstellen.

Unternehmens- und Organisationsbesitzerinnen können wählen, für welche Repositorys die Erstellung selbstgehosteter Runner auf Repositoryebene erlaubt ist. Benutzerinnen mit der Berechtigung „Organisationsrunner und Runnergruppen verwalten“ können nur auswählen, für welche Repositorys die Erstellung selbstgehosteter Runner auf Repositoryebene für Repositorys in Ihrer Organisation erlaubt ist.

Weitere Informationen zu benutzerdefinierten Organisationsrollen finden Sie unter „Informationen zu benutzerdefinierten Organisationsrollen“.

Weitere Informationen findest du unter Erzwingen von Richtlinien für GitHub Actions in deinem Unternehmen und unter GitHub Actions für deine Organisation Deaktivieren oder Einschränken.

Überprüfen des Status eines selbst gehosteten Läufers

Ein selbstgehosteter Runner kann entweder in den Repository-, Organisations- oder Enterprise-Kontoeinstellungen auf GitHub gefunden werden. Um einen selbst-gehosteten Läufer zu verwalten, musst Du über die folgenden Berechtigungen verfügen, abhängig davon, wo der selbst-gehostete Läufer hinzugefügt wurde:

  • Benutzer-Repository: Du musst der Repositorybesitzer sein.

  • Organisation: Du musst ein Organisationsbesitzer sein.

  • Organisationsrepository: Du musst du ein Organisationsbesitzer sein oder über Administratorzugriff auf das Repository verfügen.

  • Unternehmenskonto: Du musst ein Unternehmensbesitzer sein.

  1. Navigiere in deiner Organisation oder deinem Repository zur Hauptseite, und klicke auf Settings.

  2. Klicke in der linken Seitenleiste auf Aktionen und dann auf Runner.

  3. Unter „Runner“ kannst du eine Liste registrierter Runner, einschließlich Name, Bezeichnungen und Status des Runners, einsehen.

    Folgende Statuswerte sind möglich:

    • Leerlauf: Der Runner ist mit GitHub Enterprise Cloud verbunden und bereit, Aufträge auszuführen.
    • Aktiv: Der Runner führt derzeit einen Auftrag aus.
    • Offline: Der Runner ist nicht mit GitHub Enterprise Cloud verbunden. Dies könnte daran liegen, dass der Rechner offline ist, die Anwendung für selbst-gehostete Runner nicht auf dem Rechner läuft, oder die Anwendung für selbst-gehostete Runner kann nicht mit GitHub Enterprise Cloud kommunizieren.

Problembehandlung bei der Netzwerkkonnektivität

Überprüfen der Netzwerkkonnektivität für selbstgehostete Runner

Du kannst das config-Skript der selbstgehosteten Runneranwendung mit dem Parameter --check verwenden, um zu überprüfen, ob ein selbstgehosteter Runner auf alle erforderlichen Netzwerkdienste in GitHub zugreifen kann.

Zusätzlich zu --check müssen zwei weitere Argumente für das Skript angegeben werden:

  • --url mit der URL zu deinem bzw. deiner GitHub-Repository, -Organisation oder -Unternehmen. Beispiel: --url https://github.com/octo-org/octo-repo.
  • --pat mit dem Wert eines personal access token (classic), der den Geltungsbereich workflow haben muss, oder einen fine-grained personal access token mit Lese- und Schreibzugriff für Workflows. Beispiel: --pat ghp_abcd1234. Weitere Informationen findest du unter Verwalten deiner persönlichen Zugriffstoken.

Beispiel:

./config.sh --check --url URL --pat ghp_abcd1234

./config.sh --check --url URL --pat ghp_abcd1234

config.cmd --check --url https://github.com/YOUR-ORG/YOUR-REPO --pat GHP_ABCD1234

Das Skript testet die einzelnen Dienste und gibt entweder PASS oder FAIL für jeden Dienst aus. Wenn die Überprüfung für einen Dienst nicht erfolgreich ist, findest du weitere Einzelheiten in der Protokolldatei der Überprüfung. Die Protokolldateien befinden sich im Verzeichnis _diag, in dem du die Runneranwendung installiert hast. Der Pfad der Protokolldateien für die einzelnen Überprüfungen wird zudem in der Konsolenausgabe des Skripts angezeigt.

Wenn die Überprüfung für einen Dienst nicht erfolgreich ist, solltest du zudem überprüfen, ob der für deinen selbstgehosteten Runner verwendete Computer alle Kommunikationsanforderungen erfüllt. Weitere Informationen findest du unter Informationen zu selbstgehosteten Runnern.

Deaktivieren der TLS-Zertifikatüberprüfung

Standardmäßig überprüft die selbstgehostete Runneranwendung das TLS-Zertifikat für GitHub Enterprise Cloud. Wenn Netzwerkprobleme auftreten, sollte die TLS-Zertifikatüberprüfung zu Testzwecken möglicherweise deaktiviert werden.

Zum Deaktivieren der TLS-Zertifizierungsüberprüfung in der selbstgehosteten Runneranwendung legst du die GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY-Umgebungsvariable auf 1 fest, bevor du die selbstgehostete Runneranwendung konfigurierst und ausführst.

export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.sh

export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.sh

[Environment]::SetEnvironmentVariable('GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY', '1')
./config.cmd --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.cmd

Warning

Die Deaktivierung der TLS-Überprüfung wird nicht empfohlen. Der Grund dafür ist, dass mithilfe von TLS der Datenschutz und die Datenintegrität zwischen der selbstgehosteten Runneranwendung und GitHub Enterprise Cloud sichergestellt wird. Es wird empfohlen, das GitHub Enterprise Cloud-Zertifikat im Zertifikatspeicher des Betriebssystems für deinen selbstgehosteten Runner zu installieren. Informationen zur Installation des GitHub Enterprise Cloud-Zertifikats erhältst du beim Hersteller deines Betriebssystems.

Die Logdateien der Anwendung für selbst-gehostete Runner überprüfen

Du kannst den Status der selbstgehosteten Runneranwendung und die zugehörigen Aktivitäten überwachen. Protokolldateien werden im Verzeichnis _diag gespeichert, in dem du die Runneranwendung installiert hast. Bei jedem Start der Anwendung wird ein neues Protokoll generiert. Der Dateiname beginnt mit Runner_, gefolgt von einem UTC-Zeitstempel des Anwendungsstarts.

Warning

Runner-Anwendungsprotokolldateien für kurzlebige Runner müssen für Problembehandlungs- und Diagnosezwecke extern weitergeleitet und beibehalten werden. Weitere Informationen zu selbstgehosteten Runnern finden Sie unter "Automatische Skalierung mit selbstgehosteten Runnern."

Ausführliche Protokolle zur Ausführung von Workflowaufträgen finden Sie im nächsten Abschnitt zu den Dateien vom Typ Worker_.

Logdatei eines Jobs überprüfen

Die selbstgehostete Runneranwendung erstellt eine detaillierte Protokolldatei für jeden Auftrag, den sie verarbeitet. Diese Dateien werden im Verzeichnis _diag gespeichert, in dem Sie die Runner-Anwendung installiert haben. Der Dateiname beginnt mit Worker_.

Den Anwendungs-Dienst für selbst-gehostete Runner mittels journalctl überprüfen

Für Linux-basierte selbstgehostete Runner, die die Anwendung mit einem Dienst ausführen, kannst du zur Überwachung der Echtzeitaktivität journalctl verwenden. Der standardmäßige systembasierte Dienst verwendet die folgende Namenskonvention: actions.runner.<org>-<repo>.<runnerName>.service Wenn dieser Name mehr als 80 Zeichen umfasst, wird er abgeschnitten. Aus diesem Grund sollte anhand der Datei .service nach dem Namen des Diensts gesucht werden. Beispiel:

$ cat ~/actions-runner/.service
actions.runner.octo-org-octo-repo.runner01.service

Wenn dieser Vorgang nicht möglich ist, weil der Dienst an anderer Stelle installiert ist, kannst du den Dienstnamen anhand der Liste der ausgeführten Dienste ermitteln. Auf den meisten Linux-Systemen kannst du z. B. den Befehl systemctl verwenden:

$ systemctl --type=service | grep actions.runner
actions.runner.octo-org-octo-repo.hostname.service loaded active running GitHub Actions Runner (octo-org-octo-repo.hostname)

Mithilfe von journalctl kannst du die Echtzeitaktivität des selbstgehosteten Runners überwachen:

sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f

In dieser Beispielausgabe siehst du den Start von runner01, den Empfang des Auftrags testAction und den resultierenden Status:

Feb 11 14:57:07 runner01 runsvc.sh[962]: Starting Runner listener with startup type: service
Feb 11 14:57:07 runner01 runsvc.sh[962]: Started listener process
Feb 11 14:57:07 runner01 runsvc.sh[962]: Started running service
Feb 11 14:57:16 runner01 runsvc.sh[962]: √ Connected to GitHub
Feb 11 14:57:17 runner01 runsvc.sh[962]: 2020-02-11 14:57:17Z: Listening for Jobs
Feb 11 16:06:54 runner01 runsvc.sh[962]: 2020-02-11 16:06:54Z: Running job: testAction
Feb 11 16:07:10 runner01 runsvc.sh[962]: 2020-02-11 16:07:10Z: Job testAction completed with result: Succeeded

Zum Anzeigen der systemd-Konfiguration kannst du hier nach der Dienstdatei suchen: /etc/systemd/system/actions.runner.<org>-<repo>.<runnerName>.service. Diese Datei darf nicht direkt bearbeitet werden, um den Dienst der selbstgehosteten Runneranwendung anzupassen. Befolge die unter Die Anwendung für selbst-gehostete Runner als Dienst konfigurieren beschriebenen Anweisungen.

Überprüfen des selbstgehosteten Runneranwendungsdiensts mit launchd

Für macOS-basierte selbstgehostete Runner, die die Anwendung als Dienst ausführen, kannst du zur Überwachung der Echtzeitaktivität launchctl verwenden. Der standardmäßige launchd-basierte Dienst verwendet die folgende Namenskonvention: actions.runner.<org>-<repo>.<runnerName> Wenn dieser Name mehr als 80 Zeichen umfasst, wird er abgeschnitten. Aus diesem Grund sollte anhand der Datei .service im Runnerverzeichnis nach dem Namen des Diensts gesucht werden:

% cat ~/actions-runner/.service
/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist

Das Skript svc.sh überprüft mithilfe von launchctl, ob die Anwendung ausgeführt wird. Beispiel:

$ ./svc.sh status
status actions.runner.example.runner01:
/Users/exampleUsername/Library/LaunchAgents/actions.runner.example.runner01.plist
Started:
379 0 actions.runner.example.runner01

Die resultierende Ausgabe enthält die Prozess-ID und den Namen des launchd-Diensts der Anwendung.

Zum Anzeigen der launchd-Konfiguration kannst du hier nach der Dienstdatei suchen: /Users/exampleUsername/Library/LaunchAgents/actions.runner.<repoName>.<runnerName>.service. Diese Datei darf nicht direkt bearbeitet werden, um den Dienst der selbstgehosteten Runneranwendung anzupassen. Befolge die unter Die Anwendung für selbst-gehostete Runner als Dienst konfigurieren beschriebenen Anweisungen.

Den Anwendungs-Dienst für selbst-gehostete Runner mittels PowerShell überprüfen

Für Windows-basierte selbstgehostete Runner, die die Anwendung als Dienst ausführen, kannst du zur Überwachung der Echtzeitaktivität PowerShell verwenden. Der Dienst verwendet die GitHub Actions Runner (<org>-<repo>.<runnerName>)-Namenskonvention. Du kannst den Namen des Diensts auch in der .service-Datei im Runnerverzeichnis ermitteln:

PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.service

Der Status des Runners kann in der Windows-Anwendung Dienste (services.msc) angezeigt werden. Darüber hinaus kannst du auch mit PowerShell überprüfen, ob der Dienst ausgeführt wird:

PS C:\actions-runner> Get-Service "actions.runner.octo-org-octo-repo.runner01.service" | Select-Object Name, Status
Name                                                  Status
----                                                  ------
actions.runner.octo-org-octo-repo.runner01.service    Running

Mithilfe von PowerShell kannst du die aktuelle Aktivität des selbstgehosteten Runners überprüfen. In dieser Beispielausgabe siehst du den Anwendungsstart, den Empfang des Auftrags testAction und den resultierenden Status:

PS C:\actions-runner> Get-EventLog -LogName Application -Source ActionsRunnerService

   Index Time          EntryType   Source                 InstanceID Message
   ----- ----          ---------   ------                 ---------- -------
     136 Mar 17 13:45  Information ActionsRunnerService          100 2020-03-17 13:45:48Z: Job Greeting completed with result: Succeeded
     135 Mar 17 13:45  Information ActionsRunnerService          100 2020-03-17 13:45:34Z: Running job: testAction
     134 Mar 17 13:41  Information ActionsRunnerService          100 2020-03-17 13:41:54Z: Listening for Jobs
     133 Mar 17 13:41  Information ActionsRunnerService          100 û Connected to GitHub
     132 Mar 17 13:41  Information ActionsRunnerService            0 Service started successfully.
     131 Mar 17 13:41  Information ActionsRunnerService          100 Starting Actions Runner listener
     130 Mar 17 13:41  Information ActionsRunnerService          100 Starting Actions Runner Service
     129 Mar 17 13:41  Information ActionsRunnerService          100 create event log trace source for actions-runner service

Den automatischen Aktualisierungsprozesses überwachen

Da der selbstgehostete Runner Aufträge nicht verarbeiten kann, wenn eine bestimmte Version unterschritten wird, solltest du den automatischen Updateprozess regelmäßig überprüfen. Die selbstgehostete Runneranwendung aktualisiert sich automatisch selbst. Dieser Vorgang umfasst jedoch keine Updates des Betriebssystems oder anderer Software. Diese Updates müssen separat verwaltet werden.

Die Updateaktivitäten können in den Runner_-Protokolldateien angezeigt werden. Zum Beispiel:

[Feb 12 12:37:07 INFO SelfUpdater] An update is available.

Weitere Informationen findest du zudem in den SelfUpdate-Protokolldateien im _diag-Verzeichnis, in dem du die Runneranwendung installiert hast.

Fehlerbehebung für Container in selbst-gehosteten Runnern

Überprüfen, ob Docker installiert ist

Wenn für deine Aufträge Container benötigt werden, muss ein Linux-basierter selbstgehosteter Runner verwendet werden, und Docker muss installiert sein. Überprüfe, ob dein selbstgehosteter Runner über eine Docker-Installation verfügt und der Dienst ausgeführt wird.

Du kannst den Dienststatus mithilfe von systemctl überprüfen:

$ sudo systemctl is-active docker.service
active

Wenn Docker nicht installiert ist, werden abhängige Aktionen mit den folgenden Fehlern abgebrochen:

[2020-02-13 16:56:10Z INFO DockerCommandManager] Which: 'docker'
[2020-02-13 16:56:10Z INFO DockerCommandManager] Not found.
[2020-02-13 16:56:10Z ERR  StepsRunner] Caught exception from step: System.IO.FileNotFoundException: File not found: 'docker'

Die Docker Berechtigungen überprüfen

Gehe wie folgt vor, wenn dein Auftrag mit dem folgenden Fehler abgebrochen wird:

dial unix /var/run/docker.sock: connect: permission denied

Überprüfe, ob das Dienstkonto des selbstgehosteten Runners für die Verwendung des Docker-Diensts berechtigt ist. Dieses Konto lässt sich anhand der Konfiguration des selbstgehosteten Runners in systemd ermitteln. Beispiel:

$ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service
User=runner-user

Überprüfen, welche Docker-Engine auf dem Runner installiert ist

Gehe wie folgt vor, wenn dein Build mit dem folgenden Fehler abgebrochen wird:

Error: Input required and not supplied: java-version

Überprüfe, welche Docker-Engine auf deinem selbstgehosteten Runner installiert ist. Um die Eingaben einer Aktion an den Docker-Container zu übergeben, verwendet der Runner Umgebungsvariablen, die Bindestriche in ihren Namen enthalten können. Die Aktion kann die Eingaben möglicherweise nicht abrufen, wenn es sich bei der Docker-Engine nicht um eine binäre ausführbare Datei handelt, sondern um einen Shell-Wrapper oder einen Link, z. B. eine mit snap unter Linux installierte Docker-Engine. Um diesen Fehler zu beheben, konfiguriere deinen selbstgehosteten Runner so, dass er eine andere Docker-Engine verwendet.

Verwende den Befehl which, um zu überprüfen, ob deine Docker-Engine mit snap installiert wurde. Im folgenden Beispiel wurde die Docker-Engine mit snap installiert:

$ which docker
/snap/bin/docker