Bug 519738 - tabled's %check can randomly fail
Summary: tabled's %check can randomly fail
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: tabled
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-27 15:48 UTC by Warren Togami
Modified: 2013-07-03 02:36 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-07-08 04:49:11 UTC


Attachments (Terms of Use)

Description Warren Togami 2009-08-27 15:48:48 UTC
tabled-0.3-4.fc12

http://koji.fedoraproject.org/koji/getfile?taskID=1638989&name=build.log
+ mkdir -p /builddir/build/BUILDROOT/tabled-0.3-4.fc12.x86_64/etc/rc.d/init.d
+ install -m 755 /builddir/build/SOURCES/tabled.init /builddir/build/BUILDROOT/tabled-0.3-4.fc12.x86_64/etc/rc.d/init.d/tabled
+ mkdir -p /builddir/build/BUILDROOT/tabled-0.3-4.fc12.x86_64/etc/sysconfig
+ install -m 644 /builddir/build/SOURCES/tabled.sysconf /builddir/build/BUILDROOT/tabled-0.3-4.fc12.x86_64/etc/sysconfig/tabled
+ find /builddir/build/BUILDROOT/tabled-0.3-4.fc12.x86_64 -name '*.la' -exec rm -f '{}' ';'
+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id /builddir/build/BUILD/tabled-0.3
extracting debug info from /builddir/build/BUILDROOT/tabled-0.3-4.fc12.x86_64/usr/lib64/libhttpstor.so.0.100.1
extracting debug info from /builddir/build/BUILDROOT/tabled-0.3-4.fc12.x86_64/usr/sbin/tabled
extracting debug info from /builddir/build/BUILDROOT/tabled-0.3-4.fc12.x86_64/usr/sbin/tdbadm
symlinked /usr/lib/debug/usr/lib64/libhttpstor.so.0.100.1.debug to /usr/lib/debug/usr/lib64/libhttpstor.so.0.debug
symlinked /usr/lib/debug/usr/lib64/libhttpstor.so.0.100.1.debug to /usr/lib/debug/usr/lib64/libhttpstor.so.debug
432 blocks
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-python-bytecompile
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.H4GTdw
+ umask 022
+ cd /builddir/build/BUILD
+ cd tabled-0.3
+ unset DISPLAY
+ make -s check
Making check in doc
Making check in lib
Making check in include
Making check in server
Making check in test
mkdir .libs
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o wait-for-listen wait-for-listen.o   
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/basic-bucket basic-bucket.o  ../lib/.libs/libhttpstor.so ../lib/libhttputil.a -lcurl -lglib-2.0 -lcrypto -lxml2 -lz -lm 
creating basic-bucket
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/basic-object basic-object.o  ../lib/.libs/libhttpstor.so ../lib/libhttputil.a -lcurl -lglib-2.0 -lcrypto -lxml2 -lz -lm 
creating basic-object
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o .libs/it-works it-works.o  ../lib/.libs/libhttpstor.so ../lib/libhttputil.a -lcurl -lglib-2.0 -lcrypto -lxml2 -lz -lm 
creating it-works
tdbadm: can't bind socket to listening address: Address already in use
tdbadm: dbenv->repmgr_start: Address already in use
test database not found.
FAIL: prep-db
chunkd[23086]: stat(2) cfgfile Path 'data/chunk' failed: No such file or directory
chunkd[23086]: error: no volume Path defined in cfg file

Is checking the right thing to do? It seems that it can clash randomly with something else running on the buildsystem and fail.

Comment 1 Jeff Garzik 2009-08-27 16:40:26 UTC
Yes, the tests use a hardcoded TCP port, which may already be in use by something else running on the build box.

Unfortunately, we _do_ need to run the tests -- they have definitely caught problems in the past.

Suggestions welcome...

Comment 2 Pete Zaitcev 2009-08-27 16:44:03 UTC
AF_UNIX maybe?

Comment 3 Pete Zaitcev 2009-08-27 16:46:28 UTC
Oh wait, scratch AF_UNIX. It's ouside of our control unless we write
the whole new transport for DB4. So, I guess a better option option
would be do disable replication entirely and use AF_UNIX between
the client and tabled, and tabled and chunkd & CLD. That's a lot
of work, because tabled is very high in feedchain.

Comment 4 Jeff Garzik 2009-08-27 16:56:47 UTC
I hoped to avoid AF_UNIX...  maybe the tests could figure out a bind port on their own, e.g.

1) bind to *
2) get local address (query port allocated to us by kernel)
3) record this port somewhere, for test clients to use

Comment 5 Pete Zaitcev 2009-08-27 18:02:17 UTC
Mucking with netstat is dumb. All we need is cld to write out cld.port
alongside cld.pid. The rest of ports can (and should) be fetched from
CLD. Both chunkd and tabled register with CLD. And then our own transport
would be safe. This means a bunch of code in every client that extracts
the service locations from CLD, but we need it in a library anyway.

This leaves the replication. I say again, disable it with an option
(for both CLD and tabled).

Comment 6 Bug Zapper 2009-11-16 11:46:17 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Pete Zaitcev 2009-12-08 05:31:56 UTC
I think we should be able to close it, now that random port is in.
Of course the voting port is still in conflict but we should not see
any fallout from that.


Note You need to log in before you can comment on or make changes to this bug.