CODEWITHSUNDEEP
azure-devopsyamlazure-pipelinesazure-pipelines-yaml
sveinungf
sveinungf

Reputation: 1081

Azure DevOps YAML build pipeline stuck on self-hosted agent

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.

Upvotes: 4

Views: 15752

Answers (5)

phifi
phifi

Reputation: 3028

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.

Upvotes: 0

Promise Preston
Promise Preston

Reputation: 28920

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

Upvotes: 1

Bill Holman
Bill Holman

Reputation: 21

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".

Upvotes: 2

sveinungf
sveinungf

Reputation: 1081

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.

Upvotes: 4

LoLance
LoLance

Reputation: 28126

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.

Upvotes: 1

Related Questions