监视和故障排除自托管运行程序

您可以监视自托管运行程序以查看其活动并诊断常见问题。

平台导航

本文内容

使用存储库级自托管运行器

你可能无法为组织拥有的存储库创建自托管运行器。

组织所有者可以选择允许哪些存储库创建存储库级自托管运行器。

有关更多信息，请参阅“禁用或限制组织的 GitHub Actions”。

检查自托管运行器状态

自托管运行器可以位于 GitHub 上的存储库、组织或企业帐户设置中。要管理自托管运行器，你必须具有以下权限，具体取决于自托管运行器添加的位置

  • 用户存储库：你必须是存储库所有者。
  • 组织：你必须是组织所有者。
  • 组织存储库：你必须是组织所有者，或具有存储库的管理员访问权限。

  1. 在你的组织或存储库中，导航到主页并单击 设置.

  2. 在左侧边栏中，单击 操作，然后单击运行器。

  3. 在“运行器”下，你可以查看已注册运行器的列表，包括运行器的名称、标签和状态。

    状态可以是以下之一

    • 空闲：运行器已连接到 GitHub，并且已准备好执行作业。
    • 活动：运行器当前正在执行作业。
    • 脱机：运行器未连接到 GitHub。这可能是因为机器处于脱机状态，自托管运行器应用程序未在机器上运行，或自托管运行器应用程序无法与 GitHub 通信。

故障排除网络连接

检查自托管运行器网络连接

你可以使用自托管运行器应用程序的 config 脚本和 --check 参数来检查自托管运行器是否可以访问 GitHub.com 上的所有必需网络服务。

除了 --check，你还必须向脚本提供两个参数

  • --url，其中包含指向你的 GitHub 存储库、组织或企业的 URL。例如，--url https://github.com/octo-org/octo-repo。
  • --pat，其中包含个人访问令牌（经典）的值，该令牌必须具有 workflow 范围，或具有工作流读写访问权限的细粒度个人访问令牌。例如，--pat ghp_abcd1234。有关更多信息，请参阅“管理你的个人访问令牌”。

例如

./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

该脚本测试每项服务，并针对每项服务输出 PASS 或 FAIL。如果你有任何失败的检查，你可以在检查的日志文件中看到有关问题的更多详细信息。日志文件位于你安装运行器应用程序的 _diag 目录中，并且每个检查的日志文件路径显示在脚本的控制台输出中。

如果你有任何失败的检查，你还应该验证你的自托管运行器机器是否满足所有通信要求。有关更多信息，请参阅“关于自托管运行器”。

禁用 TLS 证书验证

默认情况下，自托管运行程序应用程序会验证 GitHub 的 TLS 证书。如果您遇到网络问题，您可能希望禁用 TLS 证书验证以进行测试。

要在自托管运行程序应用程序中禁用 TLS 证书验证，请在配置和运行自托管运行程序应用程序之前，将 GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY 环境变量设置为 1。

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

警告

不建议禁用 TLS 验证，因为 TLS 在自托管运行程序应用程序和 GitHub 之间提供隐私和数据完整性。我们建议您在自托管运行程序的操作系统证书存储中安装 GitHub 证书。有关如何安装 GitHub 证书的指南，请咨询您的操作系统供应商。

查看自托管运行程序应用程序日志文件

您可以监视自托管运行程序应用程序的状态及其活动。日志文件保存在您安装运行程序应用程序的 _diag 目录中，并且每次启动应用程序时都会生成一个新日志。文件名以 Runner_ 开头，后面是应用程序启动时的 UTC 时间戳。

警告

临时运行程序的运行程序应用程序日志文件必须转发并外部保留以用于故障排除和诊断目的。有关临时运行程序和自动缩放自托管运行程序的更多信息，请参阅“使用自托管运行程序进行自动缩放”。

有关工作流作业执行的详细日志，请参阅下一部分，其中介绍了 Worker_ 文件。

查看作业的日志文件

自托管运行程序应用程序为其处理的每个作业创建一个详细的日志文件。这些文件存储在您安装运行程序应用程序的 _diag 目录中，并且文件名以 Worker_ 开头。

使用 journalctl 检查自托管运行程序应用程序服务

对于使用服务运行应用程序的基于 Linux 的自托管运行程序，您可以使用 journalctl 监视其实时活动。默认基于 systemd 的服务使用以下命名约定：actions.runner.<org>-<repo>.<runnerName>.service。如果此名称超过 80 个字符，则此名称将被截断，因此查找服务名称的首选方式是检查 .service 文件。例如

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

如果由于服务在其他位置安装而导致此操作失败，则可以在正在运行的服务列表中找到服务名称。例如，在大多数 Linux 系统上，可以使用 systemctl 命令

$ 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)

可以使用 journalctl 监控自托管运行程序的实时活动

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

在此示例输出中，可以看到 runner01 启动、接收名为 testAction 的作业，然后显示结果状态

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

要查看 systemd 配置，可以在此处找到服务文件：/etc/systemd/system/actions.runner.<org>-<repo>.<runnerName>.service。如果要自定义自托管运行程序应用程序服务，请不要直接修改此文件。按照“将自托管运行程序应用程序配置为服务”中描述的说明进行操作。

使用 launchd 检查自托管运行程序应用程序服务

对于将应用程序作为服务运行的基于 macOS 的自托管运行程序，可以使用 launchctl 监控其实时活动。基于 launchd 的默认服务使用以下命名约定：actions.runner.<org>-<repo>.<runnerName>。如果此名称超过 80 个字符，则会将其截断，因此查找服务名称的首选方式是检查运行程序目录中的 .service 文件

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

svc.sh 脚本使用 launchctl 检查应用程序是否正在运行。例如

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

结果输出包括进程 ID 和应用程序的 launchd 服务的名称。

要查看 launchd 配置，可以在此处找到服务文件：/Users/exampleUsername/Library/LaunchAgents/actions.runner.<repoName>.<runnerName>.service。如果要自定义自托管运行程序应用程序服务，请不要直接修改此文件。按照“将自托管运行程序应用程序配置为服务”中描述的说明进行操作。

使用 PowerShell 检查自托管运行程序应用程序服务

对于将应用程序作为服务运行的基于 Windows 的自托管运行程序，可以使用 PowerShell 监控其实时活动。该服务使用命名约定 GitHub Actions Runner (<org>-<repo>.<runnerName>)。您还可以通过检查运行程序目录中的 .service 文件来查找服务名称

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

您可以在 Windows 服务 应用程序 (services.msc) 中查看运行程序的状态。您还可以使用 PowerShell 检查服务是否正在运行

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

您可以使用 PowerShell 来检查自托管 Runner 的近期活动。在此示例输出中，您可以看到应用程序启动、接收名为 testAction 的作业，然后显示结果状态

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

监视自动更新进程

我们建议您定期检查自动更新进程，因为如果自托管 Runner 低于某个版本阈值，它将无法处理作业。自托管 Runner 应用程序会自动更新自身，但请注意此进程不包括对操作系统或其他软件的任何更新；您需要单独管理这些更新。

您可以在 Runner_ 日志文件中查看更新活动。例如

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

此外，您还可以在安装 Runner 应用程序的 _diag 目录中找到 SelfUpdate 日志文件中的更多信息。

对自托管 Runner 中的容器进行故障排除

检查是否已安装 Docker

如果您的作业需要容器，则自托管 Runner 必须基于 Linux，并且需要安装 Docker。检查您的自托管 Runner 是否已安装 Docker，并且该服务正在运行。

您可以使用 systemctl 检查服务状态

$ sudo systemctl is-active docker.service
active

如果未安装 Docker，则依赖操作将失败，并出现以下错误

[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'

检查 Docker 权限

如果您的作业失败，并出现以下错误

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

检查自托管 Runner 的服务帐户是否有权使用 Docker 服务。您可以通过检查 systemd 中自托管 Runner 的配置来识别此帐户。例如

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

检查在 Runner 上安装了哪个 Docker 引擎

如果您的构建失败，并出现以下错误

Error: Input required and not supplied: java-version

检查在您的自托管 Runner 上安装了哪个 Docker 引擎。为了将操作的输入传递到 Docker 容器中，Runner 使用环境变量，这些变量的名称中可能包含破折号。如果 Docker 引擎不是二进制可执行文件，而是 shell 包装器或链接（例如，使用 snap 在 Linux 上安装的 Docker 引擎），则该操作可能无法获取输入。要解决此错误，请将您的自托管 Runner 配置为使用不同的 Docker 引擎。

要检查您的 Docker 引擎是否使用 snap 安装，请使用 which 命令。在以下示例中，Docker 引擎使用 snap 安装

$ which docker
/snap/bin/docker