Test executed twice instead of executing the next test #2997
Comments
|
Attaching tmt debug output and archive of the run: |
|
Note: "provision -h connect" is much more likely to hit the issue. |
|
Sounds like an important one, let's try to squeeze this into |
psss
changed the title
psss
added
the
priority | must
|
Just a hunch, but could it be that the content of |
|
Hmm, I'm unable to reproduce this behavior :( BTW
Could be, also |
|
I've added |
|
So to be on safer side we should have unique names for tmt-test-wrapper.sh-default-0-default-0, right? |
|
Yeah, I can do that, I'm just curious why it's happening. I can't reproduce it, you obviously can, easily, so where's the problem :) Some mount option, some fsync setting? |
To prevent accidental reuse of the wrapper, reported in #2997, and improve investigation by saving all wrappers, make the test shell wrapper filename even more unique that it already was. Besides the phase and guest names, include also test name and its serial number. That should make the filename unlike any other filename created for other tests. See #2997
|
So here's my proposal, #2998 Still, I can't reproduce the issue, so I have no idea how to trigger the error and test the fix. The filename is now unique, let me know whether it would help - or trigger |
|
This looks like the file was not modified on the guest, right? |
|
Ah, rsync has 'checksum' as "optional" decision factor to update files... |
|
WIth |
|
:)) Anyway, we want both, right? More unique wrapper filenames and |
I'm not sure how often |
|
Hm, manpage hints it is XOR |
|
So, should we include both? The #2998 fixes the problem. Based on manpage we can have rsync do either 'quick check' or 'checksum', I originally thought it checksum will be just 'make sure quick check was correct' but it replaces the check completely. |
|
With the patch, we shouldn't hit the problem when a filename changes its content, therefore the need for checksum would diminish. Maybe we could add an envvar for additional rsync options, expose it in TF and see whether it increases testing times by hours or not, and decide WRT checksum after that. |
To prevent accidental reuse of the wrapper, reported in #2997, and improve investigation by saving all wrappers, make the test shell wrapper filename even more unique that it already was. Besides the phase and guest names, include also test name and its serial number. That should make the filename unlike any other filename created for other tests. See #2997
I think this would be probably the safest way. I'm afraid that we can expect some significant slow down when the |
To prevent accidental reuse of the wrapper, reported in #2997, and improve investigation by saving all wrappers, make the test shell wrapper filename even more unique that it already was. Besides the phase and guest names, include also test name and its serial number. That should make the filename unlike any other filename created for other tests. See #2997
To prevent accidental reuse of the wrapper, reported in #2997, and improve investigation by saving all wrappers, make the test shell wrapper filename even more unique that it already was. Besides the phase and guest names, include also test name and its serial number. That should make the filename unlike any other filename created for other tests. See #2997
To prevent accidental reuse of the wrapper, reported in #2997, and improve investigation by saving all wrappers, make the test shell wrapper filename even more unique that it already was. Besides the phase and guest names, include also test name and its serial number. That should make the filename unlike any other filename created for other tests. See #2997
To prevent accidental reuse of the wrapper, reported in teemtee#2997, and improve investigation by saving all wrappers, make the test shell wrapper filename even more unique that it already was. Besides the phase and guest names, include also test name and its serial number. That should make the filename unlike any other filename created for other tests. See teemtee#2997
I've executed following test plan using TMT: https:/pholica/tmt_testrepo/blob/6087865da91737f8bf9c9ff2d2f19da1311f6cac/plans/example.fmf
from repo: https:/pholica/tmt_testrepo/tree/6087865da91737f8bf9c9ff2d2f19da1311f6cac
During the execution, I hit a situation when the
01_log_plan_datawas actually executed twice, second time as if it was02_log_test_data. See the result of03_list_rootand output from02_log_test_data.I'm not hitting this behavior consistently, but rather randomly but quite frequently.
The text was updated successfully, but these errors were encountered: