svn got confused trying to incorporate updates to the email pkg. Slaves sparc solaris10 gcc trunk and x86 gentoo trunk got stuck in their trunk "updating" steps for 7 hours, presumably as a result. I killed those builds, and tried to start new builds on those slaves. There was no effect apart from their "pending" count rising from 6 to 7. They respond to pings, but won't start another build. I'm not sure how they get into such a state (but saw it at Zope Corp at times too). It's possible that their buildbot processes need to be restarted, and/or that the master process needs to be restarted.
On 3/18/06, Tim Peters
svn got confused trying to incorporate updates to the email pkg. Slaves
sparc solaris10 gcc trunk and x86 gentoo trunk
got stuck in their trunk "updating" steps for 7 hours, presumably as a result.
I killed those builds, and tried to start new builds on those slaves. There was no effect apart from their "pending" count rising from 6 to 7. They respond to pings, but won't start another build.
I've seen this happen a few times. It seems the only way to fix this is to restart the master which I did. After the restart, all the pending changes are lost, so I forced a rebuild on both machines. n
Tim Peters wrote:
I'm not sure how they get into such a state (but saw it at Zope Corp at times too). It's possible that their buildbot processes need to be restarted, and/or that the master process needs to be restarted.
It's a buildbot 0.7.1 bug (according to the 0.7.2 changelog); the sighup command sometimes gets confused. I thought it would survive the configuration change when no build is ongoing, but apparently I was wrong. Regards, Martin
participants (3)
-
"Martin v. Löwis" -
Neal Norwitz -
Tim Peters