action #94510
openos-autoinst OBS build errors in Leap 15.2 size:M
0%
Description
Observation¶
[ 72s] Can't use an undefined value as filehandle reference at lib/Mojo/IOLoop/ReadWriteProcess.pm line 298.
[ 3676s] qemu-kvm: terminating on signal 15 from pid 32619 ()
[ 3677s] ### VM INTERACTION END ###
[ 3677s] No buildstatus set, either the base system is broken (kernel/initrd/udev/glibc/bash/perl)
[ 3677s] or the build host has a kernel or hardware problem...
Job seems to be stuck here, killed. (after 3600 seconds of inactivity)
so first there is the "undefined value", second tests shouldn't timeout after an hour but much earlier internally, third it should not fail at all :)
Acceptance criteria¶
- AC1: no "undefined value"
- AC2: no timeout after an hour but much earlier internally
- AC3: tests in OBS do not fail
Updated by mkittler over 3 years ago
This is the related code:
my $stdout;
my $stderr;
my $stdin;
$stdout = $output_pipe->writer() if $output_pipe;
$stderr
= (!$self->separate_err) ? $stdout
: $output_err_pipe ? $output_err_pipe->writer()
: undef;
$stdin = $input_pipe->reader() if $input_pipe;
open STDERR, ">&", $stderr
or !!$internal_err->write($!)
or $self->_diag($!);
Line 298 is open STDERR, ">&", $stderr so apparently STDERR is undef here. This is strange. I'm re-triggering the build to see whether it is a one-time issue.
Updated by mkittler over 3 years ago
Now it succeeds. Note that the builds for other architectures than x86_64 weren't failing in the first place. I'm wondering whether this is even specific to Leap 15.2 or just a general sporadic issue.
Updated by livdywan over 3 years ago
We all agree this is "M" and workable/properly sized as-is (planning poker)
Updated by okurz over 3 years ago
- Subject changed from os-autoinst OBS build errors in Leap 15.2 to os-autoinst OBS build errors in Leap 15.2 size:M
Updated by okurz over 3 years ago
- Priority changed from High to Low
- Target version changed from Ready to future
https://build.opensuse.org/package/show/devel:openQA:Leap:15.2/perl-Mojo-IOLoop-ReadWriteProcess seems to be very stable the past days. No more problems observed. This leaves still AC1 and AC2 to be properly fulfilled, not just "avoided".