Builder stuck on reset build
Bug #499095 reported by
Michael Nelson
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
Medium
|
Michael Nelson |
Bug Description
After a previous issue with this build, it was reset manually with some SQL so that job.date_started = null.
Now it's been dispatched again, and is causing the builder to be stuck.
https:/
Related branches
lp:~michael.nelson/launchpad/499095-build-retry-depwait-stuck
Merged
into
lp:launchpad
- Brad Crittenden (community): Approve (code)
-
Diff: 87 lines (+15/-16)2 files modifiedlib/lp/buildmaster/buildergroup.py (+2/-8)
lib/lp/soyuz/doc/buildd-slavescanner.txt (+13/-8)
Changed in soyuz: | |
status: | Confirmed → In Progress |
Changed in soyuz: | |
milestone: | none → 10.01 |
Changed in soyuz: | |
status: | Fix Released → In Progress |
Changed in soyuz: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
<bigjools> noodles: arg I just noticed an issue on the build farm, can you have a look no particular rush, things are still working. https:/ /edge.launchpad .net/ubuntu/ +archive/ test-rebuild- 20090909/ +build/ 1226841 /pastebin. canonical. com/25907/
<noodles> Sure
<bigjools> that build was one I reset previously
<bigjools> the builder it says it's on is reporting as idle
<bigjools> but since we have a build referring to it nothing is being dispatched to that builder
<noodles> um, something's dispatched now?
<noodles> gar, gone again. It had something listed as dispatched (open clipart)
<noodles> OK, so it keeps trying to dispatch and fails... k, looking into it.
<bigjools> yeah that's the bug :(
<noodles> bigjools: but when you say that you reset it, do you mean via sql?
<bigjools> noodles: whatever works :)
<noodles> bigjools: no, that was a question - you said that *you* reset it previously - I'm wondering whether that was an SQL query - if so, it'd be great to have the paste, as it's a very different thing if the data is inconsistent as opposed to a bug?
<noodles> Although, we should still handle the inconsistent data gracefully of course.
<bigjools> oh I see, yes it was
<bigjools> noodles: the data was originally inconsistent, so I just nulled the job start, BQ.builder and made buildstate 0 (NEEDSBUILD)
<bigjools> (sorry was OTP)
<noodles> Thanks
<bigjools> it's happened again
<bigjools> so I suspect a bug
<bigjools> which could be lingering data corruption
<bigjools> or it could be code
<noodles> And it was both times for this exact build 1226841?
<bigjools> yep
<bigjools> https:/
<bigjools> found my paste
<bigjools> seems like I superseded it