Repository navigation
[JENKINS-3891] Build 'appears to be stuck' even if in queue #18864
Description
If I understand the abort stuck builds feature, it is intended to kill builds
that hang due to some sort of execution. However, builds are reported to be
stuck even if they are simply waiting their turn in the queue. It seems like
this timer should not start until the job begins execution.
Originally reported by 
pamdirac, imported from: Build 'appears to be stuck' even if in queue
- assignee:
kohsuke
- status: Closed
- priority: Major
- component(s): core
- resolution: Fixed
- resolved: 2009-06-23T15:36:37+00:00
- votes: 0
- watchers: 0
- imported: 2025-11-24
Raw content of original issue
If I understand the abort stuck builds feature, it is intended to kill builds that hang due to some sort of execution. However, builds are reported to be stuck even if they are simply waiting their turn in the queue. It seems like this timer should not start until the job begins execution.
- environment:
Platform: All, OS: All
Activity
jenkins-infra-bot commentedon Jun 19, 2009
Raw content of original comment:
The intention of marking such jobs in the queue is to let you know that these
are starving for additional executors — it's time to add more slaves.
Perhaps we should change the wording a bit? Like from "stuck" to "starving
executors" or something like that? With perhaps a hyperlink to a page in Wiki
that talks about what you are supposed to do when you see it?
Or maybe we should change the color from red to something less scary, like yellow?
jenkins-infra-bot commentedon Jun 20, 2009
Raw content of original comment:
when you mouseover the link I think it already shows the reason (awaiting an
executor...).. maybe change the text to an icon and keep the mouseover text.
confusing wording gone
jenkins-infra-bot commentedon Jun 20, 2009
Raw content of original comment:
Ah, so I think I misunderstood the feature. When I set a value for "Abort the
build if it's stuck", this same timeout applies separately to executor
starvation and the actual build execution time?
I guess what's weird is that we have different jobs that take wildly varying
lengths of time. So I have timeouts for various jobs at 5 minutes, 30 minutes,
1 hour and 3 hours. For a couple of hours during the day for us, it's very easy
to get a 15-minute queue depth. The five minute jobs will then be reported as
stuck while sitting in the queue, but the other jobs won't.
I think that just a better indication of what is really happening is an ok solution.
jenkins-infra-bot commentedon Jun 23, 2009
Raw content of original comment:
Code changed in hudson
User: : jglick
Path:
trunk/hudson/main/core/src/main/resources/lib/hudson/queue.jelly
trunk/hudson/main/war/images/hourglass.svg
trunk/hudson/main/war/resources/images/16x16/hourglass.gif
trunk/hudson/main/war/resources/images/24x24/hourglass.gif
http://fisheye4.cenqua.com/changelog/hudson/?cs=19163
Log:
[FIXED JENKINS-3891] Replaced misleading, verbose, and scary red "(appears to be stuck)" label with a warning icon & tooltip.
jenkins-infra-bot commentedon Jun 23, 2009
Raw content of original comment:
Code changed in hudson
User: : jglick
Path:
trunk/www/changelog.html
http://fisheye4.cenqua.com/changelog/hudson/?cs=19164
Log:
JENKINS-3891Noting.jenkins-infra-bot commentedon Jul 21, 2009
Raw content of original comment:
jenkins-infra-bot commentedon Nov 24, 2025
[Original
is_duplicated_byfrom Jira: JENKINS-3040]