[qam][sporadic][blue] test fails in evolution_prepare_servers - Race condition when typing password
Race condition when typing password.
I suggest to verify the typed string before sending 'ret'.
Fails since Build 195.1
in scenario sle-15-SP1-Installer-DVD-s390x-extra_tests_in_textmode@s390x-kvm-sle12
The test module was new added to this scenario, there is no expected result for zkvm.
Expected result from x86_64
Always latest result in this scenario: latest
#4 Updated by pcervinka almost 3 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...
#6 Updated by pcervinka almost 3 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.
#9 Updated by SLindoMansilla almost 3 years ago
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.
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)
type_password "password123"; wait_still_screen 1; send_key 'ret';
#11 Updated by SLindoMansilla almost 3 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. :)