{"meta":{"title":"자체 호스트형 실행기 모니터링 및 문제 해결","intro":"셀프 호스팅 러너를 모니터링하여 해당 활동을 보고 일반적인 문제를 진단할 수 있습니다.","product":"GitHub Actions","breadcrumbs":[{"href":"/ko/actions","title":"GitHub Actions"},{"href":"/ko/actions/how-tos","title":"사용법"},{"href":"/ko/actions/how-tos/manage-runners","title":"실행기 관리"},{"href":"/ko/actions/how-tos/manage-runners/self-hosted-runners","title":"자체 호스팅 실행기"},{"href":"/ko/actions/how-tos/manage-runners/self-hosted-runners/monitor-and-troubleshoot","title":"모니터링 및 문제 해결"}],"documentType":"article"},"body":"# 자체 호스트형 실행기 모니터링 및 문제 해결\n\n셀프 호스팅 러너를 모니터링하여 해당 활동을 보고 일반적인 문제를 진단할 수 있습니다.\n\n\n## Checking access levels\n\nYou may not be able to create a self-hosted runner for an organization-owned repository.\n\nOrganization owners can choose which repositories are allowed to create repository-level self-hosted runners.\n\nFor more information, see [Disabling or limiting GitHub Actions for your organization](/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#limiting-the-use-of-self-hosted-runners).\n\n## Checking the status of a self-hosted runner\n\nA self-hosted runner can be located in either your repository, organization, or enterprise account settings on GitHub. To manage a self-hosted runner, you must have the following permissions, depending on where the self-hosted runner was added:\n\n* **User repository:** You must be the repository owner.\n* **Organization:** You must be an organization owner.\n* **Organization repository:** You must be an organization owner, or have admin access to the repository.\n\n1. In your organization or repository, navigate to the main page and click ** Settings**.\n\n2. In the left sidebar, click ** Actions**, then click **Runners**.\n\n3. Under \"Runners\", you can view a list of registered runners, including the runner's name, labels, and status.\n\n The status can be one of the following:\n\n * **Idle:** The runner is connected to GitHub and is ready to execute jobs.\n * **Active:** The runner is currently executing a job.\n * **Offline:** The runner is not connected to GitHub. This could be because the machine is offline, the self-hosted runner application is not running on the machine, or the self-hosted runner application cannot communicate with GitHub.\n\n## Troubleshooting network connectivity\n\n### Checking self-hosted runner network connectivity\n\nYou can use the self-hosted runner application's `config` script with the `--check` parameter to check that a self-hosted runner can access all required network services on GitHub.\n\nIn addition to `--check`, you must provide two arguments to the script:\n\n* `--url` with the URL to your GitHub repository, organization, or enterprise. For example, `--url https://github.com/octo-org/octo-repo`.\n* `--pat` with the value of a personal access token (classic), which must have the `workflow` scope, or a fine-grained personal access token with workflows read and write access. For example, `--pat ghp_abcd1234`. For more information, see [Managing your personal access tokens](/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n\nFor example:\n\n
\n\nThe script tests each service, and outputs either a `PASS` or `FAIL` for each one. If you have any failing checks, you can see more details on the problem in the log file for the check. The log files are located in the `_diag` directory where you installed the runner application, and the path of the log file for each check is shown in the console output of the script.\n\nIf you have any failing checks, you should also verify that your self-hosted runner machine meets all the communication requirements. For more information, see [Self-hosted runners reference](/en/actions/reference/runners/self-hosted-runners).\n\n### Disabling TLS certificate verification\n\nBy default, the self-hosted runner application verifies the TLS certificate for GitHub. If you encounter network problems, you may wish to disable TLS certificate verification for testing purposes.\n\nTo disable TLS certification verification in the self-hosted runner application, set the `GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY` environment variable to `1` before configuring and running the self-hosted runner application.\n\n
\n\n> \\[!WARNING]\n> Disabling TLS verification is not recommended since TLS provides privacy and data integrity between the self-hosted runner application and GitHub. We recommend that you install the GitHub certificate in the operating system certificate store for your self-hosted runner. For guidance on how to install the GitHub certificate, check with your operating system vendor.\n\n> \\[!NOTE]\n> For GitHub-hosted larger runners using Azure private networking, see the TLS interception requirements in [Configuring private networking for GitHub-hosted runners in your organization](/en/organizations/managing-organization-settings/configuring-private-networking-for-github-hosted-runners-in-your-organization#prerequisites).\n\n## Reviewing the self-hosted runner application log files\n\nYou can monitor the status of the self-hosted runner application and its activities. Log files are kept in the `_diag` directory where you installed the runner application, and a new log 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.\n\n> \\[!WARNING]\n> Runner application log files for ephemeral runners must be forwarded and preserved externally for troubleshooting and diagnostic purposes. For more information about ephemeral runners and autoscaling self-hosted runners, see [Self-hosted runners reference](/en/actions/reference/runners/self-hosted-runners#ephemeral-runners-for-autoscaling).\n\nFor detailed logs on workflow job executions, see the next section describing the `Worker_` files.\n\n## Reviewing a job's log file\n\nThe self-hosted runner application creates a detailed log file for each job that it processes. These files are stored in the `_diag` directory where you installed the runner application, and the filename begins with `Worker_`.\n\n
\n\n## Using journalctl to check the self-hosted runner application service\n\nFor 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.-..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. For example:\n\n```shell\n$ cat ~/actions-runner/.service\nactions.runner.octo-org-octo-repo.runner01.service\n```\n\nIf this fails due to the service being installed elsewhere, you can find the service name in the list of running services. For example, on most Linux systems you can use the `systemctl` command:\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\nYou can use `journalctl` to monitor the real-time activity of the self-hosted runner:\n\n```shell\nsudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f\n```\n\nIn this example output, you can see `runner01` start, receive a job named `testAction`, and then display the resulting 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\nTo view the `systemd` configuration, you can locate the service file here: `/etc/systemd/system/actions.runner.-..service`.\nIf 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](/en/actions/how-tos/manage-runners/self-hosted-runners/configure-the-application#customizing-the-self-hosted-runner-service).\n\n
\n\n
\n\n## Using `launchd` to check the self-hosted runner application service\n\nFor 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.-.`. 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:\n\n```shell\n% cat ~/actions-runner/.service\n/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist\n```\n\nThe `svc.sh` script uses `launchctl` to check whether the application is running. For example:\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\nThe resulting output includes the process ID and the name of the application’s `launchd` service.\n\nTo view the `launchd` configuration, you can locate the service file here: `/Users/exampleUsername/Library/LaunchAgents/actions.runner...service`.\nIf 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](/en/actions/how-tos/manage-runners/self-hosted-runners/configure-the-application#customizing-the-self-hosted-runner-service).\n\n
\n\n
\n\n## Using PowerShell to check the self-hosted runner application service\n\nFor 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 (-.)`. You can also find the service's name by checking the *.service* file in the runner directory:\n\n```powershell\nPS C:\\actions-runner> Get-Content .service\nactions.runner.octo-org-octo-repo.runner01.service\n```\n\nYou 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:\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\nYou 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:\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## Monitoring the automatic update process\n\nWe recommend that you regularly check the automatic update process, as the self-hosted runner will not be able to process jobs if it falls below a certain version threshold. The self-hosted runner application automatically updates itself, but note that this process does not include any updates to the operating system or other software; you will need to separately manage these updates.\n\nYou can view the update activities in the `Runner_` log files. For example:\n\n```shell\n[Feb 12 12:37:07 INFO SelfUpdater] An update is available.\n```\n\nIn addition, you can find more information in the *SelfUpdate* log files located in the `_diag` directory where you installed the runner application.\n\n
\n\n## Troubleshooting containers in self-hosted runners\n\n### Checking that Docker is installed\n\nIf 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.\n\nYou can use `systemctl` to check the service status:\n\n```shell\n$ sudo systemctl is-active docker.service\nactive\n```\n\nIf Docker is not installed, then dependent actions will fail with the following errors:\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### Checking the Docker permissions\n\nIf your job fails with the following error:\n\n```shell\ndial unix /var/run/docker.sock: connect: permission denied\n```\n\nCheck 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`. For example:\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### Checking which Docker engine is installed on the runner\n\nIf your build fails with the following error:\n\n```shell\nError: Input required and not supplied: java-version\n```\n\nCheck which Docker engine is installed on your self-hosted runner. To pass the inputs of an action into the Docker container, the runner uses environment variables that might contain dashes as part of their names. The action may not be able to get the inputs if the Docker engine is not a binary executable, but is instead a shell wrapper or a link (for example, a Docker engine installed on Linux using `snap`). To address this error, configure your self-hosted runner to use a different Docker engine.\n\nTo check if your Docker engine was installed using `snap`, use the `which` command. In the following example, the Docker engine was installed using `snap`:\n\n```shell\n$ which docker\n/snap/bin/docker\n```"}