Action stuck for 4 days with Local Runner (Windows)

In one of our private repos the action is stuck and does not finish for 4 days!!!

No way to cancel.

Other queued jobs are not running. The local runner - even after restart - claims: “Listening for Jobs”.

What to do?

1 Like

Tried disabling Actions for the repo. Re-enabling leaves the same state.

The stuck actions is essentially done (failed) and hangs in this step:

Complete Job

   “Cleaning up orphan processes”

Could you provide the URL of the run which got stuck ?

Thanks for the quick response:

I think I can replicate the issue.

It happened here again (public repo this time):

I fear it is windows related as I was in the _work folder and as such the runner probably could not clean up due to Microsoft’s famous file locking.

After I left the subfolder the runner proceeded, however the job is in limbo now.

Cancelling or even disconnecting the runner will not clear the status - and as such it will block everything else.

So basically we have a guaranteed way to limbo github actions.

Same here.

If it is possible, could you help me remove all “Queued” and “stuck” actions?

Thank you.

Not sure if this was someones doing or not but the public repo and the other commenters repo seem to be solved.

My private repo is still in limbo since 6 days:

Basically I am blocked since two days and can not proceed with my work.

Any help?

For reference:

github support told me that while certain workflows still look like they would stall, you can create a new run and it would work. Even, like in my case when there seem to be queued jobs.

Just trigger a new job and it will run instead. This worked for me.

I have seen the same issue with a self-hosted MacOS.

Similar to the solution below. I was able to run a second workflow, even though the statuses incorrectly showed ‘running’ and ‘queued’. By the next day the statuses finally updated.

This was only the status in the action list on GitHub that was incorrect. Viewing the details revealed that all steps had finished.

I don’t think this should be counted as a solution, but rather a workaround for the actual issue.

I encounter this issue usually with Windows runners, not sure if it’s still relevant, here are the details:

I found out my issue - I was running msiexec and apparently it causes issues, probably because it attempts to open a new window while it’s running on a headless machine.