View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001797 | GNUnet | file-sharing service | public | 2011-09-19 16:16 | 2011-10-31 12:00 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | minor | Reproducibility | random |
| Status | closed | Resolution | fixed | ||
| Summary | 0001797: fs test 'test_gnunet_fs_idx.py' fails on some buildbots with odd timeout | ||||
| Description | The error message produced is: PASS: test_gnunet_fs_rec.py Sep 19 08:02:02-828697 transport-13491 WARNING `stat' failed on file `/tmp/gnunet-test-fs-py-rec/.hostkey' at crypto_rsa.c:670 with error: No such file or directory Sep 19 08:02:02-829252 transport-13491 ERROR Transport service could not access hostkey. Exiting. command timed out: 1200 seconds without output, killing pid 9845 process killed by signal 9 program finished with exit code -1 elapsedTime=1679.565651 Since 'test_gnunet_fs_rec.py' is before 'test_gnunet_fs_idx.py', this would indicate that the idx test is what is failing. | ||||
| Tags | No tags attached. | ||||
|
|
In these situations, gnunet-publish is hanging waiting for the gnunet*-services. However, despite the script launching "gnunet-arm -s", no such services are (anymore?) running when the problem arises. gnunet-publish has not made any progress at the time this happens. |
|
|
First analysis of what (I think) happened is that the gnunet-arm timeout for '-e' was too short (just 1s). As a result, gnunet-arm from the PREVIOUS test terminated *before* gnunet-service-arm was done with the shutdown. The failing idx.py-test then runs 'gnunet-arm -s' which finds that gnunet-service-arm is *still* running (by 'bind' failure-test!). So gnunet-arm -s just does nothing and quits. Then the gnunet-service-arm from the PREVIOUS test quits. Then gnunet-publish starts and finds it is all alone. Increasing the timeout for gnunet-arm -e to 15s should fix this for virtually all systems. That change is now in; however, if I run the ns.py and idx.py tests in succession, the problem seems to be still there (ugh). |
|
|
Interesting. This fails (on efikamx): ./test_gnunet_fs_ns.py && ./test_gnunet_fs_idx.py && echo ok where as this succeeds: gnunet-arm -s -c test_gnunet_fs_ns_data.conf && gnunet-arm -e -c test_gnunet_fs_ns_data.conf && ./test_gnunet_fs_idx.py && echo ok |
|
|
I also get: Oct 20 12:50:58-610070 util-13409 WARNING `stat' failed on file `/tmp/gnunet-test-fs-py-idx/.hostkey' at crypto_rsa.c:684 with error: No such file or directory Oct 20 12:50:58-610627 transport-13409 ERROR Transport service could not access hostkey. Exiting. This is odd, as by the time that the .py-script cleans up /tmp, *all* GNUnet processes should have terminated. |
|
|
Seems to be fixed now with the increased ARM timeouts. Not sure why it didn't seem to be fixed at first, but at least now all buildbots show green on fs. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-09-19 16:16 | Christian Grothoff | New Issue | |
| 2011-09-19 16:16 | Christian Grothoff | Status | new => assigned |
| 2011-09-19 16:16 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2011-09-19 16:16 | Christian Grothoff | Category | other => file-sharing service |
| 2011-09-19 16:19 | Christian Grothoff | Priority | normal => high |
| 2011-10-20 19:17 | Christian Grothoff | Note Added: 0004712 | |
| 2011-10-20 19:47 | Christian Grothoff | Note Added: 0004713 | |
| 2011-10-20 19:49 | Christian Grothoff | Note Added: 0004714 | |
| 2011-10-20 19:53 | Christian Grothoff | Note Added: 0004715 | |
| 2011-10-21 11:45 | Christian Grothoff | Note Added: 0004719 | |
| 2011-10-21 11:45 | Christian Grothoff | Status | assigned => resolved |
| 2011-10-21 11:45 | Christian Grothoff | Fixed in Version | => 0.9.0pre4 |
| 2011-10-21 11:45 | Christian Grothoff | Resolution | open => fixed |
| 2011-10-31 12:00 | Christian Grothoff | Status | resolved => closed |
