I have a rather complex problem, I'll try to keep it short and sweet:

I ssh (Cygwin on Windows XP) to a Linux machine at a university 150 miles away. On this Linux machine I run a program called Fluent (computational fluid dynamics software).

Fluent has a text user interface which generally permits me to write a journal file of commands and execute them in batch mode, without GUI, with the following commands:

$ at -f <batch_file.txt> now

where <batch_file.txt> contains the fluent command:

fluent 3ddp -g <journal_file.txt> text_output.out 2>&1&

where -g is a switch that supresses GUI and graphics, <journal_file.txt> is the list of Fluent commands, and text_output.out is the file that contains the redirected text output of Fluent.

Fluent has a bug, though (at least one). There is one command that I *must* run in Fluent that cannot be executed through the TUI. I can enter GUI commands in the journal file, but I clearly cannot run Fluent in batch mode if I do this. Fluent support is working the bug, but I don't think we'll see a fix from them until the next release, if then.

I must run Fluent in batch mode, as my calculations require days and weeks to execute (my connection would never survive long enough).

What I am dreaming of is a way to run Fluent without suppressing graphics, so as to permit the running of GUI commands in the journal file. However, I would want to redirect this GUI in such a manner that I can still run in batch mode.

I heard somewhere that people have used 'setenv DISPLAY /dev/null' to suppress graphics output, but that won't help me as it would muck up my ssh.

Any ideas? If you need any more info, let me know. I know just enough about Linux to be dangerous, so use small words when you are trying to describe things to me.

Thanks all,
Matt

if the 'setenv DISPLAY /dev/null' really works (I never tried it...) you may put it in the batch file, like this:
at least this is safe enough to try

greetz,
.-=~ iluvatar ~=-.

I'm afraid that won't work as the DISPLAY variable is set (and required) by ssh to be localhost. It would work if I were actually sitting at the machine.

As such, the logical conclusion seems to be to use VNC, which I learned about the other day. I can tunnel VNC through ssh, spawn a desktop, do whatever I want graphically on the machine, and close VNC. The desktop will still run even though I am not logged in. I have yet to restart my calculation as the network admins decided it was prudent to delete all of my files off of my home directory!

Thanks for your post.

I think the bash script runs in it's own shell, so the enviroment variable is known in that shell. like in X: if I open a xterm and set a enviroment variable it isn't set in another xterm. and this bash script is called by at, so at spawns a bash shell with the DISPLAY variable set, without ssh, right?

greetz,
.-=~ iluvatar ~=-.

Even so, ssh doesn't require DISPLAY to be set to localhost. However, if you want graphics to be displayed (which you say you don't), then DISPLAY should point to a display accepting connections for you.

This may be localhost (which is provided by ssh), but it might as well be something else, including (possibly) /dev/null.

I too never heard of this trick though. I'm going to try it as soon as I get home

Groetjes,

Kees-Jan

Did anyone ever figure this out? I have basically the same problem, I need to run a program in the background while I'm disconnected, but it needs a window open...

Thanks

I can be way off here, but have you guys tried to "&" in the end of the command? When I'm at work, I ssh into my home linux and do "wget http://etc etc ... &" to send the download to background. Even after logging ssh off the download continues.

No because the program requires an Xwindow to stay open to run. Doing mozilla& will still open mozilla on my local machine. I need the window to be opened on the machine I'm logged into and stay open.

I tried setting the display to /dev/null, but that doesn't work for all applications (at least xload wouldn't accept it - not that that would have made any sense, but still)

So I guess I recommend using vnc for these cases. It gives you a normal x-display with the ability to disconnect and reconnect without shutting down any programs in between.

Groetjes,

Kees-Jan

If you don't need to actually see the X window, then you might look at using xvfb to set up a virtual X framebuffer. xvfb acts just like a normal X server, except that it doesn't use any display or input hardware (and so doesn't generate input events); the framebuffer itself is held in virtual memory.