action #120429
closed
- Subject changed from test fails in logs_from_installation_system - command 'ping -c 1 worker2.oqa.suse.de' timed out to Increase timeout when checking if YaST logs can be uploaded
- Description updated (diff)
- Priority changed from Normal to High
- Target version set to Current
- Description updated (diff)
I suspect /dev/ttysclp0 is still work or not.
- Tags deleted (
qe-yast-refinement)
- Status changed from New to Workable
- Status changed from Workable to In Progress
- Assignee set to geor
- Parent task set to #121876
PR closed.
After various iteration we can concur that increasing the timeout does not resolve the issue.
The culprit for the occasional failure here is script_run, which does not always capture the return code from the ping command. It can happen that ping has returned successfully in the first 10 seconds, but script_run will time out in 60 seconds (or whichever timeout value it had).
A new approach is needed here, that will address the sporadic inability of script_run's underlying functionality to get ping's return code.
As discussed in the daily we will not create a new ticket to avoid creating clutter, but will work on the new issue that has arisen in this ticket.
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: offline_sles12sp4_ltss_pscc_sdk_all_full
https://openqa.suse.de/tests/10219982#step/logs_from_installation_system/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
So, it turns out that this is not related to the ping command, but rather, there are cases where the return code of a shell command is not captured by openqa.
For instance, here we can see that an assert_script_run("ls") command has timed out, despite the fact that the ls command has successfully returned.
This issue, where the return code of a shell command is not captured, appears only sporadically and is not easy to debug given it's nature.
- Status changed from In Progress to Closed
- Status changed from Closed to Feedback
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: offline_sles12sp5_pscc_sdk-asmm-contm-lgm-tcm-wsm-pcm_all_full
https://openqa.suse.de/tests/10256078#step/logs_from_installation_system/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
- Status changed from Feedback to Resolved
- Status changed from Resolved to Feedback
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: offline_sles12sp5_media_sdk-asmm-contm-lgm-tcm-wsm-pcm_all_full
https://openqa.suse.de/tests/10448596#step/logs_from_installation_system/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF