Xpra: Ticket #2021: Automated tests: On server shutdown, Xpra GUI is launched

As the title states, when running the automated tests (once you get them to the state that they can successfully spin up a server and attach the client), after each test run completes, the tests then spawn the Xpra GUI. To me, it looks like the command that is supposed to stop the server is actually stopping the server, but is also somehow launching the Xpra GUI simultaneously.

Some background info:

The machine in question is a Fedora 28 VM running the latest Beta package from /beta. No OpenGL for now, so I'm only running the A/V tests for now to make sure I can get a successful run with some kind of output data.

I'm running the tests by spinning up a start-desktop session like so:

xpra start-desktop --bind-ssh=0.0.0.0:20000 --start="xrandr -s 1280x720" --start="xterm -e 'python ./test_measure_perf.py config_just_av ./myfirst.csv 1 2 > ./myfirst.log'" --no-daemon

Upon completion of each test run, I end up in a situation where the tests are still running but not going anywhere because it's waiting on...something? If I attach a session to the start-desktop wrapper, I see that there's an Xterm running and the Xpra GUI. The Xterm indicates the tests have paused while it waits for the GUI to disappear. If I kill the GUI's PID, the next round of tests start and everything continues normally, until that runs completion. At which point it spawns a new GUI and waits on it, over and over again.

So I'm not sure if I haven't ended up in a weird corner case, or there's a bug in the tests as this is a totally new situation. I'll attach a screenshot in a minute to show you what I'm seeing.



Tue, 30 Oct 2018 17:04:43 GMT - J. Max Mena: attachment set

Screenshot as mentioned in description


Tue, 30 Oct 2018 19:34:37 GMT - Antoine Martin: owner changed

.. running the automated tests (once you get them to the state that they can successfully spin up a server and attach the client)

What is needed?

I'm not really following the rest, but it shouldn't be too hard to log every exec command the automated test run, reduce it to a single test, then figure out which command shows the gui. FYI: the gui fires up from just "xpra" with no arguments.


Tue, 30 Oct 2018 20:47:22 GMT - J. Max Mena:

What is needed?

Mostly, installing a few packages that we don't require. xdotool is the big one, and Trickle is no longer available in the Fedora repos, so I've cheated and added a blank file in /usr/bin that matches what the tests expect to see. That's about it for setup steps, thankfully.

I'm not really following the rest, but it shouldn't be too hard to log every exec command the automated test run, reduce it to a single test, then figure out which command shows the gui.

I'll slip in a few print statements and see what I get. I have a feeling it comes down to formatting being wrong, but I really don't know enough about Python's subprocessing system to speak with any authority.


Tue, 30 Oct 2018 22:39:58 GMT - J. Max Mena:

Update:

I had to kill the test run because I forgot to install mplayer beforehand.

Perusing the logs shows this interesting tidbit:

stopping server with: ['/usr/bin/xpra', 'stop', ':10']
stopping server with: ps -ef | grep -i [X]org-for-Xpra-:10 | awk '{print $2}' | xargs kill

I find it notable that the first command is an array and the second one looks like a valid Bash command. I wonder if the Python interpreter is interpreting ['/usr/bin/xpra', 'stop', ':10'] as three separate commands - /usr/bin/xpra, stop, and :10? If that were the case, then it would make sense that I see the Xpra GUI pop up after each run - it's literally just running xpra, stop, and :10 but not showing the output of those commands.


Wed, 31 Oct 2018 05:27:39 GMT - Antoine Martin:

I had to kill the test run because I forgot to install mplayer beforehand.

Why run more tests when you should be trying to reduce the search space?

I find it notable that the first command is an array and the second one looks like a valid Bash command.

That should be fine, as long as the other arguments to Popen are also correct (shell=True). As per the documentation: Popen: a sequence of program arguments or else a single string


Wed, 31 Oct 2018 17:29:33 GMT - J. Max Mena:

I wrote a quick Python test application that is essentially only the chunk of code in test_measure_perf.py that actually calls xpra stop :10. It's only 10 lines, and if I launch it from the console, I get the Xpra GUI to show up on my local machine, so I'm pretty sure that array of commands is what's causing the GUI to appear.

import subprocess
def main():
        print("Launching subprocess")
        process = subprocess.Popen(['/usr/bin/xpra', 'stop', ':10'], stdin=None, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
        print(process.communicate())
if __name__ == "__main__":
        main()

However, if I turn change shell=True to shell=False, the test application works as expected.


Wed, 31 Oct 2018 17:46:33 GMT - Antoine Martin:

Try r20900.


Wed, 31 Oct 2018 17:55:10 GMT - J. Max Mena: status changed; resolution set

Spun up my second test VM, upped the src/tests/xpra local SVN checkout I had (which included the change to test_measure_perf.py) and started a quick test run. Based on the logs and CPU usage, it looks like it's on its third test now, so it appears to be working as expected.

Thanks, that seems to have done it.

Closing.


Sat, 23 Jan 2021 05:40:01 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2021