👋 We've unified all of GitHub's product documentation in one place! Check out the content for REST API, GraphQL API, and Developers. Learn more on the GitHub blog.


Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.

Monitoramento e resolução de problemas dos executores auto-hospedados

Você pode monitorar seus executores auto-hospedados para visualizar sua atividade e diagnosticar problemas comuns.

Neste artigo

Verificar o status de um executor auto-hospedado usando GitHub

A self-hosted runner can be located in either your organization or repository settings on GitHub. To manage a self-hosted runner, you must have the following permissions, depending on where the self-hosted runner was added:

  • User repository: You must be the repository owner.
  • Organization: You must be an organization owner.
  • Organization repository: You must be the organization owner, or have admin access to the repository.
  1. In your organization or repository, navigate to the main page and click Settings.

  2. In the left sidebar, click Actions.

    Actions setting

  3. Em "Executores auto-hospedados", você pode ver uma lista de executores registrados, incluindo o nome, etiqueta e status do executor.

    Lista de executores

    Pode haver os seguintes status:

    • Inativo: O executor está conectado a GitHub e está pronto para executar trabalhos.
    • Ativo: O executor está executando uma tarefa no momento.
    • Off-line: O executor não está conectado a GitHub. Isto pode ser porque a máquina está off-line, o aplicativo do executor auto-hospedado não está funcionando na máquina, ou o aplicativo do executor auto-hospedado não pode comunicar-se com GitHub.

Revisar os arquivos de registro do aplicativo do executor auto-hospedado

You can monitor the status of the self-hosted runner application and its activities. Log files are kept in the _diag directory, and a new one is generated each time the application is started. The filename begins with Runner_, and is followed by a UTC timestamp of when the application was started.

For detailed logs on workflow job executions, see the next section describing the Worker_ files.

Revisar o arquivo de registro de um trabalho

The self-hosted runner application creates a detailed log file for each job that it processes. These files are stored in the _diag directory, and the filename begins with Worker_.

Usar journalctl para verificar o serviço do aplicativo do executor auto-hospedado

For Linux-based self-hosted runners running the application using a service, you can use journalctl to monitor their real-time activity. The default systemd-based service uses the following naming convention: actions.runner.<org>-<repo>.<runnerName>.service. This name is truncated if it exceeds 80 characters, so the preferred way of finding the service's name is by checking the .service file. Por exemplo:

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

You can use journalctl to monitor the real-time activity of the self-hosted runner:

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

In this example output, you can see runner01 start, receive a job named testAction, and then display the resulting status:

Feb 11 14:57:07 runner01 runsvc.sh[962]: Iniciando o ouvinte do executor com o tipo de inicialização: serviço
Feb 11 14:57:07 runner01 runsvc.sh[962]: Processo do ouvinte iniciado
Feb 11 14:57:07 runner01 runsvc.sh[962]: Serviço de execução iniciado
Feb 11 14:57:16 runner01 runsvc.sh[962]: √ Conectado ao GitHub
Feb 11 14:57:17 runner01 runsvc.sh[962]: 2020-02-11 14:57:17Z: Escuta para Jobs
Feb 11 16:06:54 runner01 runsvc.sh[962]: 2020-02-11 16:06:54Z: Trabalho em execução: testAction
Feb 11 16:07:10 runner01 runsvc.sh[962]: 2020-02-11 16:07:10Z: Trabalho testAction concluído com o resultado: Aprovado

To view the systemd configuration, you can locate the service file here: /etc/systemd/system/actions.runner.<org>-<repo>.<runnerName>.service. If you want to customize the self-hosted runner application service, do not directly modify this file. Follow the instructions described in "Configuring the self-hosted runner application as a service."

Usar o launchd para verificar o serviço do aplicativo do executor auto-hospedado

For macOS-based self-hosted runners running the application as a service, you can use launchctl to monitor their real-time activity. The default launchd-based service uses the following naming convention: actions.runner.<org>-<repo>.<runnerName>. This name is truncated if it exceeds 80 characters, so the preferred way of finding the service's name is by checking the .service file in the runner directory:

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

The svc.sh script uses launchctl to check whether the application is running. Por exemplo:

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

The resulting output includes the process ID and the name of the application’s launchd service.

To view the launchd configuration, you can locate the service file here: /Users/exampleUsername/Library/LaunchAgents/actions.runner.<repoName>.<runnerName>.service. If you want to customize the self-hosted runner application service, do not directly modify this file. Follow the instructions described in "Configuring the self-hosted runner application as a service."

Usar PowerShell para verificar o serviço do aplicativo do executor auto-hospedado

For Windows-based self-hosted runners running the application as a service, you can use PowerShell to monitor their real-time activity. The service uses the naming convention GitHub Actions Runner (<org>-<repo>.<runnerName>). You can also find the service's name by checking the .service file in the runner directory:

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

You can view the status of the runner in the Windows Services application (services.msc). You can also use PowerShell to check whether the service is running:

PS C:\actions-runner> Get-Service "actions.runner.octo-org-octo-repo.runner01.service" | Select-Object Name, Status
Nome                                                  Status
----                                                  ------
actions.runner.octo-org-octo-repo.runner01.service    Em execução

You can use PowerShell to check the recent activity of the self-hosted runner. In this example output, you can see the application start, receive a job named testAction, and then display the resulting status:

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

   Índice temporal          Tipo de entrada   Fonte                 ID da instância Mensagem
   ----- ----          ---------   ------                 ---------- -------
     136 Mar 17 13:45  Informação ActionsRunnerService          100 2020-03-17 13:45:48Z: Job Saudação concluída com o resultado: Aprovado
     135 Mar 17 13:45  Informação ActionsRunnerService          100 2020-03-17 13:45:34Z: Trabalho em execução: testAction
     134 Mar 17 13:41  Informação ActionsRunnerService          100 2020-03-17 13:41:54Z: Escuta para trabalhos
     133 Mar 17 13:41  Informação ActionsRunnerService          100 û conectado ao GitHub
     132 Mar 17 13:41  Informação ActionsRunnerService            0 Service iniciado com sucesso.
     131 Mar 17 13:41  Informação ActionsRunnerService          100 Iniciando ações do ouvinte do executor
     130 Mar 17 13:41  Informação ActionsRunnerService          100 Iniciando ações do serviço do executor
     129 Mar 17 13:41  Informação ActionsRunnerService          100 criar fonte de rastreamento de registro de evento para o serviço actions-runner

Monitorar o processo de atualização automática

Recomendamos que você verifique regularmente o processo de atualização automática, uma vez que o executor auto-hospedado não será capaz de processar os trabalhos se estiver abaixo de um determinado limite de versão. O aplicativo do executor auto-hospedado atualiza-se, mas mas observe que este processo não inclui atualizações do sistema operacional ou de outro software. Será necessário que você gerencie essas atualizações separadamente.

You can view the update activities in the Runner_ log files. Por exemplo:

[Fevb 12 12:37:07 INFO SelfUpdater] Uma atualização está disponível.

In addition, you can find more information in the SelfUpdate log files located in the _diag directory.

Resolução de problemas de contêineres em executores auto-hospedados

Verificar se o Docker está instalado

If your jobs require containers, then the self-hosted runner must be Linux-based and needs to have Docker installed. Check that your self-hosted runner has Docker installed and that the service is running.

You can use systemctl to check the service status:

$ sudo systemctl is-active docker.service
ativo

If Docker is not installed, then dependent actions will fail with the following errors:

[2020-02-13 16:56:10Z INFO DockerCommandManager] Which: 'docker'
[2020-02-13 16:56:10Z INFO DockerCommandManager] Não encontrado.
[2020-02-13 16:56:10Z ERR  StepsRunner] Capturou exceção da etapa: System.IO.FileNotFoundException: Arquivo não encontrado: 'docker'

Verificar as permissões do Docker

If your job fails with the following error:

discar unix /var/run/docker.sock: conexão: permissão negada

Check that the self-hosted runner's service account has permission to use the Docker service. You can identify this account by checking the configuration of the self-hosted runner in systemd. Por exemplo:

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

Pergunte a uma pessoa

Não consegue encontrar o que procura?

Entrar em contato