> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Demo Github Actions Self Hosted Runner Diagnostics > Diagnosing canceled GitHub Actions jobs on self-hosted runners by inspecting runner processes, _work and _diag directories, logs, and enabling step and runner debug logging This guide shows how to diagnose canceled GitHub Actions jobs that run on self-hosted runners. We'll: * Create a simple workflow that simulates a long-running telemetry stream. * Run it on a self-hosted runner and cancel it from the GitHub Actions UI. * Inspect the runner process, `_work` and `_diag` directories to determine why the job was canceled. Keywords: GitHub Actions self-hosted runner diagnostics, canceled job, `_diag` logs, `ACTIONS_RUNNER_DEBUG`, `ACTIONS_STEP_DEBUG`. ## 1. Create the workflow Create a new workflow file (for example, `.github/workflows/rocket-launch.yml`) with this content. It triggers on pushes and manual workflow\_dispatch events, runs on a self-hosted runner, and includes a 10-minute timeout. The single step prints telemetry every 5 seconds for 60 seconds. ```yaml theme={null} name: "πŸš€ Rocket Launch Telemetry Demo" on: push: {} workflow_dispatch: {} jobs: telemetry-check: name: Telemetry Stream & API Check runs-on: self-hosted timeout-minutes: 10 steps: # Uncomment to debug runner secrets and debug toggles # - name: Test Debug Secrets # run: | # echo "Testing if debug logging is enabled..." # echo "ACTIONS_RUNNER_DEBUG: ${{ secrets.ACTIONS_RUNNER_DEBUG }}" # echo "ACTIONS_STEP_DEBUG: ${{ secrets.ACTIONS_STEP_DEBUG }}" - name: Stream Telemetry Data (Long-Running Task) run: | echo "Beginning simulated 60-second rocket launch sequence..." for i in {1..12}; do echo "T-minus $((60 - i * 5)) seconds: Systems nominal..." sleep 5 done echo "πŸš€ Lift off!" ``` This workflow will appear in GitHub Actions and can be started manually (workflow\_dispatch) or by pushing to the repository. ## 2. Run the job and cancel it from the GitHub Actions UI Start the workflow (push or manual trigger). If you cancel the running workflow from the GitHub Actions UI while the step is executing, the job log will show the running shell output and then an error like: ```bash theme={null} Run echo "Beginning simulated 60-second rocket launch sequence..." Beginning simulated 60-second rocket launch sequence... T-minus 55 seconds: Systems nominal... T-minus 50 seconds: Systems nominal... T-minus 45 seconds: Systems nominal... T-minus 40 seconds: Systems nominal... T-minus 35 seconds: Systems nominal... T-minus 30 seconds: Systems nominal... T-minus 25 seconds: Systems nominal... Error: The operation was canceled. ``` At this point the UI shows the job as canceled. To determine why it was canceled and how the runner handled the shutdown, inspect the self-hosted runner host directly. ![A dark-themed GitHub Actions page for a repository, showing the "Rocket Launch Telemetry Demo" workflow with its run history and a notice about an upcoming GitHub App installation token format change. The left sidebar lists other workflows and management options like Caches and Runners.](https://mintcdn.com/kodekloud-c4ac6d9a/Ae2SeWV4btujbkSt/images/GitHub-Administration-Certification/GitHub-Actions-and-Runners/Demo-Github-Actions-Self-Hosted-Runner-Diagnostics/github-actions-rocket-launch-telemetry-notice.jpg?fit=max\&auto=format\&n=Ae2SeWV4btujbkSt\&q=85\&s=118f7ddd4a75749d026683913b3d4027) ## 3. Inspect the self-hosted runner process On the self-hosted runner host, start or watch the runner with the provided `run.sh` script: ```bash theme={null} root ~/actions-runner on ☁️ (us-east-2) ❯ ./run.sh βœ” Connected to GitHub Current runner version: '2.336.0' 2026-08-25 06:15:41Z: Listening for Jobs 2026-08-25 06:19:51Z: Running job: test-composite-action 2026-08-25 06:20:02Z: Job test-composite-action completed with result: Succeeded 2026-08-25 06:31:29Z: Running job: Telemetry Stream & API Check ``` If you cancel the job from the UI, the runner process output records the cancellation: ```bash theme={null} 2026-08-25 06:32:07Z: Job Telemetry Stream & API Check completed with result: Canceled ``` The runner repo directory typically contains `_work` (job working directories) and `_diag` (diagnostic logs). List the runner directory: ```bash theme={null} root ~/actions-runner on (us-east-2) ❯ ls -la _diag _work bin config.sh env.sh run-helper.sh run.sh svc.sh ... (other files) ``` ## 4. Explore `_work` β€” job working directories and temp files Inspect `_work` to find per-run directories, checked-out repositories, and temporary files: ```bash theme={null} root ~/actions-runner on ☁️ (us-east-2) ❯ ll _work/ total 28 drwxr-xr-x 7 batman batman 4096 Aug 25 06:32 ./ drwxr-xr-x 6 batman batman 4096 Aug 25 06:15 ../ drwxr-xr-x 3 batman batman 4096 Aug 25 06:19 _PipelineMapping/ drwxr-xr-x 3 batman batman 4096 Aug 25 06:32 _actions/ drwxr-xr-x 2 batman batman 4096 Aug 25 06:32 _temp/ drwxr-xr-x 2 batman batman 4096 Aug 25 06:19 _tool/ drwxr-xr-x 3 batman batman 4096 Aug 25 06:19 ghas-guardrail-demo/ ``` Useful quick-checks: * Look for the temp script run by the step in `_work/_temp/`. * Check the workspace for artifacts or partial output that may indicate abrupt termination. ## 5. Check diagnostic logs in `_diag` The `_diag` folder contains the most useful files for deep debugging: `Runner_*` and `Worker_*` logs. List them: ```bash theme={null} root ~/actions-runner/_diag on ☁️ (us-east-2) ❯ ll total 456 -rw-r---- 1 batman batman 20049 Aug 25 06:15 Runner_20260825-061404-utc.log -rw-r--r-- 1 batman batman 57130 Aug 25 06:32 Runner_20260825-061538-utc.log -rw-r--r-- 1 batman batman 144255 Aug 25 06:20 Worker_20260825-061952-utc.log -rw-r--r-- 1 batman batman 76438 Aug 25 06:32 Worker_20260825-063130-utc.log -rw-r--r-- 1 batman batman 143846 Aug 25 06:32 Worker_20260825-063212-utc.log drwxr-xr-x 2 batman batman 4096 Aug 25 06:32 blocks/ drwxr-xr-x 2 batman batman 4096 Aug 25 06:32 pages/ ``` Search for cancellation-related entries. Common greps: * `cancel` * `Operation canceled` * `Force kill process on cancellation` * `BrokerServer` Example: find canceled socket operations: ```bash theme={null} root ~/actions-runner/_diag on ☁️ (us-east-2) ❯ cat Worker_20260825-063212-utc.log | grep -i "Operation canceled" [2026-08-25 06:32:21Z ERR BrokerServer] System.IO.IOException: Unable to read data from the transport connection: Operation canceled. ---> System.Net.Sockets.SocketException (125): Operation canceled [2026-08-25 06:32:21Z ERR BrokerServer] System.Net.Sockets.SocketException (125): Operation canceled [2026-08-25 06:32:21Z WARN BrokerServer] Back off 5.544 seconds before next retry. 4 attempt left. [2026-08-25 06:32:21Z INFO BrokerMessageListener] Get messages has been cancelled using local token source. Continue to get messages with new status. ``` This output indicates the runner’s broker connection encountered a canceled socket operation β€” consistent with an API-initiated cancellation or a network/transport failure. Other `_diag` entries to watch for: ```text theme={null} [2026-08-25 06:15:13Z INFO ProcessInvokerWrapper] Force kill process on cancellation: 'False' [2026-08-25 06:15:13Z INFO ProcessInvokerWrapper] Process started with process id 10941, waiting for process exit. [2026-08-25 06:15:13Z INFO ProcessInvokerWrapper] Finished process 10941 with exit code 0, and elapsed time 00:00:00.0013462. [2026-08-25 06:15:13Z INFO Listener] Runner execution has finished with return code 0 ``` * `Force kill process on cancellation: 'False'` means the runner tries a graceful shutdown of child processes instead of forcing them to exit immediately. ## 6. Results upload and cleanup after cancellation Even after a cancel, the runner typically tries to upload step logs and job logs to the results service and then cleans up temporary directories: ```text theme={null} [2026-08-25 06:32:16Z INFO JobServerQueue] Starting upload of step log file to results service ResultsLog, /home/batman/actions-runner/_diag/blocks/_... .1 ... [2026-08-25 06:32:20Z INFO JobServerQueue] Tried to upload 5 file(s) to results, success rate: 5/5. [2026-08-25 06:32:20Z INFO JobServerQueue] Results upload queue drained. [2026-08-25 06:32:20Z INFO TempDirectoryManager] Cleaning runner temp folder: /home/batman/actions-runner/_work/_temp ``` This confirms logs are preserved and uploaded β€” allowing you to continue debugging via the GitHub UI. ## 7. Enable more verbose debugging To get more detailed information during execution: * Enable workflow step debug logging by setting the repository secret `ACTIONS_STEP_DEBUG` to `true`. * Enable runner debug logging by setting the repository secret `ACTIONS_RUNNER_DEBUG` to `true` (or enable it via runner configuration locally). Placeholders for these were included as commented-out steps in the example workflow above. Enable `ACTIONS_STEP_DEBUG` and/or `ACTIONS_RUNNER_DEBUG` only temporarily. Debug logs are very verbose and can expose sensitive data β€” do not leave these enabled in production long-term. When step debug is enabled, the job log includes `##[debug]` lines. Example showing a step aborted with exit code 130 (SIGINT / CTRL-C): ```text theme={null} ##[debug]Starting: Stream Telemetry Data (Long-Running Task) β–Έ Run echo "Beginning simulated 60-second rocket launch sequence..." ##[debug]/usr/bin/bash -e /home/batman/actions-runner/_work/_temp/ba1d14d7-1432-47df-a91b-22f8e3bff4a1.sh Beginning simulated 60-second rocket launch sequence... T-minus 55 seconds: Systems nominal... T-minus 45 seconds: Systems nominal... T-minus 40 seconds: Systems nominal... T-minus 35 seconds: Systems nominal... Error: Process completed with exit code 130. ##[debug]Re-evaluate condition on job cancellation for step: 'Stream Telemetry Data (Long-Running Task)' ##[debug]Skip Re-evaluate condition on runner shutdown. ##[debug]Finishing: Stream Telemetry Data (Long-Running Task) ``` * Exit code 130 typically indicates termination by SIGINT (signal 2 / user cancel). Different exit codes point to other termination reasons. ## 8. Quick reference β€” runner folders and useful grep terms | Location | Purpose | Typical use | | -: | - | - | | `_work/` | Job workspaces, checked-out repos, temp scripts | Inspect `_work/_temp/` for the shell script that was executing when canceled | | `_diag/` | Runner and worker diagnostic logs | Grep `Runner_*` and `Worker_*` logs for cancellation traces | | `_diag/blocks/` and `_diag/pages/` | Uploaded log blocks and pages | Contains files referenced in results upload entries | | Runner process output | Live connection and job lifecycle events | Shows "Running job" and "completed with result: Canceled" messages | Common grep terms to find cancellation context: * `cancel` * `Operation canceled` * `Force kill process on cancellation` * `BrokerServer` * `ProcessInvokerWrapper` ## 9. Troubleshooting checklist * Check the GitHub Actions job log first for step output and any `Error: The operation was canceled.` messages. * On the runner host: * Inspect `_work/` for the workspace and temp scripts. * Inspect `_diag/` (`Runner_*` and `Worker_*` logs) for detailed traces, socket errors, stack traces, and upload activity. * Grep `_diag` logs for the terms listed above to quickly locate cancellation-related traces. * Confirm whether the runner process was stopped (e.g., `^C`, service restart) β€” stopping the runner while jobs are running causes the server to mark them canceled. * If you need deeper information, enable `ACTIONS_STEP_DEBUG` and/or `ACTIONS_RUNNER_DEBUG` temporarily and rerun the workflow. * Determine if the cancel came from: * A user/API call (UI cancel or REST API) * Runner process termination * Network/transport error that aborted the broker connection Using the job log together with `_diag` and `_work` inspection will let you determine whether a cancel was user-initiated, runner-initiated (shutdown), or caused by an underlying transport/socket error. ## Links and references * [GitHub Actions documentation](https://docs.github.com/actions) * [Self-hosted runner documentation](https://docs.github.com/actions/hosting-your-own-runners) > [card] [Watch Video](https://learn.kodekloud.com/user/courses/github-administration-certification/module/3ba840c5-7afb-4da9-8395-a430a6354557/lesson/0d4eae12-c1d7-4605-912f-5eadf0176f88) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.