How to run a Cmdline job on Linux with X server active for window creation?

[njushchyshyn]

So, we're working on deploying Lightwave rendering on our linux workers by running a screamer net command within wine.

All is working well running screamer net via ssh with the following approach:
start ssh with -X option to allow xwindow forwarding.

run a test commandline:
opt/cxoffice/bin/wine d:/_Dive_Shared/bin/screamernet/win/Programs/lwsn.exe --help

The resulting help text from lwsn comeback nice.

The same commandline always fails with this error:
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.

Also validated this by logging into the worker using ssh without the -X option to get the same error at the command line.

So.....

How can I configure a cmdline job to run on linux with X server active?

[Scot Brew]

We will add Wine integration as a Feature Request. 

Though Qube usually runs in headless sessions (without a graphical windows) on the Workers, it has been used to render with nVidia graphics cards for Gelato.  I'll also check with our developers about any known nuances of running an X session through a Qube submission as you have described, though it may be a Wine-specific issue.

[Scot Brew]

Submitting a cmdline job like "xeyes" on a Linux machine will produce the error message "Error: Can't open display:", similar to what you noticed with Lightwave running through Wine.

There may be a way to call X applications through Qube, but it is not set up for it out of the box as most all renderers are commandline driven and do not require X.  We will look into it a bit further and see if a way can be identified to do so.

[shinya]

Hi-
Allow me to post the answer I provided you in the tech support email,
so others can benefit from it.

----
Qube does not really deal with windowing system/server on the
worker nodes-- in face, on a typical farm, workers may not
have any windowing servers running.

Having said that, you might be able to get some useful results
if you log a user into all the workers, make sure the X server
is started, and do an "xhost +" command, and leave the user
logged in.  Then your jobtype back-end code can open an X client
(wine, for instance) locally.

Your back-end code could conceivably use "ssh -X localhost" to run
wine also, but I haven't tested that.

[michael.graf]

your best bet will be to use a virtual framebuffer.
Xvfb has worked well for us in the past when we needed to do post processing via the queue and the program required a -display.

Setup Xvfb to start up at boot and all you need to do is issue a command like
DISPLAY :77 command

where 77 is the screen number set by Xvfb.

There are a lot of resources on the net to help explain this more and set it up.
Additionally, check if your program has -screen or -display switch to set the display to use.  Then you will not need to use the DISPLAY :77.
Technically, to be more complete you should use
DISPLAY localhost:77
or DISPLAY hostname:77
or DISPLAY FQDNS:77

[lineplot]

Interesting - this affects us too.  We have headless render nodes with a graphics chip, boxx 10200, running Qube 5.4 with Maya 2009.  We do have some processes that need a graphics buffer - PFX for example to render hair or toon lines, or ideally HW rendering for quick shot estimation.

I've been messing with xauth and gdm for a couple of days now.  I can in fact get xclock to run from a qube job, but it's not a secure solution.  I'll try the virtual framebuffer and report back.  I hope it can use the GPU, while still leaving X locked up or better, turned off.

[njushchyshyn]

This is great information. Thanks for all the input!
I'll take a look at Xvfb as well.
Thanks again.