action #35688
closedcoordination #35302: [qe-core][opensuse][functional][epic][sporadic] Various unstable tests on o3
[opensuse][functional][u][sporadic][bsc#1091353][medium] Various unstable tests on o3 - inkscape
0%
Description
Observation¶
- NET/ZDUP42.2-gnome:inkscape: https://openqa.opensuse.org/tests/658802#step/inkscape/13
Problem¶
okurz: regarding "inkscape failing" I can always find the same symptoms, pkcon can not find the package but apparently a retrigger helps. I would consider that a product bug but we should help with investigation and workaround. E.g. in https://openqa.opensuse.org/tests/662319#step/inkscape/12
[30 Apr 2018 11:02:46] <DimStar> okurz: surprisingly this does not match PK's own log file, where in that same test it can find inkscape:
[30 Apr 2018 11:02:50] <DimStar> 2018-04-24 18:18:44 <1> susetest(2205) [packagekit] pk-backend-zypp.cpp(backend_resolve_thread):2825 inkscape ~installed;newest;arch;~source
[30 Apr 2018 11:02:52] <DimStar> 2018-04-24 18:18:44 <1> susetest(2205) [packagekit] pk-backend-zypp.cpp(backend_resolve_thread):2853 found (581)inkscape-0.92.2-6.2.x86_64(@System)
[30 Apr 2018 11:03:36] <DimStar> […] y2logs_clone contains it
Suggestions¶
might be also interesting to find log files in 'success case' (preferably of a direct rerun where it succeeded)
Updated by okurz almost 6 years ago
- Subject changed from [opensuse][functional][u][sporadic] Various unstable tests on o3 - inkscape to [opensuse][functional][u][sporadic][bsc#1091353] Various unstable tests on o3 - inkscape
- Status changed from In Progress to Blocked
First, I found that one process died with a core dump and reported this is a bug although I assume it's not directly related: https://bugzilla.opensuse.org/show_bug.cgi?id=1091349
I compared both pk_backend_zypp logfiles from a "bad" as well as "good" case and could find obvious differences but I did not investigate further in detail. https://bugzilla.opensuse.org/show_bug.cgi?id=1091353 reported. For now waiting for feedback in bug. Maybe someone has an idea.
If not, what we can try to do here now is to apply a workaround. I suggest to conduct the following steps:
- Reproduce locally consistently
- Crosscheck if the same can happen in clean installation systems or only the upgrade scenarios
- Reduce number of modules executed to simplify scenario
- Restart even more? Wait longer in between? Restart computer?
Updated by okurz almost 6 years ago
- Related to action #19428: [opensuse][functional][u][sporadic][medium] test fails in inkscape, pkcon xterm window does not close on "alt-f4" added
Updated by okurz almost 6 years ago
- Related to action #30805: [functional][opensuse][leap][medium][u] first test after reboot fails in krunner, potential system overload (was: test fails in inkscape - typing too fast?) added
Updated by mgriessmeier almost 6 years ago
- Due date changed from 2018-05-22 to 2018-06-05
Updated by mgriessmeier almost 6 years ago
can you clarify why exactly this is blocked?
it's not clear to me
Updated by okurz almost 6 years ago
- Due date changed from 2018-06-05 to 2018-07-03
- Status changed from Blocked to Workable
- Assignee deleted (
okurz) - Target version changed from Milestone 16 to Milestone 17
I set it to be blocked by the bug mentioned in the subject line but the "gnome team" is apparently not very keen to pick it up so we should make sure that the inkscape test is stable regardless of this bug, i.e. even if that shows, keep the test stable, e.g. by reverting to zypper or whatever.
Updated by okurz almost 6 years ago
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5193 did that.
Now we can check statistics further and ensure that the inkscape module will be stable.
Updated by okurz almost 6 years ago
- Target version changed from Milestone 17 to Milestone 17
Updated by riafarov almost 6 years ago
- Subject changed from [opensuse][functional][u][sporadic][bsc#1091353] Various unstable tests on o3 - inkscape to [opensuse][functional][u][sporadic][bsc#1091353][medium] Various unstable tests on o3 - inkscape
Updated by zluo almost 6 years ago
- Status changed from Workable to In Progress
- Assignee set to zluo
take over
Updated by zluo almost 6 years ago
- Status changed from In Progress to Feedback
after long time investigation I found this is related more to worker performance than to test module itself or there is small regression issue of product.
tested on loewe and my remote worker.
test runs have failed mostly at installation stage "await_install" or "first_boot".
send_key_until_needlematch 'generic-desktop', "alt-f4", 5, 5;
Changes above can reduces failures on 3o, but it doesn't solve this problem really. We need a better resolution.
Set it as feedback for now.
Updated by okurz almost 6 years ago
- Due date changed from 2018-07-03 to 2018-07-31
- Status changed from Feedback to Blocked
- Target version changed from Milestone 17 to Milestone 18
I have the suspicion that most if not all unstable test modules fail due background maintenance tasks which are triggered during random time when test modules are executed so we should do #31351 first.
Updated by okurz almost 6 years ago
- Status changed from Blocked to Resolved
- Assignee changed from zluo to okurz