Describe the bug
Starting in what appears to be datadog 2.6.0, we've found that controllers that are not cleanly restarted when jobs are in progress (first discovered when a controller OOM'd, but we can reproduce by just killing the process) come back with items that are "in" the queue but cannot be deleted. In addition, node creation (using the ec2 plugin) and saving configuration at the manage UI all never make an HTTP response. All of these are events that typically send datadog events, and I can reproduce running a fresh jenkins:lts docker image with default plugins, plus datadog.
The only way we've found to clear the behavior is to visit the job(s) stuck in the queue and delete the build. Then after a restart, it comes back as normal.
We haven't been able to reproduce yet on any version of datadog prior to 2.6.0, (tested on 0.7.1 (don't ask...) 1.0.0, 2.0.0, and all 2.x minor releases) and have not yet tested on the 2.7.0 release yesterday.
I'm not entirely sure what mechanism in the datadog plugin could even cause this behavior, but I'm hoping someone here does.
To Reproduce
Steps to reproduce the behavior:
docker run -p 8080:8080 -p 50000:50000 -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts
- Do initial Jenkins setup, accepting defaults.
- Install the datadog plugin.
- Start a long-running job. All of ours are Jenkinsfile pipelines, but a
sh 'sleep 300' seems sufficient to reproduce for us.
- Forcibly terminate Jenkins without waiting for jobs to finish (eg.,
docker kill)
- When Jenkins returns, note the job still in the queue. Attempts to delete it will fail.
- Visit
/configure on the controller and set a system message to exercise saving configurations. Attempts to save or apply will fail.
To Remediate
- Once in this state, visit the job that is stuck in the queue. Stop the run from the build UI, and then delete the run.
- Restart Jenkins. You may need to forcibly terminate, as we've seen Jenkins get stuck "shutting down" when it is in this state. After restart, the queue will now progress, and configurations can be saved.
Expected behavior
After an unexpected shutdown, Jenkins should continue to process jobs and accept configuration changes.
Environment and Versions (please complete the following information):
A clear and precise description of your setup:
- datadog 2.6.0
- Jenkins 2.263.1
Describe the bug
Starting in what appears to be datadog 2.6.0, we've found that controllers that are not cleanly restarted when jobs are in progress (first discovered when a controller OOM'd, but we can reproduce by just killing the process) come back with items that are "in" the queue but cannot be deleted. In addition, node creation (using the ec2 plugin) and saving configuration at the manage UI all never make an HTTP response. All of these are events that typically send datadog events, and I can reproduce running a fresh
jenkins:ltsdocker image with default plugins, plus datadog.The only way we've found to clear the behavior is to visit the job(s) stuck in the queue and delete the build. Then after a restart, it comes back as normal.
We haven't been able to reproduce yet on any version of datadog prior to 2.6.0, (tested on 0.7.1 (don't ask...) 1.0.0, 2.0.0, and all 2.x minor releases) and have not yet tested on the 2.7.0 release yesterday.
I'm not entirely sure what mechanism in the datadog plugin could even cause this behavior, but I'm hoping someone here does.
To Reproduce
Steps to reproduce the behavior:
docker run -p 8080:8080 -p 50000:50000 -v jenkins_home:/var/jenkins_home jenkins/jenkins:ltssh 'sleep 300'seems sufficient to reproduce for us.docker kill)/configureon the controller and set a system message to exercise saving configurations. Attempts to save or apply will fail.To Remediate
Expected behavior
After an unexpected shutdown, Jenkins should continue to process jobs and accept configuration changes.
Environment and Versions (please complete the following information):
A clear and precise description of your setup: