<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Just to close this thread: The problem seems to be resolved now.</p>
<p>My best guess is that sqlite retains a cache somewhere that
persists when one deletes the buildbot master and reboots the
machine.</p>
<p>As a result, the entire log contents for a step (not just the
workdir, as I originally thought) displayed results actually from
an earlier, outdated build.</p>
<p>Regardless of the underlying explanation, to workaround the
problem, I deleted, then re-created the buildbot master specifying
a different db URL:<br>
</p>
<p> buildbot create-master --db sqlite:///freshstate.sqlite -r
master<br>
</p>
<p>This requires a corresponding change to the master.cfg file:</p>
<p>c['db'] = {<br>
'db_url' : "sqlite:///freshstate.sqlite",<br>
}<br>
</p>
<p>After that, the logs for the individual steps (including the SVN
checkout step) started showing the correct workdir.</p>
<p>If anyone knows a way to clean sqlite's cache for the buildbot
database (without having to re-create the entire buildbot master),
I'd be most interested to learn that. <br>
</p>
<p>-Greg<br>
</p>
<br>
<div class="moz-cite-prefix">On 6/17/2016 10:03 AM, Greg Bullock
wrote:<br>
</div>
<blockquote cite="mid:b0a78e73-f161-e73f-e029-befbbfbca541@nwra.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p>The step page indeed shows the start time and end time the
step, but clicking the associated link under the Logs section
displays content that itself includes no time stamp.</p>
<p>For my current purposes, I'd like that log content to also
report the date & time.</p>
<p>Some anomaly on my system causes the buildbot to retain prior
memory and ultimately insert into the log a clue as to what it
remembers. I've been thinking that its memory is confined to
just the workdir -- related to location of the buildslave. But
so far I can't rule out that it's the entire log content getting
pulled from outdated memory.<br>
</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 6/16/2016 10:45 AM, Pierre Tardy
wrote:<br>
</div>
<blockquote
cite="mid:CAJ+soVeG-vHKubarTMXVLKM5XYtoLqqxpd2_3VF2BhO_Mui16A@mail.gmail.com"
type="cite">
<p dir="ltr">There is a start time and end time for each step
that you can see in the step page</p>
<br>
<div class="gmail_quote">
<div dir="ltr">Le jeu. 16 juin 2016 19:19, Greg Bullock <<a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:greg@nwra.com"><a class="moz-txt-link-abbreviated" href="mailto:greg@nwra.com">greg@nwra.com</a></a>> a
écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p><font size="-1"><font face="Helvetica, Arial,
sans-serif">It dawns on me that the problem may not
be that the buildbot somehow retains a memory of the
earlier location of a buildslave. It could instead
be that the entire log that displays is actually
from an earlier (and failed) build attempt.</font></font></p>
<p><font size="-1"><font face="Helvetica, Arial,
sans-serif">Is there a way to have buildbot insert a
datetime stamp into the log for a given step?</font></font></p>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<p><font size="-1"><font face="Helvetica, Arial,
sans-serif"><br>
</font></font></p>
<br>
<div>On 6/14/2016 3:01 PM, Greg Bullock wrote:<br>
</div>
<blockquote type="cite">
<div>I'm using <span
style="font-family:Verdana,Arial,sans-serif;text-align:justify;background-color:rgb(255,255,255)">version
0.8.12.</span></div>
<div><span
style="font-family:Verdana,Arial,sans-serif;text-align:justify;background-color:rgb(255,255,255)"><br>
</span></div>
<div><span
style="font-family:Verdana,Arial,sans-serif;text-align:justify;background-color:rgb(255,255,255)">I
have indeed rebooted the master. I've also deleted
the CentOS virtual machine (the slave) and created a
new one from a fresh install of the system. No
luck. </span></div>
<div><span
style="font-family:Verdana,Arial,sans-serif;text-align:justify;background-color:rgb(255,255,255)"><br>
</span></div>
<div><span
style="font-family:Verdana,Arial,sans-serif;text-align:justify;background-color:rgb(255,255,255)">I
have not tried both of these measures in the same
test, I wouldn't think that could make the
difference. </span></div>
<div><span
style="font-family:Verdana,Arial,sans-serif;text-align:justify;background-color:rgb(255,255,255)"><br>
</span></div>
<div><span
style="font-family:Verdana,Arial,sans-serif;text-align:justify;background-color:rgb(255,255,255)">I
will look into purging the sun cache, from the log,
it seems that the buildslave is already reporting
using the obsolete (and nonexistent) working
directory before it calls svn.</span></div>
<div><br>
</div>
<div>
<div style="font-size:85%;color:#575757">Greg Bullock</div>
<div style="font-size:85%;color:#575757">NorthWest
Research Associates</div>
<div style="font-size:85%;color:#575757"><a
moz-do-not-send="true">301 Webster St.</a></div>
<div style="font-size:85%;color:#575757"><a
moz-do-not-send="true">Monterey, CA 93940</a></div>
<div style="font-size:85%;color:#575757"> <a
moz-do-not-send="true"
href="tel:%28831%29%20582-4907" target="_blank">(831)
582-4907</a></div>
<div style="font-size:85%;color:#575757"><a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:greg@nwra.com"><a class="moz-txt-link-abbreviated" href="mailto:greg@nwra.com">greg@nwra.com</a></a></div>
</div>
<div><br>
</div>
<div style="font-size:100%;color:#000000">
<div>-------- Original message --------</div>
<div>From: Pierre Tardy <a moz-do-not-send="true"
href="mailto:tardyp@gmail.com" target="_blank"><tardyp@gmail.com></a>
</div>
<div>Date: 6/14/16 1:12 PM (GMT-08:00) </div>
<div>To: Greg Bullock <a moz-do-not-send="true"
href="mailto:greg@nwra.com" target="_blank"><greg@nwra.com></a>,
<a moz-do-not-send="true"
href="mailto:users@buildbot.net" target="_blank">users@buildbot.net</a>
</div>
<div>Subject: Re: [<a moz-do-not-send="true"
href="mailto:users@bb.net" target="_blank">users@bb.net</a>]
buildbot retains memory of an earlier location of a
buildslave? </div>
<div><br>
</div>
</div>
<div dir="ltr">Hi,
<div>Looks indeed like an interresting problem. Did
you try to reboot the master?</div>
<div><br>
</div>
<div>The master might indeed store the workdir, but I
would expect it to be reset when the work is
reconnecting.</div>
<div><br>
</div>
<div>Which version of buildbot is that?</div>
<div><br>
</div>
<div>Also thing to check is svn. could svn cache
something?</div>
<div><br>
</div>
<div>Regards</div>
<div>Pierre</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le mar. 14 juin 2016 à 21:04, Greg
Bullock <<a moz-do-not-send="true"
href="mailto:greg@nwra.com" target="_blank">greg@nwra.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Where
might the buildbot retain its memory of an earlier
location of a<br>
buildslave? I've moved a buildslave to a different
drive, but the log<br>
from the new build tests shows the steps (e.g., the
SVN, ShellCommand,<br>
and Compile steps) all running from the original
drive, not the new drive.<br>
<br>
My buildbot runs on Windows 7 64-bit, and this
particular buildslave<br>
(called "centos7-worker") runs on a virtual machine
on CentOS 7 (linux)<br>
hosted on the same Windows machine with the buildbot
master.<br>
<br>
Originally, the buildslave's files were on a shared
drive (which is also<br>
a Windows share shared from the Windows host), in<br>
/media/sf_G_DRIVE/buildbot/centos7-worker, but the
SVN checkout step<br>
would successfully checkout only about half the
project, then give an error<br>
<br>
------------------------------------------------------------<br>
... (previous lines omitted)<br>
svn: E200030: disk I/O error, executing statement
'RELEASE s10246'<br>
svn: E200030: sqlite: disk I/O error<br>
svn: E200030: sqlite: disk I/O error<br>
svn: E200030: no such savepoint: s10247,
executing statement<br>
'RELEASE s10247'<br>
svn: E200030: no such savepoint: s10247,
executing statement<br>
'ROLLBACK TO s10247'<br>
program finished with exit code 1<br>
------------------------------------------------------------<br>
<br>
After a Google search turned up several mentions of
conflicts between<br>
Windows shared drive and sqlite (see, for example,<br>
<a moz-do-not-send="true"
href="http://stackoverflow.com/questions/18782941/tortoisesvn-checkout-sqlite-disk-i-o-error-s10"
rel="noreferrer" target="_blank">http://stackoverflow.com/questions/18782941/tortoisesvn-checkout-sqlite-disk-i-o-error-s10</a>),<br>
I moved the buildslave files to a local drive within
the virtual<br>
machine, with the path
/home/buildbot/Documents/centos7-worker.<br>
<br>
At this point, I expect the log to have references
only to the new<br>
/home/buildbot location, with no more references to
the older<br>
/media/sf_G_DRIVE location. But instead, the log
still shows steps<br>
running "in dir
/media/sf_G_DRIVE/buildbot/centos7-worker/...". The
top<br>
of the log from the SVN checkout step shows an
example:<br>
<br>
------------------------------------------------------------<br>
svn --version<br>
in dir<br>
/media/sf_G_DRIVE/buildbot/centos7-worker/gfortran_centos7_build/build<br>
(timeout 1200 secs)<br>
watching logfiles {}<br>
argv: ['svn', '--version']<br>
environment:<br>
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ebvEqaI7D1,guid=b74561f6a34d14afe5191e515759b435<br>
DESKTOP_SESSION=gnome-classic<br>
DISPLAY=:0<br>
GDMSESSION=gnome-classic<br>
GDM_LANG=en_US.UTF-8<br>
GJS_DEBUG_OUTPUT=stderr<br>
GJS_DEBUG_TOPICS=JS ERROR;JS LOG<br>
GNOME_DESKTOP_SESSION_ID=this-is-deprecated<br>
GNOME_SHELL_SESSION_MODE=classic<br>
GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1<br>
HISTCONTROL=ignoredups<br>
HISTSIZE=1000<br>
HOME=/home/buildbot<br>
HOSTNAME=localhost.localdomain<br>
IMSETTINGS_INTEGRATE_DESKTOP=yes<br>
IMSETTINGS_MODULE=none<br>
LANG=en_US.UTF-8<br>
LESSOPEN=||/usr/bin/lesspipe.sh %s<br>
LOGNAME=buildbot<br>
LS_COLORS=rs=0:di=38;5;27:ln=38;5;51:mh=44;38;5;15:pi=40;38;5;11:so=38;5;13:do=38;5;5:bd=48;5;232;38;5;11:cd=48;5;232;38;5;3:or=48;5;232;38;5;9:mi=05;48;5;232;38;5;15:su=48;5;196;38;5;15:sg=48;5;11;38;5;16:ca=48;5;196;38;5;226:tw=48;5;10;38;5;16:ow=48;5;10;38;5;21:st=48;5;21;38;5;15:ex=38;5;34:*.tar=38;5;9:*.tgz=38;5;9:*.arc=38;5;9:*.arj=38;5;9:*.taz=38;5;9:*.lha=38;5;9:*.lz4=38;5;9:*.lzh=38;5;9:*.lzma=38;5;9:*.tlz=38;5;9:*.txz=38;5;9:*.tzo=38;5;9:*.t7z=38;5;9:*.zip=38;5;9:*.z=38;5;9:*.Z=38;5;9:*.dz=38;5;9:*.gz=38;5;9:*.lrz=38;5;9:*.lz=38;5;9:*.lzo=38;5;9:*.xz=38;5;9:*.bz2=38;5;9:*.bz=38;5;9:*.tbz=38;5;9:*.tbz2=38;5;9:*.tz=38;5;9:*.deb=38;5;9:*.rpm=38;5;9:*.jar=38;5;9:*.war=38;5;9:*.ear=38;5;9:*.sar=38;5;9:*.rar=38;5;9:*.alz=38;5;9:*.ace=38;5;9:*.zoo=38;5;9:*.cpio=38;5;9:*.7z=38;5;9:*.rz=38;5;9:*.cab=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.gif=38;5;13:*.bmp=38;5;13:*.pbm=38;5;13:*.pgm=38;5;13:*.ppm=38;5;13:*.tga=38;5;13:*.xbm=38;5;13:*.xpm=38;5;13:*.tif=38;5;13:*.tiff=38;5;13:*.png=38;<br>
5;13:*.svg=38;5;13:*.svgz=38;5;13:*.mng=38;5;13:*.pcx=38;5;13:*.mov=38;5;13:*.mpg=38;5;13:*.mpeg=38;5;13:*.m2v=38;5;13:*.mkv=38;5;13:*.webm=38;5;13:*.ogm=38;5;13:*.mp4=38;5;13:*.m4v=38;5;13:*.mp4v=38;5;13:*.vob=38;5;13:*.qt=38;5;13:*.nuv=38;5;13:*.wmv=38;5;13:*.asf=38;5;13:*.rm=38;5;13:*.rmvb=38;5;13:*.flc=38;5;13:*.avi=38;5;13:*.fli=38;5;13:*.flv=38;5;13:*.gl=38;5;13:*.dl=38;5;13:*.xcf=38;5;13:*.xwd=38;5;13:*.yuv=38;5;13:*.cgm=38;5;13:*.emf=38;5;13:*.axv=38;5;13:*.anx=38;5;13:*.ogv=38;5;13:*.ogx=38;5;13:*.aac=38;5;45:*.au=38;5;45:*.flac=38;5;45:*.mid=38;5;45:*.midi=38;5;45:*.mka=38;5;45:*.mp3=38;5;45:*.mpc=38;5;45:*.ogg=38;5;45:*.ra=38;5;45:*.wav=38;5;45:*.axa=38;5;45:*.oga=38;5;45:*.spx=38;5;45:*.xspf=38;5;45:<br>
MAIL=/var/spool/mail/buildbot<br>
OLDPWD=/home/buildbot<br>
PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/buildbot/.local/bin:/home/buildbot/bin<br>
PWD=/media/sf_G_DRIVE/buildbot/centos7-worker/gfortran_centos7_build/build<br>
QTDIR=/usr/lib64/qt-3.3<br>
QTINC=/usr/lib64/qt-3.3/include<br>
QTLIB=/usr/lib64/qt-3.3/lib<br>
QT_GRAPHICSSYSTEM_CHECKED=1<br>
QT_IM_MODULE=ibus<br>
<a moz-do-not-send="true"
href="mailto:SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/2119,unix/unix:/tmp/.ICE-unix/2119"
target="_blank">SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/2119,unix/unix:/tmp/.ICE-unix/2119</a><br>
SHELL=/bin/bash<br>
SHLVL=2<br>
SSH_AGENT_PID=2306<br>
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh<br>
TERM=xterm-256color<br>
USER=buildbot<br>
USERNAME=buildbot<br>
VTE_VERSION=3803<br>
WINDOWID=44049837<br>
WINDOWPATH=1<br>
XAUTHORITY=/run/gdm/auth-for-buildbot-xH6kQ3/database<br>
XDG_CURRENT_DESKTOP=GNOME-Classic:GNOME<br>
XDG_MENU_PREFIX=gnome-<br>
XDG_RUNTIME_DIR=/run/user/1000<br>
XDG_SEAT=seat0<br>
XDG_SESSION_DESKTOP=gnome-classic<br>
XDG_SESSION_ID=1<br>
XDG_VTNR=1<br>
XMODIFIERS=@im=ibus<br>
_=/usr/bin/buildslave<br>
using PTY: False<br>
svn, version 1.7.14 (r1542130)<br>
compiled Nov 20 2015, 19:25:09<br>
(subsequent lines omitted)...<br>
------------------------------------------------------------<br>
<br>
I've tried recreating the buildbot master and both
of its buildslaves<br>
(deleting the master folder and the buildslaves
folders, creating the<br>
buildbot and buildslaves, then restoring the
buildbot.tacs and<br>
master.cfg from backup). And I also unmounted the
/media/sf_G_DRIVE<br>
altogether. All of this seemed to purge the log as
expected, but the<br>
next build attempt still makes reference to the old
location of the<br>
CentOS buildslave in /media/sf_G_DRIVE drive.<br>
<br>
Where might the reference to this obsolete location
of the buildslave be<br>
stored? The centos7-worker's buildbot.tac file
contains no explicit<br>
reference to the obsolete location:<br>
------------------------------------------------------------<br>
<br>
import os<br>
<br>
from buildslave.bot import BuildSlave<br>
from twisted.application import service<br>
<br>
basedir = '.'<br>
rotateLength = 10000000<br>
maxRotatedFiles = 10<br>
<br>
# if this is a relocatable tac file, get the
directory containing the TAC<br>
if basedir == '.':<br>
import os.path<br>
basedir =
os.path.abspath(os.path.dirname(__file__))<br>
<br>
# note: this line is matched against to check
that this is a buildslave<br>
# directory; do not edit it.<br>
application = service.Application('buildslave')<br>
<br>
try:<br>
from twisted.python.logfile import LogFile<br>
from twisted.python.log import ILogObserver,
FileLogObserver<br>
logfile =
LogFile.fromFullPath(os.path.join(basedir,
"twistd.log"),<br>
rotateLength=rotateLength,<br>
maxRotatedFiles=maxRotatedFiles)<br>
application.setComponent(ILogObserver,
FileLogObserver(logfile).emit)<br>
except ImportError:<br>
# probably not yet twisted 8.2.0 and beyond,
can't set log yet<br>
pass<br>
<br>
buildmaster_host = 'kraken'<br>
port = 9989<br>
slavename = 'centos7-worker'<br>
passwd = 'pass'<br>
keepalive = 600<br>
usepty = 0<br>
umask = None<br>
maxdelay = 300<br>
allow_shutdown = None<br>
<br>
s = BuildSlave(buildmaster_host, port, slavename,
passwd, basedir,<br>
keepalive, usepty, umask=umask,
maxdelay=maxdelay,<br>
allow_shutdown=allow_shutdown)<br>
s.setServiceParent(application)<br>
<br>
<br>
Likewise, the master.cfg file creates a single SVN
checkout step as<br>
<br>
checkout = SVN(repourl = '<a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="svn://kraken/trunk/sf_code"><a class="moz-txt-link-freetext" href="svn://kraken/trunk/sf_code">svn://kraken/trunk/sf_code</a></a>',<br>
username = "buildbot",<br>
password = "buildbot",<br>
haltOnFailure = True,<br>
)<br>
------------------------------------------------------------<br>
<br>
and this step is used in all builders on both
buildslaves (the<br>
"centos7-worker" and the "win64-worker"), so I don't
see how it could<br>
convey the obsolete location to the buildslave.<br>
<br>
<br>
--<br>
Greg Bullock<br>
NorthWest Research Associates<br>
301 Webster St.<br>
Monterey, CA 93940<br>
(831) 582-4907<br>
<a moz-do-not-send="true"
href="mailto:greg@nwra.com" target="_blank">greg@nwra.com</a><br>
<br>
<br>
_______________________________________________<br>
users mailing list<br>
<a moz-do-not-send="true"
href="mailto:users@buildbot.net" target="_blank">users@buildbot.net</a><br>
<a moz-do-not-send="true"
href="https://lists.buildbot.net/mailman/listinfo/users"
rel="noreferrer" target="_blank">https://lists.buildbot.net/mailman/listinfo/users</a><br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
users mailing list
<a moz-do-not-send="true" href="mailto:users@buildbot.net" target="_blank">users@buildbot.net</a>
<a moz-do-not-send="true" href="https://lists.buildbot.net/mailman/listinfo/users" target="_blank">https://lists.buildbot.net/mailman/listinfo/users</a></pre>
</blockquote>
<br>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<pre cols="72">--
Regards.
Greg Bullock
NorthWest Research Associates
301 Webster St.
Monterey CA 93940
(831) 582-4907
<a moz-do-not-send="true" href="mailto:greg@nwra.com" target="_blank">greg@nwra.com</a></pre>
</div>
_______________________________________________<br>
users mailing list<br>
<a moz-do-not-send="true" href="mailto:users@buildbot.net"
target="_blank">users@buildbot.net</a><br>
<a moz-do-not-send="true"
href="https://lists.buildbot.net/mailman/listinfo/users"
rel="noreferrer" target="_blank">https://lists.buildbot.net/mailman/listinfo/users</a></blockquote>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Greg Bullock
NorthWest Research Associates
301 Webster St.
Monterey, CA 93940
(831) 582-4907
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:greg@nwra.com">greg@nwra.com</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:users@buildbot.net">users@buildbot.net</a>
<a class="moz-txt-link-freetext" href="https://lists.buildbot.net/mailman/listinfo/users">https://lists.buildbot.net/mailman/listinfo/users</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Greg Bullock
NorthWest Research Associates
301 Webster St.
Monterey, CA 93940
(831) 582-4907
<a class="moz-txt-link-abbreviated" href="mailto:greg@nwra.com">greg@nwra.com</a></pre>
</body>
</html>