Closed Bug 523830 Opened 16 years ago Closed 16 years ago

some recently imaged mac slaves do not have the correct version of buildbot

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: jhford)

Details

moz2-darwin9-slave22, and the rest of the minis in that batch (probably), do not have the right version of Buildbot on them. I would guess that they imaged they were deployed from had Buildbot already, which probably caused us to not update it after the imaging. This has caused some of the slaves to get hung in debug unittests, because the old version of Buildbot doesn't support the maxTime parameter on ShellCommands. Whomever fixes this should audit the rest of the mac slaves too.
I have verified that the buildbot that is first in the path (buildbot --version) is 0.7.10p1 on all mac slaves from 01-26. Maybe we have a different buildbot install that is in a different location that is called by launchd? $ buildbot --version Buildbot version: 0.7.10p1 Twisted version: 8.0.1
(In reply to comment #1) > I have verified that the buildbot that is first in the path (buildbot > --version) is 0.7.10p1 on all mac slaves from 01-26. Maybe we have a different > buildbot install that is in a different location that is called by launchd? > > $ buildbot --version > Buildbot version: 0.7.10p1 > Twisted version: 8.0.1 The version number doesn't cut it here. Try 'hg ident' in /tools/buildbot on slave22, you'll see that is a pretty old "0.7.10p1".
19,21-26 are all at 96306d317882. I was forced to run hg tip as there was a LockError on a lot of the slaves. Even though this does not tell you the current revision, it does tell you that it doesn't have the possibility of being up to date. I will update as many of these as I can. The process I plan on using is Graceful shutdown -> rename buildbot.tac -> cd /builds/buildbot -> hg pull -> hg update -r BUILDBOT_PRODUCTION -> restore buildbot.tac
Thanks for taking this, John. Did you check the xserves and try slaves, too?
Assignee: nobody → jford
moz2-darwin9-slave22 corrected No, i didn't check xserves or try.
moz2-darwin9-slave26 updated
bm-xserve07 is out of date as is try-mac-slave02. Adding to the list of machines to track. moz2-darwin9-slave19 updated
23,24,25 and try2 all updated. moz2-darwin9-slave25 has been given to Ben for testing. Will mark this bug as fixed when i see slave25 come back up
There's no call to 'python setup.py install' mentioned at the end of comment #3, which I believe is required to copy the files from the checkout into the locatiosn on PYTHONPATH. Please consult the ref platform doc to figure out all the arguements you need.
you're right. I will take these slaves out of production again and run the setup.py step
bhearsum: Does the recently fixed bug#524097 mean that jhford can stop doing this manually now?
What's the status on this bug ? Is moz2-darwin9-slave19 not running buildbot because of it ? try-mac-slave02 was sitting at the login prompt, so I've assumed that should be fixed.
(In reply to comment #11) > bhearsum: Does the recently fixed bug#524097 mean that jhford can stop doing > this manually now? Good point - all Mac slaves being managed by Puppet should have the synced up with the correct version. I'll have a look and make sure that's the case.
Indeed, I just checked darwin9-slave18 -> darwin9-slave26 and they all have the correct Buildbot here. John, sorry I didn't update this bug or otherwise let you know when bug 524097 landed.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.