Closed Bug 393852 Opened 17 years ago Closed 17 years ago

Kill stuck processes on qm-win2k3-01 after a clobber

Categories

(Release Engineering :: General, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rcampbell, Unassigned)

References

Details

This should apply to all machines running MSYS, really. Occasionally a process will get get stuck during a build preventing a complete clobber and usually resulting in a burning machine. Steps to remedy: shutdown slave, kill errant processes (usually by closing the command window and ending tasks), clobber objdir, restart slave. Unclear how we'll do this outside of buildbot. It may be possible to create some sort of meta script that can do this for us. see, https://bugzilla.mozilla.org/show_bug.cgi?id=393808
Does this have to be done outside of Buildbot? Can we just do it right in the clobber step?
um, in theory, I think we could. The problem is that the processes are owned by a shell window. We can do kills on all instances of firefox.exe, make.exe and sh.exe but without knowing the pids of each of these, we risk killing the buildbot process. We could use the clobber step to trigger a forced reboot, I guess once we've got automatic restarts in place. None of these seem like ideal solutions though.
So, every time I clobber win32 now, qm-win2k3-01 goes red, which means I have to get IT or somebody to fix it. This is blocking efforts to figure out problems and causing the tree to be closed for longer periods of time. Raising priority.
Severity: normal → critical
fixed as a result of bug 393413
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Mass move of Core:Testing bugs to mozilla.org:ReleaseEngineering. Filter on RelEngMassMove to ignore.
Component: Testing → Release Engineering
Product: Core → mozilla.org
QA Contact: testing → release
Version: unspecified → other
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.