I'm trying to run a program as a script in a remote machine. The problem I've is related to X11. Actually, my program doesn't display anything (widgets, etc) but there are some definitions that I can't delete. For example: a=WIDGET_BASE()
If I try to run this command on a session without X, IDL returns me the following error:
X11 connection rejected because of wrong authentication. X connection to localhost:10.0 broken (explicit kill or server shutdown).
So my question is if there is a way to run IDL without X ? Or, if you are good using Linux, how can I activate the X before the command idl -rt=program_script.sav -args A B C and how can i deactivate after ?
On Feb 5, 10:37 am, nata <bernat.puigdomen...@gmail.com> wrote:
> So my question is if there is a way to run IDL without X ?
No idea. But if there is then the following is useless :-|
> Or, if you are good using Linux, how can I activate the X before the > command > idl -rt=program_script.sav -args A B C > and how can i deactivate after ?
Well, you say you're working on a remote machine. This implies you need to connect with X11-tunneling turned on. this is done with
ssh -X user@machine
Next, you should test x11 by, say, starting an xterm. If xterm won't show up on the machine you are sitting at, then you need to debug your X11. Probably soething to do with your DISPLAY variable in your shell.
If all works ok, then run your program and follow it with (assuming BASH is your shell, find out with: echo $SHELL) OLDDISPLAY=$DISPLAY export DISPLAY=blahblahblah
this will "break" X11 on your local machine untill you set: export DIAPLAY=$OLDDISPLAY
This prevents things from showing up n your local machine, but doesn't actually break the X11 tunnel. Not sure how to do that. If it's possible it should be a man or google away :-)
Thanks for your reply Gianguido but this is not what I'm looking for..
I can't use ssh -X user@machine because the idea is execute the program as a script. So, I created a SHELL SCRIPT that calls IDL:
idl -rt=program_script.sav -args A B C
And the computer runs this script automatically. I used the crontab command, so when the script is running it has no X. So the question is still the same: 1) Is it possible to run IDL without X? 2) Is there a way to activate the X before the command 'idl - rt=program_script.sav -args A B C' and deactivate it after ?
> Thanks for your reply Gianguido but this is not what I'm looking for..
> I can't use ssh -X user@machine because the idea is execute the > program as a script. > So, I created a SHELL SCRIPT that calls IDL:
> idl -rt=program_script.sav -args A B C
> And the computer runs this script automatically. I used the crontab > command, so when the script is running it has no X. > So the question is still the same: > 1) Is it possible to run IDL without X? > 2) Is there a way to activate the X before the command 'idl - > rt=program_script.sav -args A B C' and deactivate it after ?
Then it's just a matter of starting the virtual frame buffer program on <HOST> to create the virtual display #1:
/usr/X11R6/bin/Xvfb :1 -screen 0 1152x900x8 &
Then within the script that performs <desired batch operations> the following line sends graphics output to DISPLAY 1, the virtual frame buffer we just started:
set DISPLAY=:1.0 ; export DISPLAY
I installed Xvfb and I do: Xvfb :5 -screen 0 1152x900x8 & set DISPLAY=:5.0 ; export DISPLAY idl plot, dist(2) % Compiled module: DIST. X11 connection rejected because of wrong authentication.
> Then it's just a matter of starting the virtual frame buffer program > on <HOST> to create the virtual display #1:
> /usr/X11R6/bin/Xvfb :1 -screen 0 1152x900x8 &
> Then within the script that performs <desired batch operations> > the following line sends graphics output to DISPLAY 1, the virtual > frame > buffer we just started:
> set DISPLAY=:1.0 ; export DISPLAY
> I installed Xvfb and I do: > Xvfb :5 -screen 0 1152x900x8 & > set DISPLAY=:5.0 ; export DISPLAY > idl > plot, dist(2) > % Compiled module: DIST. > X11 connection rejected because of wrong authentication.
> T_T It doesn't work ! > Help? > nata
I was going to suggest Xvfb as well. The only other way I can think of is find another machine that is running an X server all the time, set up authentication (xhost or whatever), and then have your IDL process point its DISPLAY at that machine. But this seems fragile.
What you are doing should work. Things to look at:
Is your Xvfb server really running? Check process list. Can you run another X11 non-IDL client such as xclock to the Xvfb server?
The error message really suggests that there is an SSH issue somehow. I know that you are logging into this headless server with SSH and that you want the Xvfb server and IDL client to both run on the headless server, but something isn't getting set the way you think it is. Check your env vars, etc. Might try using set DISPLAY=localhost: 5:0 just to be explicit.
Might also try turning off X11 tunneling in your initial connection to the headless server, just to rule that out. It turns out that if you have X11 tunneling enabled in SSH, not only will SSH set your DISPLAY to localhost:10.0, but it will also put an authentication cookie in your ~/.Xauthority file. You are undoing the effect of SSH setting the DISPLAY to :10, but not the effect of the cookie. Might try renaming the ~/.Xauthority file or something.
Try googling on the error message text for a number of other possibilities.
I think you are on the right track - something simple must be wrong. Of course it would be better if you were allowed to change the IDL code to not do this :-).
Thank you for your reply. Finally I got something. Now, I'm able to run the script but only for the root user (I don't know why). For the other users I got the following message: Warning: Cannot allocate colormap entry for default background.
This is my final script:
export DISPLAY=:2 /usr/X11R6/bin/Xvfb :2 -screen 0 1152x900x16 & /usr/local/itt/idl70/bin/idl -rt=my_script.sav -args A B C
nata
PS I realized that I just have to define the screen one time (/usr/ X11R6/bin/Xvfb :2 -screen 0 1152x900x16 &). Then, if the script will be executed each 10 minutes using the 1st and 3th lines it's enough
> Thank you for your reply. Finally I got something. > Now, I'm able to run the script but only for the root user (I don't > know why). For the other users I got the following message: > Warning: Cannot allocate colormap entry for default background.
> This is my final script:
> export DISPLAY=:2 > /usr/X11R6/bin/Xvfb :2 -screen 0 1152x900x16 & > /usr/local/itt/idl70/bin/idl -rt=my_script.sav -args A B C
> nata
> PS I realized that I just have to define the screen one time (/usr/ > X11R6/bin/Xvfb :2 -screen 0 1152x900x16 &). > Then, if the script will be executed each 10 minutes using the 1st and > 3th lines it's enough
What got rid of the
X11 connection rejected because of wrong authentication.
message?
I would put a sleep for a few seconds after you kick off Xvfb to make sure it gets started before IDL tries to talk to it.
Also, I'd put a killall Xvfb after IDL runs. There's no good reason to let the server run. If you have to run it as root, you might want to find some other way to kill it, so you don't kill someone else's Xvfb.
You don't need a screen that large - you could go really tiny in w and h, and 8 bits for d. This is just a dummy server and you'll save some memory.
The colormap issue is probably caused by the root user and the "other" users having a different set of X default or config files, or something along those lines. The "other" users may have config files in their home dirs that are trying to init a desktop or who knows what. It is just a warning - the IDL client still runs without being root, right? I wouldn't run it as root if I could avoid it.
It could be that one of these config files is asking for a 32-bit color spec and your server is 16 bpp. You might try starting Xfvb with 32 bpp. Or move all those X-related config files out of the way in your home dir and see if that helps. Check for X-related env vars as well.
> On Feb 5, 3:22 pm, nata <bernat.puigdomen...@gmail.com> wrote:
> > Hi Karl,
> > Thank you for your reply. Finally I got something. > > Now, I'm able to run the script but only for the root user (I don't > > know why). For the other users I got the following message: > > Warning: Cannot allocate colormap entry for default background.
> > This is my final script:
> > export DISPLAY=:2 > > /usr/X11R6/bin/Xvfb :2 -screen 0 1152x900x16 & > > /usr/local/itt/idl70/bin/idl -rt=my_script.sav -args A B C
> > nata
> > PS I realized that I just have to define the screen one time (/usr/ > > X11R6/bin/Xvfb :2 -screen 0 1152x900x16 &). > > Then, if the script will be executed each 10 minutes using the 1st and > > 3th lines it's enough
> What got rid of the
> X11 connection rejected because of wrong authentication.
> message?
> I would put a sleep for a few seconds after you kick off Xvfb to make > sure it gets started before IDL tries to talk to it.
> Also, I'd put a killall Xvfb after IDL runs. There's no good reason > to let the server run. If you have to run it as root, you might want > to find some other way to kill it, so you don't kill someone else's > Xvfb.
> You don't need a screen that large - you could go really tiny in w and > h, and 8 bits for d. This is just a dummy server and you'll save some > memory.
> The colormap issue is probably caused by the root user and the "other" > users having a different set of X default or config files, or > something along those lines. The "other" users may have config files > in their home dirs that are trying to init a desktop or who knows > what. It is just a warning - the IDL client still runs without being > root, right? I wouldn't run it as root if I could avoid it.
> It could be that one of these config files is asking for a 32-bit > color spec and your server is 16 bpp. You might try starting Xfvb > with 32 bpp. Or move all those X-related config files out of the way > in your home dir and see if that helps. Check for X-related env vars > as well.
I use a cron job running on a Linux system that uses the Z-buffer for all graphics. That way you avoid any need to define a graphics device that has some kind of 'physical' existence. Z buffer uses system memory. Of course you will need to change a few commands with the Z buffer compared to a window device. I have use Xvfb before but i found it was a hassle if the PC was ever restarted and the Xvfb wasn't auto started.
> Then it's just a matter of starting the virtual frame buffer program > on <HOST> to create the virtual display #1:
> /usr/X11R6/bin/Xvfb :1 -screen 0 1152x900x8 &
> Then within the script that performs <desired batch operations> > the following line sends graphics output to DISPLAY 1, the virtual > frame > buffer we just started:
> set DISPLAY=:1.0 ; export DISPLAY
> I installed Xvfb and I do: > Xvfb :5 -screen 0 1152x900x8 & > set DISPLAY=:5.0 ; export DISPLAY > idl > plot, dist(2) > % Compiled module: DIST. > X11 connection rejected because of wrong authentication.
> T_T It doesn't work ! > Help? > nata
It takes a bit of time for Xvfb to start, so you may need a "sleep" after starting Xvfb before you can actually use it.
I've been using Xvfb on a number of machines for years. Most of these machines run for extended periods between boots, so I just start Xvfb manually after a restart. There is one (headless) machine where we have to use TCPIP, e.g. DISPLAY=localhost:2 in place of just DISPLAY=:2.
You can query the Xvfb server using xdpyinfo.
-- George White <aa...@chebucto.ns.ca> <g...@acm.org> 189 Parklea Dr., Head of St. Margarets Bay, Nova Scotia B3Z 2G6
> On Feb 6, 10:54 am, Karl <karl.w.schu...@gmail.com> wrote:
> > On Feb 5, 3:22 pm, nata <bernat.puigdomen...@gmail.com> wrote:
> > > Hi Karl,
> > > Thank you for your reply. Finally I got something. > > > Now, I'm able to run the script but only for the root user (I don't > > > know why). For the other users I got the following message: > > > Warning: Cannot allocate colormap entry for default background.
> > > This is my final script:
> > > export DISPLAY=:2 > > > /usr/X11R6/bin/Xvfb :2 -screen 0 1152x900x16 & > > > /usr/local/itt/idl70/bin/idl -rt=my_script.sav -args A B C
> > > nata
> > > PS I realized that I just have to define the screen one time (/usr/ > > > X11R6/bin/Xvfb :2 -screen 0 1152x900x16 &). > > > Then, if the script will be executed each 10 minutes using the 1st and > > > 3th lines it's enough
> > What got rid of the
> > X11 connection rejected because of wrong authentication.
> > message?
> > I would put a sleep for a few seconds after you kick off Xvfb to make > > sure it gets started before IDL tries to talk to it.
> > Also, I'd put a killall Xvfb after IDL runs. There's no good reason > > to let the server run. If you have to run it as root, you might want > > to find some other way to kill it, so you don't kill someone else's > > Xvfb.
> > You don't need a screen that large - you could go really tiny in w and > > h, and 8 bits for d. This is just a dummy server and you'll save some > > memory.
> > The colormap issue is probably caused by the root user and the "other" > > users having a different set of X default or config files, or > > something along those lines. The "other" users may have config files > > in their home dirs that are trying to init a desktop or who knows > > what. It is just a warning - the IDL client still runs without being > > root, right? I wouldn't run it as root if I could avoid it.
> > It could be that one of these config files is asking for a 32-bit > > color spec and your server is 16 bpp. You might try starting Xfvb > > with 32 bpp. Or move all those X-related config files out of the way > > in your home dir and see if that helps. Check for X-related env vars > > as well.
> I use a cron job running on a Linux system that uses the Z-buffer for > all graphics. That way you avoid any need to define a graphics device > that has some kind of 'physical' existence. Z buffer uses system > memory. Of course you will need to change a few commands with the Z > buffer compared to a window device. I have use Xvfb before but i found > it was a hassle if the PC was ever restarted and the Xvfb wasn't auto > started.
> Tony
I think that one constraint on the original problem was not being unable to modify the IDL code. I got the impression from the OP that the app wasn't doing any graphics that were needed, but was doing a call to WIDGET_BASE anyway. The best solution would be to make the app Really non-graphical with some sort of startup option. But that is apparently not a possibility here.
In article <de638b67-12b8-40f3-83a5-6ac5b27f1...@q2g2000pre.googlegroups.com>,
TonyL <anthony.legg...@bigpond.com> wrote: > I use a cron job running on a Linux system that uses the Z-buffer for > all graphics. That way you avoid any need to define a graphics device > that has some kind of 'physical' existence. Z buffer uses system > memory. Of course you will need to change a few commands with the Z > buffer compared to a window device. I have use Xvfb before but i found > it was a hassle if the PC was ever restarted and the Xvfb wasn't auto > started.
> Tony
This is a good suggestion, particularly now that the Z-buffer supports 24-bit color. Downsides are that you have to use TrueType fonts (some may disagree that that is a downside), and, of course, widgets don't work.
