Project

General

Profile

Actions

action #51374

closed

[functional][y] Soft failure for "Console messages writes over any tty" seems irrelevant in this case.

Added by JRivrain almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
Start date:
2019-05-10
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

The soft failure in this case seems to be no longer relevant for sle12sp5. I tried to reproduce the issue by doing as in comment 34 of the bug report, and by sending directly a message to dmesg (echo something > /dev/ksmsg), it does not seem trigger the bug.

That soft-failure should be removed where it does not apply anymore, and probably the bug could be closed now.
Some investigation may be necessary to find if some QAM tests still needs it.

yast2_ntpclient

Always latest result in this scenario: latest

Actions #1

Updated by JRivrain almost 5 years ago

  • Subject changed from [functional[y] Soft failure for "Console messages writes over any tty" seems irrelevant in this case. to [functional][y] Soft failure for "Console messages writes over any tty" seems irrelevant in this case.
Actions #2

Updated by JRivrain almost 5 years ago

Also not happening on leap 15.1.

Actions #3

Updated by riafarov almost 5 years ago

  • Assignee set to JRivrain
  • Target version set to future

I doubt that it's irrelevant. We just applied tons of workarounds. So in case you feel fancy, you could try following: remove workarounds, trigger 1000 runs and see if any of the issues appear.
As there is not much happening on the bug, we could have removed soft-failure, but then it's not clear why we set dmesg log level to lower value.

So, whenever you have a moment, please, take a look. As of now I don't see that as priority (lost my motivation as bug is 2 years old and I doubt that we have a solution for it.

Actions #4

Updated by JRivrain almost 5 years ago

  • Status changed from New to In Progress

1000 VRs and not even one failure related to this bug.
Scenarios tested ( 250 runs for each case ):
sle 12, console/snapper_cleanup.pm: http://waaa-amazing.suse.cz/tests/582#next_previous
sle 12, ncurses test suite: http://waaa-amazing.suse.cz/tests/583#next_previous
sle 15, ncurses test suite: http://waaa-amazing.suse.cz/tests/1325#next_previous
sle 15, console/snapper_cleanup.pm: http://waaa-amazing.suse.cz/tests/1085#next_previous

I will also do a bunch of VRs on other architectures, just to be sure.

Actions #5

Updated by JRivrain almost 5 years ago

  • Status changed from In Progress to Feedback
Actions #6

Updated by JRivrain almost 5 years ago

So, we found a case where this case was still happening: https://openqa.suse.de/tests/3039960#step/yast2_clone_system/7.
However,

  • This does not concern directly this PR, that test would have failed anyway regardless of my changes.
  • The problem with the code I removed, was that it was reporting the issue when it was not actually happening, but every time the tests were running.
  • bsc#1011815 cannot be reproduced anymore for x86_64, neither by 1000 openqa test runs, nor by writing something to kernel logs, nor by doing as in comment 34

My assumption is that it is fixed for x86_64, but not for aarch64.

Actions #7

Updated by JRivrain over 4 years ago

  • Status changed from Feedback to Closed

It looks like 3 months after the PR was merged, it did not cause trouble. The bug remains somehow valid however because it seems to still happen on aarch64.

Actions

Also available in: Atom PDF