Systemd service doesn't fail when runner listener crashes
See original GitHub issueDue to a permission issue the runner listener crashes, but the systemd service still shows up as running.
$ sudo systemctl status actions.runner.name-robotics-name_ci.image-build.service
● actions.runner.name-robotics-name_ci.image-build.service - GitHub Actions Runner (name-robotics-name_ci.image-build)
Loaded: loaded (/etc/systemd/system/actions.runner.name-robotics-name_ci.image-build.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-02-09 20:37:58 UTC; 8min ago
Main PID: 20082 (runsvc.sh)
Tasks: 8 (limit: 18966)
Memory: 6.6M
CGroup: /system.slice/actions.runner.name-robotics-name_ci.image-build.service
├─20082 /bin/bash /home/gh_actions_runner/runsvc.sh
└─20085 ./externals/node12/bin/node ./bin/RunnerService.js
Feb 09 20:45:57 image-build runsvc.sh[20085]: at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
Feb 09 20:45:57 image-build runsvc.sh[20085]: at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode)
Feb 09 20:45:57 image-build runsvc.sh[20085]: at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallo>
Feb 09 20:45:57 image-build runsvc.sh[20085]: at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocati>
Feb 09 20:45:57 image-build runsvc.sh[20085]: at GitHub.Runner.Common.HostTraceListener.CreatePageLogWriter()
Feb 09 20:45:57 image-build runsvc.sh[20085]: at GitHub.Runner.Common.HostTraceListener..ctor(String logFileDirectory, String logFilePrefix, Int32 pageSizeLimit, Int32 retentionDays)
Feb 09 20:45:57 image-build runsvc.sh[20085]: at GitHub.Runner.Common.HostContext..ctor(String hostType, String logFile)
Feb 09 20:45:57 image-build runsvc.sh[20085]: at GitHub.Runner.Listener.Program.Main(String[] args)
Feb 09 20:45:57 image-build runsvc.sh[20085]: Runner listener exited with error code null
Feb 09 20:45:57 image-build runsvc.sh[20085]: Runner listener exit with undefined return code, re-launch runner in 5 seconds.
Version 287.1 The restart should be handled by systemd and not internally on Linux.
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Why systemd doesn't know if a service failed?
This compat module works that the systemd considers the init script failed, and thus the service not working, if its exit code is...
Read more >Cannot get systemd to restart a service if it crashes
If set to on-failure , the service will be restarted when the process exits with a non-zero exit code, is terminated by a...
Read more >Systemd restart service if it's not listening to a port
I've been using Systemd for a while in Debian 8. I use the Restart=on-failure option to waken-up a service in case of failure....
Read more >Github self-hosted runner fails to run as a service on RH ...
After running the chcon command, I could run the start but it crashed instantly with a status=1/failure. So i ran the chcon command...
Read more >How to Crash Systemd in One Command
> The bug is caused by an error check that filters out garbage sent to PID 1. The check works correctly, except that...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi @bionade24,
We have successfully merged aPR that could solve this problem. It will be a part of the next release. Thank you for submitting this issue 😊
Hi @bionade24, I will label this as a feature request, so we can track it for future implementations 😊. Thank you for your fast response!