xpra icon
Bug tracker and wiki

Opened 2 weeks ago

Closed 2 weeks ago

#2021 closed defect (fixed)

Automated tests: On server shutdown, Xpra GUI is launched

Reported by: J. Max Mena Owned by: J. Max Mena
Priority: minor Milestone: 2.5
Component: tests Version: 2.4.x
Keywords: Cc:

Description

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.

Attachments (1)

2021_screenshot.png (46.2 KB) - added by J. Max Mena 2 weeks ago.
Screenshot as mentioned in description

Download all attachments as: .zip

Change History (8)

Changed 2 weeks ago by J. Max Mena

Attachment: 2021_screenshot.png added

Screenshot as mentioned in description

comment:1 Changed 2 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

.. 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.

comment:2 Changed 2 weeks ago by 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.

comment:3 Changed 2 weeks ago by 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.

comment:4 Changed 2 weeks ago by 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

comment:5 Changed 2 weeks ago by 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.

comment:6 Changed 2 weeks ago by Antoine Martin

Try r20900.

comment:7 Changed 2 weeks ago by J. Max Mena

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.