Project

General

Profile

action #115754

[security] test fails in syscall_thrasher

Added by punkioudi 5 months ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
pstivanin
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

History

#1 Updated by punkioudi 5 months ago

  • Description updated (diff)

#2 Updated by punkioudi 5 months ago

  • Description updated (diff)

#3 Updated by pstivanin 5 months ago

  • Status changed from New to In Progress
  • Assignee set to pstivanin

#4 Updated by pstivanin 5 months 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.

#5 Updated by pstivanin 5 months 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.

#6 Updated by pstivanin 5 months ago

  • % Done changed from 80 to 100

#7 Updated by pstivanin 5 months 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.

#8 Updated by pstivanin 5 months ago

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

seems to be stable for now, closing the ticket.

#9 Updated by pstivanin 4 months ago

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

Reopening since it's happening again.

#11 Updated by pstivanin 4 months 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.

#12 Updated by pstivanin 4 months ago

  • Status changed from In Progress to Resolved

closing the ticket since the test has been stable.

Also available in: Atom PDF