{"meta":{"title":"Überwachen und Beheben von Problemen mit selbstgehosteten Runnern","intro":"Du kannst deine selbst gehosteten Runner überwachen, um ihre Aktivität einzusehen und gängige Probleme zu diagnostizieren.","product":"GitHub Actions","breadcrumbs":[{"href":"/de/actions","title":"GitHub Actions"},{"href":"/de/actions/how-tos","title":"Anleitungen"},{"href":"/de/actions/how-tos/manage-runners","title":"Verwalten von Runnern"},{"href":"/de/actions/how-tos/manage-runners/self-hosted-runners","title":"Selbstgehosteten Runnern"},{"href":"/de/actions/how-tos/manage-runners/self-hosted-runners/monitor-and-troubleshoot","title":"Überwachen und Fehlerbehebung"}],"documentType":"article"},"body":"# Überwachen und Beheben von Problemen mit selbstgehosteten Runnern\n\nDu kannst deine selbst gehosteten Runner überwachen, um ihre Aktivität einzusehen und gängige Probleme zu diagnostizieren.\n\n## Überprüfen der Zugriffsebenen\n\nMöglicherweise kannst du keinen selbstgehosteten Runner für ein Repository im Besitz deiner Organisation erstellen.\n\nOrganisations-besitzer können auswählen, welche Repositories selbstgehostete Runner auf Repository-Ebene erstellen dürfen.\n\nWeitere Informationen finden Sie unter [Deaktivieren oder Einschränken von GitHub Actions für Ihre Organisation](/de/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#limiting-the-use-of-self-hosted-runners).\n\n## Überprüfen des Status eines selbst gehosteten Läufers\n\nEin 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:\n\n* **Benutzer-Repository**: Du musst der Repositorybesitzer sein.\n* **Organisation**: Du musst ein Organisationsbesitzer sein.\n* **Organisationsrepository**: Du musst du ein Organisationsbesitzer sein oder über Administratorzugriff auf das Repository verfügen.\n\n1. Navigiere in deiner Organisation oder deinem Repository zur Hauptseite, und klicke dann auf ** Settings**.\n\n2. Klicke in der linken Randleiste auf ** Actions** und dann auf **Runners**.\n\n3. Unter „Runner“ kannst du eine Liste registrierter Runner, einschließlich Name, Bezeichnungen und Status des Runners, einsehen.\n\n Folgende Statuswerte sind möglich:\n\n * **Leerlauf:** Der Runner ist mit GitHub verbunden und ist bereit, Jobs auszuführen.\n * **Aktiv**: Der Runner führt derzeit einen Auftrag aus.\n * **Offline:** Der Runner ist nicht mit GitHub verbunden. Dies kann sein, weil der Computer offline ist, die selbst gehostete Runner-Anwendung nicht auf dem Computer ausgeführt wird oder die selbst gehostete Läuferanwendung nicht mit GitHubkommunizieren kann.\n\n## Problembehandlung bei der Netzwerkkonnektivität\n\n### Überprüfen der Netzwerkkonnektivität für selbstgehostete Runner\n\nSie können das Skript der selbst gehosteten Runner-Anwendung `config` mit dem `--check` Parameter verwenden, um zu überprüfen, ob ein selbst gehosteter Läufer auf alle erforderlichen Netzwerkdienste GitHubzugreifen kann.\n\nZusätzlich zu `--check` müssen zwei weitere Argumente für das Skript angegeben werden:\n\n* `--url` mit der URL zu Ihrem GitHub Repository, Ihrer Organisation oder Ihrem Unternehmen. Beispiel: `--url https://github.com/octo-org/octo-repo`.\n* `--pat` mit dem Wert von einem personal access token (classic), das den Umfang `workflow` haben muss, oder von einem fine-grained personal access token mit Lese- und Schreibzugriff auf Workflows. Beispiel: `--pat ghp_abcd1234`. Weitere Informationen finden Sie unter [Verwalten deiner persönlichen Zugriffstoken](/de/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n\nZum Beispiel:\n\n
\n\nDas Skript testet die einzelnen Dienste und gibt entweder `PASS` oder `FAIL` für jeden Dienst aus. Wenn du fehlgeschlagene Prüfungen hast, kannst du im Prüfprotokoll weitere Details zum Problem sehen. 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.\n\nWenn 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 finden Sie unter [Referenzen zu selbstgehosteten Runnern](/de/actions/reference/runners/self-hosted-runners).\n\n### Deaktivieren der TLS-Zertifikatüberprüfung\n\nStandardmäßig überprüft die selbst gehostete Runner-Anwendung das TLS-Zertifikat für GitHub. Wenn Netzwerkprobleme auftreten, sollte die TLS-Zertifikatüberprüfung zu Testzwecken möglicherweise deaktiviert werden.\n\nZum 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.\n\n
\n\n> \\[!WARNING]\n> Die Deaktivierung der TLS-Überprüfung wird nicht empfohlen, da TLS Vertraulichkeit und Datenintegrität zwischen der selbstgehosteten Runner-Anwendung und GitHub bietet. Wir empfehlen, das GitHub-Zertifikat im Zertifikatspeicher des Betriebssystems für Ihren selbstgehosteten Runner zu installieren. Eine Anleitung zum Installieren des GitHub Zertifikats finden Sie bei Ihrem Betriebssystemanbieter.\n\n> \\[!NOTE]\n> Für GitHub-gehostete große Runner, die Azure Private Networking verwenden, siehe die Anforderungen für die TLS-Interception in [Konfiguration privater Netzwerke für GitHub-gehostete Runner in Ihrer Organisation](/de/organizations/managing-organization-settings/configuring-private-networking-for-github-hosted-runners-in-your-organization#prerequisites).\n\n## Die Logdateien der Anwendung für selbst-gehostete Runner überprüfen\n\nDu 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.\n\n> \\[!WARNING]\n> Protokolldateien der Runner-Anwendung für flüchtige Runner müssen für Problembehandlungs- und Diagnosezwecke extern weitergeleitet und gespeichert werden. Weitere Informationen zu ephemeren Runnern und autoskalierenden, selbstgehosteten Runnern findest du unter [Referenzen zu selbstgehosteten Runnern](/de/actions/reference/runners/self-hosted-runners#ephemeral-runners-for-autoscaling).\n\nAusführliche Protokolle zur Ausführung von Workflowaufträgen finden Sie im nächsten Abschnitt zu den Dateien vom Typ `Worker_`.\n\n## Logdatei eines Jobs überprüfen\n\nDie 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_`.\n\n
\n\n## Den Anwendungs-Dienst für selbst-gehostete Runner mittels journalctl überprüfen\n\nFü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.-..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. Zum Beispiel:\n\n```shell\n$ cat ~/actions-runner/.service\nactions.runner.octo-org-octo-repo.runner01.service\n```\n\nWenn 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:\n\n```shell\n$ systemctl --type=service | grep actions.runner\nactions.runner.octo-org-octo-repo.hostname.service loaded active running GitHub Actions Runner (octo-org-octo-repo.hostname)\n```\n\nMithilfe von `journalctl` kannst du die Echtzeitaktivität des selbstgehosteten Runners überwachen:\n\n```shell\nsudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f\n```\n\nIn dieser Beispielausgabe siehst du den Start von `runner01`, den Empfang des Auftrags `testAction` und den resultierenden Status:\n\n```shell\nFeb 11 14:57:07 runner01 runsvc.sh[962]: Starting Runner listener with startup type: service\nFeb 11 14:57:07 runner01 runsvc.sh[962]: Started listener process\nFeb 11 14:57:07 runner01 runsvc.sh[962]: Started running service\nFeb 11 14:57:16 runner01 runsvc.sh[962]: √ Connected to GitHub\nFeb 11 14:57:17 runner01 runsvc.sh[962]: 2020-02-11 14:57:17Z: Listening for Jobs\nFeb 11 16:06:54 runner01 runsvc.sh[962]: 2020-02-11 16:06:54Z: Running job: testAction\nFeb 11 16:07:10 runner01 runsvc.sh[962]: 2020-02-11 16:07:10Z: Job testAction completed with result: Succeeded\n```\n\nZum Anzeigen der `systemd`-Konfiguration kannst du hier nach der Dienstdatei suchen: `/etc/systemd/system/actions.runner.-..service`.\nDiese Datei darf nicht direkt bearbeitet werden, um den Dienst der selbstgehosteten Runneranwendung anzupassen. Befolge die unter [Selbstgehostete Runner-Anwendung als Dienst konfigurieren](/de/actions/how-tos/manage-runners/self-hosted-runners/configure-the-application#customizing-the-self-hosted-runner-service) beschriebenen Anweisungen.\n\n
\n\n
\n\n## Überprüfen des selbstgehosteten Runner-Anwendungsdiensts mit `launchd`\n\nFü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.-.` 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:\n\n```shell\n% cat ~/actions-runner/.service\n/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist\n```\n\nDas Skript `svc.sh` überprüft mithilfe von `launchctl`, ob die Anwendung ausgeführt wird. Zum Beispiel:\n\n```shell\n$ ./svc.sh status\nstatus actions.runner.example.runner01:\n/Users/exampleUsername/Library/LaunchAgents/actions.runner.example.runner01.plist\nStarted:\n379 0 actions.runner.example.runner01\n```\n\nDie resultierende Ausgabe enthält die Prozess-ID und den Namen des `launchd`-Diensts der Anwendung.\n\nZum Anzeigen der `launchd`-Konfiguration kannst du hier nach der Dienstdatei suchen: `/Users/exampleUsername/Library/LaunchAgents/actions.runner...service`.\nDiese Datei darf nicht direkt bearbeitet werden, um den Dienst der selbstgehosteten Runneranwendung anzupassen. Befolge die unter [Selbstgehostete Runner-Anwendung als Dienst konfigurieren](/de/actions/how-tos/manage-runners/self-hosted-runners/configure-the-application#customizing-the-self-hosted-runner-service) beschriebenen Anweisungen.\n\n
\n\n
\n\n## Den Anwendungs-Dienst für selbst-gehostete Runner mittels PowerShell überprüfen\n\nFü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 (-.)`-Namenskonvention. Du kannst den Namen des Diensts auch in der *.service*-Datei im Runnerverzeichnis ermitteln:\n\n```powershell\nPS C:\\actions-runner> Get-Content .service\nactions.runner.octo-org-octo-repo.runner01.service\n```\n\nDer 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:\n\n```powershell\nPS C:\\actions-runner> Get-Service \"actions.runner.octo-org-octo-repo.runner01.service\" | Select-Object Name, Status\nName Status\n---- ------\nactions.runner.octo-org-octo-repo.runner01.service Running\n```\n\nMithilfe 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:\n\n```powershell\nPS C:\\actions-runner> Get-EventLog -LogName Application -Source ActionsRunnerService\n\n Index Time EntryType Source InstanceID Message\n ----- ---- --------- ------ ---------- -------\n 136 Mar 17 13:45 Information ActionsRunnerService 100 2020-03-17 13:45:48Z: Job Greeting completed with result: Succeeded\n 135 Mar 17 13:45 Information ActionsRunnerService 100 2020-03-17 13:45:34Z: Running job: testAction\n 134 Mar 17 13:41 Information ActionsRunnerService 100 2020-03-17 13:41:54Z: Listening for Jobs\n 133 Mar 17 13:41 Information ActionsRunnerService 100 û Connected to GitHub\n 132 Mar 17 13:41 Information ActionsRunnerService 0 Service started successfully.\n 131 Mar 17 13:41 Information ActionsRunnerService 100 Starting Actions Runner listener\n 130 Mar 17 13:41 Information ActionsRunnerService 100 Starting Actions Runner Service\n 129 Mar 17 13:41 Information ActionsRunnerService 100 create event log trace source for actions-runner service\n```\n\n
\n\n## Den automatischen Aktualisierungsprozess überwachen\n\nWir empfehlen, den automatischen Updateprozess regelmäßig zu überprüfen, da der selbstgehostete Runner Aufträge nicht verarbeiten kann, wenn eine bestimmte Versionsschwelle unterschritten wird. 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.\n\nDie Updateaktivitäten können in den `Runner_`-Protokolldateien angezeigt werden. Zum Beispiel:\n\n```shell\n[Feb 12 12:37:07 INFO SelfUpdater] An update is available.\n```\n\nWeitere Informationen findest du zudem in den *SelfUpdate*-Protokolldateien im `_diag`-Verzeichnis, in dem du die Runneranwendung installiert hast.\n\n
\n\n## Fehlerbehebung für Container in selbst-gehosteten Runnern\n\n### Überprüfen, ob Docker installiert ist\n\nWenn 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.\n\nDu kannst den Dienststatus mithilfe von `systemctl` überprüfen:\n\n```shell\n$ sudo systemctl is-active docker.service\nactive\n```\n\nWenn Docker nicht installiert ist, schlagen abhängige Prozesse mit den folgenden Fehlern fehl:\n\n```shell\n[2020-02-13 16:56:10Z INFO DockerCommandManager] Which: 'docker'\n[2020-02-13 16:56:10Z INFO DockerCommandManager] Not found.\n[2020-02-13 16:56:10Z ERR StepsRunner] Caught exception from step: System.IO.FileNotFoundException: File not found: 'docker'\n```\n\n### Die Docker Berechtigungen überprüfen\n\nGehe wie folgt vor, wenn dein Auftrag mit dem folgenden Fehler abgebrochen wird:\n\n```shell\ndial unix /var/run/docker.sock: connect: permission denied\n```\n\nÜ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. Zum Beispiel:\n\n```shell\n$ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service\nUser=runner-user\n```\n\n
\n\n### Überprüfen, welche Docker-Engine auf dem Runner installiert ist\n\nGehe wie folgt vor, wenn dein Build mit dem folgenden Fehler abgebrochen wird:\n\n```shell\nError: Input required and not supplied: java-version\n```\n\nÜ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.\n\nVerwende den Befehl `snap`, um zu überprüfen, ob deine Docker-Engine mit `which` installiert wurde. Im folgenden Beispiel wurde die Docker-Engine mit `snap` installiert:\n\n```shell\n$ which docker\n/snap/bin/docker\n```"}