Project

General

Profile

action #49655

[qam][sporadic][blue] test fails in evolution_prepare_servers - Race condition when typing password

Added by SLindoMansilla over 2 years ago. Updated over 2 years ago.

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

0%

Estimated time:
Difficulty:

Description

Observation

Race condition when typing password.
I suggest to verify the typed string before sending 'ret'.

Reproducible

Fails since Build 195.1
in scenario sle-15-SP1-Installer-DVD-s390x-extra_tests_in_textmode@s390x-kvm-sle12

Expected result

The test module was new added to this scenario, there is no expected result for zkvm.
Expected result from x86_64

Further details

Always latest result in this scenario: latest


Related issues

Related to openQA Tests - action #50045: [qam][blue][sle] - Fix type_password to accept parameters and pass them to the inner call type_stringResolved2019-04-05

History

#1 Updated by SLindoMansilla over 2 years ago

Hi pcervinka,

I think that you are the best match for this module, since you are the maintainer. Could you take a look?

#2 Updated by SLindoMansilla over 2 years ago

  • Description updated (diff)

#3 Updated by pcervinka over 2 years ago

  • Subject changed from [qam][sporadic] test fails in evolution_prepare_servers - Race condition when typing password to [qam][sporadic][blue] test fails in evolution_prepare_servers - Race condition when typing password

#4 Updated by pcervinka over 2 years ago

What about to replace unstable type_password/send_key by useradd with "-p" option encrypted password?

useradd -m admin -p "\$6\$rGdJDHZcEVzNZlYh\$562QygizKzPZ4oqH/iheaOZR3HoX2CPLnRdOKZRaxLdkvEIECMWM.2ZH1uUtp9kwjBHLf5YLdaqpzi.Y3g90.."

This could save several lines there...

#5 Updated by pcervinka over 2 years ago

  • Status changed from New to In Progress

#6 Updated by pcervinka over 2 years ago

I was trying to reproduce issue with incorrectly typed password under heavy load, but couldn't. I don't think that type_password issue should be workaround-ed in the test, as it is not test issue. So far I see migration from console to virtio as better solution, zkvm doesn't have support yet.

There is already WIP to bring virtio to zkvm backend and it looks to be merged "soon" https://progress.opensuse.org/issues/45863. I prefer to wait for it and when it is ready, migrate test from console to virtio.

#7 Updated by pcervinka over 2 years ago

  • Blocked by action #45863: [s390x][svirt][ltp] Fix serial terminal console implementation for svirt backend and use it's output added

#8 Updated by pcervinka over 2 years ago

  • Status changed from In Progress to Blocked

#9 Updated by SLindoMansilla over 2 years ago

Hi pcervinka,

While virtio is a good improvement, the current behavior is buggy. It is not a workaround, it is about how the line discipline layer works. Typed string needs an echo to the terminal, which means that the string sent has a longer travel than the send_key, which takes a more direct path.

https://en.wikipedia.org/wiki/Line_discipline

This was ok for humans using serial console since they weren't able to hit enter faster than the computer time needed to echoes the command back.

Your code is open to race conditions unless you check for the echo before sending the key.

My proposal is to never send a key without a proper synchronization point (that is, you are sure in which state the SUT is before sending it)

For example:

type_password "password123";
wait_still_screen 1;
send_key 'ret';

PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/7203

#10 Updated by pcervinka over 2 years ago

That sounds pretty much like workaround, but it makes sense as you say. So if you want, we can merge your PR, but I will open new open one for migration to virtio, ok ?

#11 Updated by SLindoMansilla over 2 years ago

"A workaround is a bypass of a known problem and is a temporary fix that implies that a solution to the problem is needed."

In this case we are not talking about bypassing a problem, but about using the system properly. It is the same as using assert_screen before sending the key. That's not a workaround, that is a synchronization point. When it works it is just luck.

Sure, you can create a new one or keep this ticket. I am not worried about closing this ticket but about avoiding more failed jobs. If we merge my PR I will be fine. :)

#12 Updated by pcervinka over 2 years ago

Why not to put wait_still_screen 1; into type_password directly? Like in http://open.qa/api/testapi/#_type_string.

#13 Updated by SLindoMansilla over 2 years ago

Yes, that would actually be the ideal way.
But, I didn't wanted to spend too much time.

Feel free to fix type_password to accept parameters and pass them to the inner call type_string.

Thanks for reviewing!

#14 Updated by pcervinka over 2 years ago

  • Blocked by deleted (action #45863: [s390x][svirt][ltp] Fix serial terminal console implementation for svirt backend and use it's output)

#15 Updated by pcervinka over 2 years ago

  • Related to action #50045: [qam][blue][sle] - Fix type_password to accept parameters and pass them to the inner call type_string added

#16 Updated by pcervinka over 2 years ago

  • Status changed from Blocked to Resolved

Also available in: Atom PDF