osdir.com
mailing list archive

Subject: Re: Minor bug: buildbot fails to follow twistd.log on OSX - msg#00102

List: python.buildbot.devel

Date: Prev Next Index Thread: Prev Next Index
> > this is a problem I observed only on OSX so I suspect it's due to
> > some portability issue on this OS.

I've opened ticket #141 to track this one.. it bites me all the time too.

-Brian


http://buildbot.net/trac/ticket/141

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

Re: bug in 0.7.6 with 'buildbot reconfig'?

On Sat, 17 Nov 2007 16:29:51 +1100 John Pye <john.pye-FCV4sgi5zeUQrrorzV6ljw@xxxxxxxxxxxxxxxx> wrote: > Hi all > > Ben Hearsum wrote: > > Greg Ward wrote: > > > >> On Nov 14, 2007 8:47 AM, John Pye > >> <john.pye-FCV4sgi5zeUQrrorzV6ljw@xxxxxxxxxxxxxxxx> wrote: > >> > >>> I have what seems to be a bug with the 'buildbot reconfig' > >>> command in Buildbot 0.7.6. When I do a 'buildbot restart .' > >>> everything works fine. When I do a 'buildbot reconfig .' it also > >>> works fine, but only if I do it once. If I make further config > >>> changes then again attempt 'buildbot reconfig .' then I get a > >>> page with debug output as follows. > >> [...] > >> > >>> web.Server Traceback (most recent call last): > >>> > >>> exceptions.AttributeError: 'NoneType' object has no attribute > >>> 'getStatus' > >> Yes, I have also seen this with 0.7.6. I have not been able to > >> nail it down as precisely as you have. Hang on a second and I'll > >> try ... > >> > >> ... nope. I just did "buildbot restart" and then "buildbot > >> reconfig" four times in a row, and no error. Of course, I didn't > >> make any config changes for those reconfig runs ... > >> > >> ... nope. I just did several "reconfig" runs with an actual > >> configuration change between each one, and it's still fine. > >> > > > > Did you make any kind of changes to the config file when you did > > this? I think it has something to do with the way the new Waterfall > > consumes the soul of it's predecessor. FWIW, only Builders consume the soul of their predecessor. The WebStatus and Waterfall objects are stateless, so they have no soul to be consumed :). It feels like you've got a TCP port providing access to a Waterfall object which is no longer active (i.e. it's been de-parented, so that self.parent.getStatus() throws an exception). I can't think of why this could be happening, but to provide background for anyone else looking into this, here's how config changes work: 1: the buildmaster has a Waterfall instance as one of its children. Let's call this Instance A. This is active, with a self.parent, and a TCP Listener that points to it. 2: 'buildbot reconfig' causes the config file to be executed, causing everything inside it to be instantiated, creating a Waterfall instances that we'll call Instance B. This Instance B is not active: it has no self.parent, and is not yet running a TCP Listener 3: The buildmaster compares the existing Instance A with the proposed Instance B for equality. Each config file object defines __cmp__ to specify what it means to be "equal", usually by using ComparableMixin and listing the attributes that should be compared. The general idea is that everything you can set in the constructor arguments should be compared for equality. 4: if A and B are equal, the buildmaster ignores B and keeps using A. B gets forgotten and garbage collected. 5: if A and B are not equal, the buildmaster needs to replace the old one with the new one. It does the following: 5a: detach the old Instance A by calling A.disownServiceParent(). The act of deparenting it causes it to be shut down (i.e. A.stopService() is called), causing the TCP Listener to be terminated. This takes a while to run (i.e. it returns a Deferred). 5b: once A is shut down, B is attached with B.setServiceParent(buildmaster). This causes B to be started up, and the first thing it does is to set up a TCP Listener so the outside world can get to it. 6: all done So it feels like the old Instance A is being deparented (disownServiceParent has managed to erase self.parent) without being shut down (stopService didn't manage to turn off the TCP Listener). Perhaps an exception occurred in between these two steps which prevented stopService from finishing? Are there any "Unhandled Error in Deferred" or other exceptions in your twistd.log at the time you do the reconfig or shortly thereafter? cheers, -Brian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Next Message by Date: click to view message preview

Re: sharing buildsteps

Brian Warner wrote: > On Mon, 19 Nov 2007 14:01:19 -0500 > "Greg Ward" <gerg.ward+buildbot-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx> > wrote: > >> I don't know what the Official Recommended Best Practice is, but I >> have been using good old-fashioned procedural abstraction. > > FWIW, I've been using a similar approach, where I create the BuildFactories > in a python subroutine in my master.cfg, usually with some parameters that > control the inputs to certain buildsteps. For example, one of them looks like > this: Yes, I can see how this works (and in fact that is how I have done it myself). However, I wonder whether it wouldn't be possible to cover the same functionality with a more declarative syntax (given that we are talking about a configuration file). Brian, I know you had plans to implement a 'clone' method for steps. As the BuildFactories already are sharable, I wonder what's missing to make individual steps sharable, too. It's just a different granularity... Many thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Previous Message by Thread: click to view message preview

Re: Minor bug: buildbot fails to follow twistd.log on OSX

On 13 Nov 2007, at 10:52, Benoit Sigoure wrote: > Hi list, > this is a problem I observed only on OSX so I suspect it's due to > some portability issue on this OS. > > -------------------------------------------------------------------------- > $ buildbot restart . > buildbot process 24190 is dead > now restarting buildbot process.. > Following twistd.log until startup finished.. > > The buildmaster took more than 10 seconds to start, so we were > unable to > confirm that it started correctly. Please 'tail twistd.log' and look > for a > line that says 'configuration update complete' to verify correct > startup. > -------------------------------------------------------------------------- > > I *always* get this error, for both the buildmaster and the > buildslaves, it's systematic. However, the buildmaster/buildslave > always starts properly. I think the error is solely due to the fact > that buildbot fails to track the content of twistd.log, for some > reason. I can confirm that I get this error too on Mac OS X using the 0.7.5 version of the buildbot as a slave. Shaun ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/

Next Message by Thread: click to view message preview

bug in 0.7.6 with 'buildbot reconfig'?

Hi all I have what seems to be a bug with the 'buildbot reconfig' command in Buildbot 0.7.6. When I do a 'buildbot restart .' everything works fine. When I do a 'buildbot reconfig .' it also works fine, but only if I do it once. If I make further config changes then again attempt 'buildbot reconfig .' then I get a page with debug output as follows. Has anyone else seen this problem? Cheers JP web.Server Traceback (most recent call last): exceptions.AttributeError: 'NoneType' object has no attribute 'getStatus' /usr/lib/python2.4/site-packages/twisted/web/server.py, line 160 in process 158    try: 159      resrc = self.site.getResourceFor(self) 160      self.render(resrc) 161    except: Self site twisted.web.server.Site instance @ -0x48b76714 <twisted.web.server.Site instance at 0xb74898ec> Locals resrc buildbot.status.web.waterfall.WaterfallStatusResource instance @ -0x48b76554 <buildbot.status.web.waterfall.WaterfallStatusResource instance at 0xb7489aac> self twisted.web.server.Request instance @ -0x48b8e9d4 <GET / HTTP/1.1> /usr/lib/python2.4/site-packages/twisted/web/server.py, line 167 in render 165  def render(self, resrc): 166    try: 167      body = resrc.render(self) 168    except UnsupportedMethod, e: Locals resrc buildbot.status.web.waterfall.WaterfallStatusResource instance @ -0x48b76554 <buildbot.status.web.waterfall.WaterfallStatusResource instance at 0xb7489aac> self twisted.web.server.Request instance @ -0x48b8e9d4 <GET / HTTP/1.1> Globals UnsupportedMethod <class twisted.web.server.UnsupportedMethod at 0xb773cc2c> /usr/lib/python2.4/site-packages/buildbot/status/web/base.py, line 210 in render 208      return '' 209 210    data = ""> 211    if isinstance(data, unicode): Locals self buildbot.status.web.waterfall.WaterfallStatusResource instance @ -0x48b76554 <buildbot.status.web.waterfall.WaterfallStatusResource instance at 0xb7489aac> request twisted.web.server.Request instance @ -0x48b8e9d4 <GET / HTTP/1.1> /usr/lib/python2.4/site-packages/buildbot/status/web/base.py, line 245 in content 243    s = request.site.buildbot_service 244    data = "" 245    data += self.fillTemplate(s.header, request) 246    data += "<head>\n" Locals data '' s buildbot.status.web.baseweb.Waterfall instance @ -0x48b6e014 <WebStatus on port tcp:8011 at -0x48b6e014> request twisted.web.server.Request instance @ -0x48b8e9d4 <GET / HTTP/1.1> self buildbot.status.web.waterfall.WaterfallStatusResource instance @ -0x48b76554 <buildbot.status.web.waterfall.WaterfallStatusResource instance at 0xb7489aac> /usr/lib/python2.4/site-packages/buildbot/status/web/base.py, line 239 in fillTemplate 237    # e.g. to reference the top-level 'buildbot.css' page, use 238    # "%(root)sbuildbot.css" 239    values['title'] = self.getTitle(request) 240    return template % values Locals values Dictionary instance @ -0x48a068ec 'root' '' request twisted.web.server.Request instance @ -0x48b8e9d4 <GET / HTTP/1.1> self buildbot.status.web.waterfall.WaterfallStatusResource instance @ -0x48b76554 <buildbot.status.web.waterfall.WaterfallStatusResource instance at 0xb7489aac> template '\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"\n "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">\n\n<html\n xmlns="http://www.w3.org/1999/xhtml"\n lang="en"\n xml:lang="en">\n' /usr/lib/python2.4/site-packages/buildbot/status/web/waterfall.py, line 417 in getTitle 415 416  def getTitle(self, request): 417    status = self.getStatus(request) 418    p = status.getProjectName() Locals self buildbot.status.web.waterfall.WaterfallStatusResource instance @ -0x48b76554 <buildbot.status.web.waterfall.WaterfallStatusResource instance at 0xb7489aac> request twisted.web.server.Request instance @ -0x48b8e9d4 <GET / HTTP/1.1> /usr/lib/python2.4/site-packages/buildbot/status/web/base.py, line 220 in getStatus 218 219  def getStatus(self, request): 220    return request.site.buildbot_service.getStatus() 221  def getControl(self, request): Locals self buildbot.status.web.waterfall.WaterfallStatusResource instance @ -0x48b76554 <buildbot.status.web.waterfall.WaterfallStatusResource instance at 0xb7489aac> request twisted.web.server.Request instance @ -0x48b8e9d4 <GET / HTTP/1.1> /usr/lib/python2.4/site-packages/buildbot/status/web/baseweb.py, line 458 in getStatus 456 457  def getStatus(self): 458    return self.parent.getStatus() 459  def getControl(self): Self parent None Locals self buildbot.status.web.baseweb.Waterfall instance @ -0x48b6e014 <WebStatus on port tcp:8011 at -0x48b6e014> exceptions.AttributeError: 'NoneType' object has no attribute 'getStatus' john.pye.vcf Description: Vcard ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________ Buildbot-devel mailing list Buildbot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/buildbot-devel
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by