A progress.opensuse.org issues has been created, check poo# 119812.
After prepared the LTP test python runner as in poo#116668, the scheduled runltp-python tests in public cloud-Development group 447 started, but some tests initially failed all for the same issue and were restarted 3 times before to pass, so 2 tests failed and last one passed, in 2 different builds.
# wait_serial expected: qr/wKYTI-\d+-/u
# Result:
Host information
System: Linux
Node: install
Kernel Release: 5.3.18-150300.59.98-default
Kernel Version: #1 SMP Thu Oct 13 08:52:00 UTC 2022 (dfcde7e)
Machine Architecture: x86_64
Processor: x86_64
Temporary directory: /tmp/runltp.root/tmpkhgmmrz6
Connecting to SUT: ssh
Error: Can't read return code from reply '\n'
Traceback (most recent call last):
File "runltp-ng/ltp/session.py", line 278, in run_single
sut_config)
File "runltp-ng/ltp/session.py", line 172, in _start_sut
iobuffer=Printer(sut, False))
File "runltp-ng/ltp/ssh.py", line 309, in communicate
iobuffer=iobuffer)
File "runltp-ng/ltp/ssh.py", line 465, in run_command
f"Can't read return code from reply {repr(reply)}")
ltp.sut.SUTError: Can't read return code from reply '\n'
wKYTI-1-
That same error was already noted in the past and initially, it was resolved with a patch in the ssh module, adding a sleep time, but it re-occurred now and is not deterministic, test reruns sometime pass: probably related to some sync timing.
Please check more details in the above named poo# 119812.
A progress.opensuse.org issues has been created, check poo# 119812.
After prepared the LTP test python runner as in poo#116668, the scheduled runltp-python tests in public cloud-Development group 447 started, but some tests initially failed all for the same issue and were restarted 3 times before to pass, so 2 tests failed and last one passed, in 2 different builds.
In particular the first runs of kernel-ec2: syscalls: https://openqa.suse.de/tests/9856819#step/run_ltp/50 cve: https://openqa.suse.de/tests/9856226#step/run_ltp/50 failed both with the same error:
That same error was already noted in the past and initially, it was resolved with a patch in the ssh module, adding a sleep time, but it re-occurred now and is not deterministic, test reruns sometime pass: probably related to some sync timing.
Please check more details in the above named poo# 119812.