#2290 closed defect (fixed)
allmydata.test.test_util.FileUtil.test_disk_stats sometimes fails on Travis
| Reported by: | daira | Owned by: | Brian Warner <warner@…> |
|---|---|---|---|
| Priority: | normal | Milestone: | undecided |
| Component: | code | Version: | 1.10.0 |
| Keywords: | tests travis | Cc: | |
| Launchpad Bug: |
Description
https://travis-ci.org/travis-tahoe/tahoe-lafs/jobs/34190813
[FAIL] Traceback (most recent call last): File "/home/travis/build/travis-tahoe/tahoe-lafs/src/allmydata/test/test_util.py", line 522, in test_disk_stats self.failUnless(disk['used'] > 0, disk['used']) File "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/twisted/trial/_synctest.py", line 308, in assertTrue raise self.failureException(msg) twisted.trial.unittest.FailTest: 0 allmydata.test.test_util.FileUtil.test_disk_stats
I don't understand why this failed on Python 2.6.9 but succeeded (https://travis-ci.org/travis-tahoe/tahoe-lafs/jobs/34190811) on the Python 2.7.8 run of the same build. Also, a previous build with identical source (https://travis-ci.org/travis-tahoe/tahoe-lafs/jobs/34187776) passed on Python 2.6.9.
(Travis isn't enabled yet for the main repo, but this is an identical test repo.)
Change History (15)
comment:1 Changed at 2014-09-12T16:11:51Z by warner
comment:2 Changed at 2014-09-12T19:50:35Z by warner
#2298 was a dup.
After some more investigation, it appears that Travis-CI workers sometimes report fake-looking os.statvfs() values. I've filed an issue to investigate:
On the job that failed, every single os.statvfs() call for the whole 20-minute test suite claimed that the 20 GiB disk was empty (f_bfree == f_blocks). On passing jobs, f_blocks reported a 120 GiB disk (or larger) and the number of free blocks rose and fell over the course of the test run.
My hunch is that some of the travis workers are using a virtual disk that happens to return bogus or simulated data to os.statvfs(). Daira and I decided that it'd be ok to relax this test (to accept disk["used"] >= 0). If the Travis folks find an easy solution, we can tighten the test back up again.
comment:3 Changed at 2014-09-12T20:00:29Z by Brian Warner <warner@…>
- Owner set to Brian Warner <warner@…>
- Resolution set to fixed
- Status changed from new to closed
I caught an instance of this with extra debug prints turned on, to dump the return value from statvfs
https://travis-ci.org/tahoe-lafs/tahoe-lafs/jobs/35096649
allmydata.test.test_util.FileUtil.test_disk_stats ... STATVFS posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=5242880, f_bfree=5242880, f_bavail=5242880, f_files=2621440, f_ffree=2621439, f_favail=2621439, f_flag=4096, f_namemax=255) STATVFS posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=5242880, f_bfree=5242880, f_bavail=5242880, f_files=2621440, f_ffree=2621439, f_favail=2621439, f_flag=4096, f_namemax=255) GET_DISK_STATS {'free_for_root': 21474836480, 'avail': 21474828288, 'free_for_nonroot': 21474836480, 'total': 21474836480, 'used': 0} Traceback (most recent call last): File "/home/travis/build/tahoe-lafs/tahoe-lafs/src/allmydata/test/test_util.py", line 523, in test_disk_stats self.failUnless(disk['used'] > 0, disk['used']) File "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/twisted/trial/_synctest.py", line 308, in assertTrue raise self.failureException(msg) twisted.trial.unittest.FailTest: 0 [FAILURE]From what I can tell, every call to the os.statvfs in get_disk_stats() in this particular run returned the same thing.
In the passing test runs, os.statvfs() returns varying values.