Azure DevOps YAML build pipeline stuck on self-hosted agent

Question

I have an issue with running a YAML based build pipeline on self-hosted agents. After the build is triggered, it gets stuck on Preparing an agent for the job - Waiting for the request to be queued.

The azure-pipelines.yml looks like this:

trigger:
- master

pool:
  name: Default

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script'

If I change to a Microsoft hosted agent, the build does work:

trigger:
- master

pool:
  vmImage: ubuntu-16.04

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script'

The strange thing is that I have other existing YAML build pipelines that is working fine on the self-hosted agents, but all new pipelines I try to create just ends up getting stuck with Waiting for the request to be queued.

I have tried on what is currently the latest versions of the agent daemon, both 2.164.8 and 2.165.0, to no avail. I have also checked that I am not being limited by the maximum number of parallel jobs in DevOps.

Nigger

I suspect that the agent is missing capabilities to run the job, try and investigate that – Conservationist

The agent can run much more complex builds, so I find it strange for it to lack capabilities for such a simple build. – Nigger

well, you need to identify whats holding up the build. usually is capabilities. its not a matter of complex vs straightforward. your build might have arbitrary capability attached to it – Conservationist

Have you checked how many agents in current default agent pool? If you have both old and new agents in the pool, we can't make sure it will pick the new-version agent for us to run the job. (I once met similar issue when I use one quite old agent 16.3 version). I think you can create a new agent pool and register a new agent in that pool, then in your yaml specify to use the new agent pool. What's the result? – Benedikt

Answer 1

It turned out to be a permission issue to the agent pool. In Organization Settings => Agent Pools => POOL_NAME => Security, there is a setting called Grant access permission to all pipelines. After enabling this, my builds are now working as expected.

Nigger

Answer 2

Be sure and check that the agent is running in Windows services on the server. I had what appeared to be the same issue, but had a different root cause. The Azure Pipeline Agent... service was stopped after an unplanned outage which resulted in the the service not restarting. Someone or some process had set the service start property to "Auto Start(delay)" instead of "Auto Start".

Entente

Answer 3

The strange thing is that I have other existing YAML build pipelines that is working fine on the self-hosted agents, but all new pipelines I try to create just ends up getting stuck with Waiting for the request to be queued.

You only specify to use Default agent pool. So it will pick up one available agent in that pool to run the job.

Go Organization Settings => Agent Pools to check the available agents in Default agent pool.

We should make sure we have one available agent with version 2.164.8 and higher, it should be online status and enabled. And then we can temporarily disable other agents in that pool, run your pipeline again to check if it helps. (In this situation, it should pick the good agent to run your pipeline)

I guess maybe you have different definitions about pool: in your other old yaml pipelines. Or you can create a new Agent Pool named MyPool, and create one new agent in MyPool, then in your yaml specify to use name: MyPool to check if there's something wrong with the agents in Default pool.

Benedikt

Answer 4

I had a similar issue. When I checked my self-hosted agent it was showing as Offline.

The issue was that my azure-devops agent was not running.

Here's how I fixed it

First, I logged into the Linux server when the agent was installed:

Next, I navigated to the folder/directory where the azure-devops agent install files were extracted into:

cd <my-azure-devops-agent-directory>

When I listed the files, the contents below were shown (yours might be slightly different):

_diag
_work
bin  
config.sh  
env.sh  
externals  
kubectl  
license.html  
run-docker.sh  
run.sh  
runsvc.sh  
svc.sh

Next, install the azure-devops-agent as a service by running the file svc.sh using the command below:

sudo ./svc.sh install <your-user>

OR to install with root user:

sudo ./svc.sh install

Next, start the azure-devops-agent as a service by running the file svc.sh using the command below:

sudo ./svc.sh start

Check the status of the azure-devops-agent as a service by running the file svc.sh using the command below:

sudo ./svc.sh status

However, if you want to start the service in interactive mode then run run.sh file using the command:

./run.sh

Nobukonoby

Answer 5

In my case I had to manually update the agent to the most up-to-date version (from 2.xxx to 3.xxx) and for some reason this update wasn't applied automatically through the Azure DevOps Update funcionality in the CollectionSettings/Agent Pools.

Solidarity