Project

General

Profile

Actions

action #115754

closed

[security] test fails in syscall_thrasher

Added by punkioudi over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
-
Start date:
2022-08-25
Due date:
% Done:

100%

Estimated time:
Difficulty:

Description

# Test died: command './thrash' timed out
It happens in 2 architectures: x86_64, s390x

Acceptance criteria

  1. Identify if it is a product bug or this should not be in the test list (?)
  2. If it is a bug, open a bugzilla ticket under SUSE Linux Enterprise Server 15 SP5
  3. If it is a test issue (it could be also checked if the timeout of this command can be increased), adjust the test accordingly and run Verification runs.

Observation

openQA test in scenario sle-15-SP5-Online-x86_64-cc_atsec@64bit fails in
syscall_thrasher

Test suite description

Testsuite maintained at https://gitlab.suse.de/qa-maintenance/qam-openqa-yml.

Reproducible

Fails since (at least) Build 15.2 (current job)

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by punkioudi over 1 year ago

  • Description updated (diff)
Actions #2

Updated by punkioudi over 1 year ago

  • Description updated (diff)
Actions #3

Updated by pstivanin over 1 year ago

  • Status changed from New to In Progress
  • Assignee set to pstivanin
Actions #4

Updated by pstivanin over 1 year ago

  • % Done changed from 0 to 20

I can't reproduce this issue locally using the qcow2 image from https://openqa.suse.de/tests/9392698#settings .
I'm now trying on 15-SP4 to see if the issue is also there. Weirdly enough, it's not failing on x86_64, but it is failing on x86_64-uefi.

Actions #5

Updated by pstivanin over 1 year ago

  • % Done changed from 20 to 80

So the test is passing on both 15sp4 (https://openqa.suse.de/tests/9405564) and 15sp5 (https://openqa.suse.de/tests/9405747).
The failure seems to be related to load/network, since locally (with the same qcow2 and cpu/ram amount) I was never able to reproduce it.

Actions #6

Updated by pstivanin over 1 year ago

  • % Done changed from 80 to 100
Actions #7

Updated by pstivanin over 1 year ago

  • % Done changed from 100 to 90

We've decided to first try with allocating more resources, and see if this helps. I've therefore set QEMUCPUS: 4 and QEMURAM: 4096 in the Security jobgroup.
If this won't help, we'll go with the retry workaround.

Actions #8

Updated by pstivanin over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

seems to be stable for now, closing the ticket.

Actions #9

Updated by pstivanin over 1 year ago

  • Status changed from Resolved to In Progress
  • % Done changed from 100 to 80

Reopening since it's happening again.

Actions #11

Updated by pstivanin over 1 year ago

  • % Done changed from 80 to 100

The test is green so far. Let's keep this open for a few days and see how things will go both in devel and maint.

Actions #12

Updated by pstivanin over 1 year ago

  • Status changed from In Progress to Resolved

closing the ticket since the test has been stable.

Actions

Also available in: Atom PDF