action #18972
closed[functional][sles] test fails in apache_nss because of missing keys
0%
Description
Observation¶
openQA test in scenario sle-12-SP3-Server-DVD-x86_64-textmode+xen_server_role@64bit fails in
apache_nss
The reason for that is that openqa fails to type "/dev/ttyS0" and instead types "/d/ttyS0".
It also fails to type in the correct IP in this case: https://openqa.suse.de/tests/916958#step/zypper_lifecycle/84
Both of these test ran on openqaworker5 almost simultaneously so a high worker load is very likely:
apache_nss module:
Result: failed finished about 14 hours ago ( 32:53 minutes )
Assigned worker: openqaworker5:11
zypper_livecycle module:
Result: failed finished about 14 hours ago ( 01:07 hours )
Assigned worker: openqaworker5:12
Here is a short excerpt from IRC for further reference:
11:40:27 nsinger | do we sill have problems with missing keys? http://openqa.suse.de/tests/917191#step/apache_nss/36
11:55:03 okurz | nsinger: short answer: The generic "missing keys" issue is resolved. If you find "missing keys" then we assume it is specific to scenarios or machines or product regressions so not the generic one. I am wondering about why this test executes zypper_up in between and other modules which don't sound very familiar to me. Also, the post_fail_hook unfortunately does not upload /proc/loadavg which could tell about if we have high load on the system.
11:57:29 okurz | nsinger: force_cron_run should ensure the system is unloaded for all modules that come afterwards but in this scenario quite some steps are executed which can cause higher background load again. The machine is nothing special so I assume it is either a product regression or sporadic issue that was already present in before causing the system to be unresponsive during the typing and would need another force_cron_run just in before which would be not so nice
Reproducible¶
As already mentioned by okurz this issue is most likely a sporadic one and not "apache_nss" related.
Expected result¶
OpenQA is able to type "/dev/ttyS0".
Last good: 0365 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by okurz over 6 years ago
- Status changed from New to Resolved
Since this ticket has been reported we introduced changes to make the backend more robustly typing as well as introduce the test module "force_cron_run" so I assume we are done here.