@ancorgs https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:A/yast2-ruby-bindings/standard/x86_64

I added extra debugging output for the screen problem, but still I have no clue. This command

screen -D -m sh -c 'rspec /home/abuild/rpmbuild/BUILD/yast2-ruby-bindings-3.2.6/tests/integration/std_streams_spec.rb >/tmp/test_cmd_output 2>&1; echo \$? > /tmp/exit'

Doesn't seem to produce a /tmp/test_cmd_output nor /tmp/exit file. I would expect both to be there and I cannot reproduce it in my TW. Has something changed in OBS?

In the line above, changing "screen -D -m" to "screen -d -m" seems to fix the problem. But I would appreciate advice from Martin Vidner (who originally suggested the usage of -D) and the screen maintainer.

In the PR that introduced this test, I noted "(...) will not trigger the bug because CMake redirects the output to ./Testing/Temporary/LastTest.log" Ancor, have you checked that file?

In libyui-test I tried several ways of starting such a test: screen, tmux, screen -d -m, screen -D -m https://github.com/libyui/libyui-test/commits/master/virtual_terminal The lowercase version runs in background. It we don't mind then we can use that.

I just did. Nothing interesting there. Just the same clueless empty output.

@Alexander_Naumov any insight?

Alexander Naumov (Alexander_Naumov) - over 7 years ago

The problem is that you don't get the logfile, right? In case of GNU screen 4.5.1 you should use option "-L" for logging on and "-Logfile" to set the logfile name.

@Alexander_Naumov, That doesn't seem to be the problem.

As you can see in the second comment, we are already redirecting the output and the exit code to files just using the good old >. I tried to perform the same redirection using "-L -Logfile" instead of ">" bit it makes no big difference.

On the other hand, I got to the conclusion yesterday that using "-d -m" worked... but to be honest I cannot reproduce that today, neither with > or -L. :-( So whatever options I use, after screen execution the files are not there.

Doing more checks...

@mlin7442 sr#479296 should workaround the problem. Can you check?