Repository navigation
[JENKINS-17667] Unable to kill a job which is running #14503
Description
When I kill a running job in Jenkins at the very early stage of its build, it doesn't get killed and goes to a null state. I can't see that in the main console, but when I go to the job page, I see the job running. I am unable to kick off another build for the same job as it says that the job is already running. Please see the screenshot.
The only way I have for now is to restart jenkins. It has been happening quite frequently in the past 2-3 days time. Please send me a resolution for this at the earliest, it is not easy to restart jenkins very often in a busy day.
Thanks,
Aswini
Originally reported by aswini_r, imported from: Unable to kill a job which is running
- assignee:
jglick
- status: Resolved
- priority: Major
- component(s): core
- label(s): 1.565.3-fixed, threads, tools
- resolution: Fixed
- resolved: 2015-05-12T10:07:29+00:00
- votes: 1
- watchers: 16
- imported: 2025-11-24
Raw content of original issue
When I kill a running job in Jenkins at the very early stage of its build, it doesn't get killed and goes to a null state. I can't see that in the main console, but when I go to the job page, I see the job running. I am unable to kick off another build for the same job as it says that the job is already running. Please see the screenshot. The only way I have for now is to restart jenkins. It has been happening quite frequently in the past 2-3 days time. Please send me a resolution for this at the earliest, it is not easy to restart jenkins very often in a busy day.
Thanks, Aswini
- environment:
Red Hat Linux, Jenkins version 1.505
Activity
jenkins-infra-bot commentedon Apr 19, 2013
aswini_r:
Raw content of original comment:
Any updates on this issue?
jenkins-infra-bot commentedon Apr 23, 2013
aswini_r:
Raw content of original comment:
Why am I not getting any updates? I know that there will be lot of issues daily and its hard to resolve everything at the earliest. But atleast a small comment saying that we are working on this would do. This is a blocker for me daily. I end up restarting jenkins to resolve this issue.
jenkins-infra-bot commentedon Apr 23, 2013
Raw content of original comment:
Aswini, I think you may have misunderstood the nature of open source projects. Open source projects are addressed by a community of interested users who implement enhancements and work on problems based on their needs and their interests.
I think the response you're expecting is much closer to commercial support, rather than an open source community. You might consider contacting CloudBees about their commercially supported offering based on Jenkins.
There is also a concept of a "bug bounty" that I've seen offered elsewhere in the Jenkins project, though I'm not sure if that generally has the result you are seeking, since you seem to be seeking response times more typical of commercial products than open source projects.
jenkins-infra-bot commentedon Apr 23, 2013
aswini_r:
Raw content of original comment:
Hi Mark, I thought this forum will be watched by the Jenkins developers and they will post a solution for my question. If you have any answer for my query, can you let me know? Thanks.
jenkins-infra-bot commentedon Apr 23, 2013
Raw content of original comment:
I don't have an answer to your question. I've observed that sometimes a Jenkins job is harder to interrupt than others. My usual technique has been to click the "x" to stop the job, then if the job has not stopped shortly, I'll click somewhere else in the UI (causing the page to refresh), then click the "x" to stop the job a second time.
jenkins-infra-bot commentedon Apr 23, 2013
aswini_r:
Raw content of original comment:
My issue is that there is no log itself for that job and it keeps running for null time in the machine. The only way for me to kick off the job is to do after restarting jenkins.
This happens when I kill the job as soon as it starts.
jenkins-infra-bot commentedon Feb 26, 2014
ikedam:
Raw content of original comment:
This seems a issue of Jenkins-core rather than build-timeout plugin.
jenkins-infra-bot commentedon Mar 12, 2014
axelb:
Raw content of original comment:
I think I have the same problem. What I see is this:
jenkins-infra-bot commentedon Mar 14, 2014
situboo:
Raw content of original comment:
I've seen this from time to time. Any attempt at killing the job is useless (from the gui, from a curl command). I have seen this more frequently in the past and now it's back. I'm suspecting it may be related to using locks and latches... I wonder if there's a timeout that may have been exceeded and it's left in a state of limbo.
One thing I can suggest... it's rather drastic. But as I'm a pretty heavy user of the jenkins cli, if you pull down the job configuration, you can delete the job (removing this ghost running build) and recreate the job. You loose build history etc. but if you really need to get rid of it and a restart of Jenkins is simply out of the question.
jenkins get-job abc > config.xml
jenkins delete-job abc
jenkins create-job abc < config.xml
hth,steven
and of course 'jenkins' in the above example is a shell script of
#!/bin/bash
java -jar ~/bin/jenkins-cli.jar -s https://jenkins_url -i ~/.ssh/id_rsa $@
And by the way... having used commercial software for years.. I've never seen the level of response that's being suggested.
jenkins-infra-bot commentedon Apr 7, 2014
Raw content of original comment:
I am encountering this issue as well. There are many threads stuck on the line
The version of java I'm using:
Jenkins version:
Jenkins ver. 1.557
It seems as if the same WeakHashMap instance is being used by multiple threads, and since in the documentation for WeakHashMap it says
http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html
It seems like you should be using Collections.synchronizedMap on this or you should prboably use
http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/cache/CacheBuilder.html
which allows for weak keys and is thread safe.
jenkins-infra-bot commentedon Apr 7, 2014
Raw content of original comment:
I took a look at
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/tools/InstallerTranslator.java
and see a possible issue.
none of the Map.put or Map.get calls are wrapped in a synchronized block.
According to the java memory model Each Thread can have its own local view of memory that is inconsistent with another Thread.
This is to enable multiple CPUS to have their own caching and not force all reads/writes to be consistent with each other, which would slow things down.
So that if you have
Inorder to have consistency you can use volatiles, so
A volatile in effect forces a read on main memory instead a per thread cache.
Another way to achieve this effect is to use a synchronized block.
Thread1: synchrnoized(lock) { A.a=1; } Thread2: synchronized(lock) {System.out.println(A.a); } //Will print out 1.This is from my understanding of
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Now in your case, your gets and puts are not synchronized, so you can end up with strange behavior. I suggest wrapping your new WeakHashMap() invocations with Collections.synchronizedMap(new WeakHashMap())
jenkins-infra-bot commentedon Jul 11, 2014
Raw content of original comment:
Code changed in jenkins
User: Joshua Kolash
Path:
core/src/main/java/hudson/tools/InstallerTranslator.java
http://jenkins-ci.org/commit/jenkins/e3952f41c5649c326ace3cc263420a8c287e1e7c
Log:
[FIXED JENKINS-17667] - Syncronization of InstallerTranslator::getToolHome()
There appears to be some unthreadsafe initialization going on here.
Initialize/get inside a synchronized block for threadsaftey.
jenkins-infra-bot commentedon Jul 11, 2014
Raw content of original comment:
Code changed in jenkins
User: Daniel Beck
Path:
core/src/main/java/hudson/tools/InstallerTranslator.java
http://jenkins-ci.org/commit/jenkins/5ef293d7a0ac0a2f7a443a8460abda196f8056e0
Log:
Merge pull request #1176 from jkolash/master
[FIXED JENKINS-17667] - Syncronization of InstallerTranslator::getToolHome()
Compare: 7b70bd9...5ef293d
jenkins-infra-bot commentedon Jul 12, 2014
Raw content of original comment:
Code changed in jenkins
User: Daniel Beck
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/fdc0b5c5650b3ee849f02e3c5d94d23c12886adc
Log:
Noting #1314, #1316, #1308,
JENKINS-17667,JENKINS-22395,JENKINS-18065jenkins-infra-bot commentedon Jul 12, 2014
Raw content of original comment:
Integrated in
jenkins_main_trunk #3515
[FIXED JENKINS-17667] - Syncronization of InstallerTranslator::getToolHome() (Revision e3952f4)
Result = SUCCESS
joshua.kolash : e3952f41c5649c326ace3cc263420a8c287e1e7c
Files :
10 remaining items
jenkins-infra-bot commentedon Mar 5, 2015
Raw content of original comment:
Thread dump for the issue with Jenkins 1.593
jenkins-infra-bot commentedon Mar 5, 2015
Raw content of original comment:
After Jenkins restart, the timing has been adjusted and the node on which it seems Jenkins actually wanted to send the build has been fixed:
"took 0 ms on rhel6-3" (instead now of "master" as it was displayed while it was stuck).
So, that also matches the issue described, and the guy who did this confirmed: the build was tried to be killed very early during its launch.
jenkins-infra-bot commentedon Mar 5, 2015
Raw content of original comment:
@Daniel I reopened before seing your comment, because the symptoms are exactly the same at first sight, and I didn't want to disseminate data onto different JIRA issues when it seemed to be the same one.
But if needed I can still file a new one, and link to here.
jenkins-infra-bot commentedon May 12, 2015
Raw content of original comment:
Disable the job and then enable the job.. You will see that all jobs has killed and not rerunning.
jenkins-infra-bot commentedon May 12, 2015
Raw content of original comment:
A good idea as long as it never misleads or contradicts. As soon as that happens it's a mess and you need to figure out what's going on. Since you can mark jobs as being related, this shouldn't be an issue.
jenkins-infra-bot commentedon May 12, 2015
Raw content of original comment:
Not sure why this got reassigned away from me. I committed the fix to the known issue. (If there are other issues with similar symptoms, they should be filed separately and linked.)
jenkins-infra-bot commentedon Feb 8, 2016
sphalke:
Raw content of original comment:
I observed the same issue in the Jenkins version. 1.625.3. The issue occurred in the Multi-configuration project job. In my case the issue appeared after changing the Job weight of the Multi-configuration project job to 2 from 1. The next build of the Multi-configuration project job were non responsive. The non-responsive build under the build history displayed the on hover message "Started Null ago, Estimated remaining time: null." Could trigger the next build after reverting the job weight to 1 and after enabling the job configuration option "Execute concurrent builds if necessary"