Project

General

Profile

Actions

action #43616

closed

[functional][u][sporadic] test fails in shutdown - SUT took longer than 60 seconds to shutdown, no logs available (non-s390x)

Added by szarate about 6 years ago. Updated over 5 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA (private) - Milestone 24
Start date:
2018-11-09
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario sle-15-SP1-Installer-DVD-x86_64-create_hdd_minimal_base+sdk@64bit-smp fails in
shutdown

The main observation is that the SUT simply doesn't shutdown, however there are no logs on what prevented it from shutting down... Which makes difficult further bug investigation

Reproducible

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

Expected result

System shutsdown properly, if not logs are collected (if possible) before finishing the test.

Suggestions

  • Change power_action in lib/power_action_utils.pm to be more generic (i.e, not check what desktop are we using.
  • Ensure that post_fail_hook always calls the collect logs function

Related issues 1 (0 open1 closed)

Related to openQA Tests (public) - action #43880: [functional][u][s390x][sporadic] test fails in shutdown on s390xResolvedzluo2018-11-16

Actions
Actions #1

Updated by szarate about 6 years ago

  • Description updated (diff)
Actions #2

Updated by szarate about 6 years ago

Actions #3

Updated by okurz about 6 years ago

  • Target version set to Milestone 22
Actions #4

Updated by szarate about 6 years ago

@okurz, do you mind if we move this to milestone 21 and pick it up soonish? A serial failure should be more than enough to detect the machine didn't shut down. saving us the pain :)

Actions #5

Updated by okurz about 6 years ago

Sure, if you are motivated :) So if the serial failure detection can help understanding the issue then go ahead, pick it up, set M21.

Actions #6

Updated by okurz about 6 years ago

  • Related to action #43880: [functional][u][s390x][sporadic] test fails in shutdown on s390x added
Actions #7

Updated by zluo almost 6 years ago

I think this is a duplicated ticket of #43880.

Actions #8

Updated by okurz almost 6 years ago

  • Target version changed from Milestone 22 to Milestone 24
Actions #9

Updated by szarate almost 6 years ago

  • Status changed from New to Workable
Actions #10

Updated by okurz almost 6 years ago

  • Subject changed from [functional][u] test fails in shutdown - SUT took longer than 60 seconds to shutdown, no logs available to [functional][u] test fails in shutdown - SUT took longer than 60 seconds to shutdown, no logs available (non-s390x)
  • Status changed from Workable to Blocked
  • Assignee set to zluo

Not a duplicate of #43880 which is about s390x.

@zluo please track this ticket as blocked until #43880 is resolved.

Actions #11

Updated by zluo over 5 years ago

  • Status changed from Blocked to In Progress

since the issue reported in #43880 got fixed, set this as In Progress for further investigation.

Actions #13

Updated by zluo over 5 years ago

I can reproduce on overloaded remote workers only: http://f40.suse.de/tests/2916#step/shutdown/3

This is a sporadic issue however, and post_fail_hook doesn't have a chance to get log-console to execute systemctl 'list-jobs'.
cleanup_before_shutdown collects already some logs, but for performance issue there is no way to detect.

what we can do is to increase timeout from 60 to 120. Compare with s390 scenarios(600) this is okay, if we cannot avoid performance issue on osd.

Actions #14

Updated by zluo over 5 years ago

  • Subject changed from [functional][u] test fails in shutdown - SUT took longer than 60 seconds to shutdown, no logs available (non-s390x) to [functional][u][sporadic] test fails in shutdown - SUT took longer than 60 seconds to shutdown, no logs available (non-s390x)
Actions #15

Updated by zluo over 5 years ago

  • Status changed from In Progress to Rejected

https://openqa.suse.de/tests/2742528#next_previous shows that we don't have this issue since at least 2 months, and this happened only one time 5 months ago. reject this.

Actions #16

Updated by zluo over 5 years ago

we can re-open this ticket if it happens again. an option could be to increase timeout to 120, but at moment I don't the need to do so.

Actions

Also available in: Atom PDF