Visit Jeremy's Blog.
Go Back > Forums > Linux Forums > Linux - General
User Name
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.


  Search this Thread
Old 12-17-2004, 11:35 AM   #1
Registered: Nov 2004
Distribution: RHEL 2.1, RHEL 3.0, SUSE 9.2
Posts: 31

Rep: Reputation: 16
Cron job - which X display is used by default?

I'm having a problem with an application that I inherited. The application is essentially a custom-made print daemon that converts incoming files to PCL and submits them to a printer. The application is called by a bash script that polls an incoming directory and launches the application based on the incoming file type.
I've got the script loaded into crontab.

Crontab calls the script, which polls the directory and calls the application. Based on testing, if I manually call the script from the console, it works fine. If I modify the crontab from the console and log off, it seems to work fine. But if I call the application from a SSH session, or if I modify the crontab from an SSH session, I get the following error:

Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

<application>: cannot connect to X server :0.0

I've been able to deduce that the application wants to run as if at the console. In the script, I can see that the DISPLAY variable is set to :0.0 in an attempt to get this done, but it apparently isn't happening.

I've tried commenting out the "export DISPLAY=" statement, and I get

<application>: cannot connect to X server

(no Xlib lines, no port spedified by the application error line.)

What's going on here? How do I get this to work consistently without having to launch it from the console? In theory, I'm deploying this to several remote sites and I won't have the ability to launch from the console.

Any help would be greatly apprecaited. Thanks in advance.

(I do have contacts with the people who wrote this app, and I'm following up with them, but they appear to be application programmers and don't seem to have a much firmer grasp of X than I do. If they come through with an answer, I'll post it.)
Old 12-17-2004, 12:21 PM   #2
Registered: May 2003
Location: Lisbon Falls, Maine
Distribution: RH 8.0, 9.0, FC2 - 4, Slack 9.0 - 10.2, Knoppix 3.4 - 4.0, LFS,
Posts: 789

Rep: Reputation: 30
IIRC, trying to do this over SSH requires you to export the DISPLAY variable with the IP address of the client that you are connecting FROM. Something similar to:

export DISPLAY=

should work... you may also need to add the IP of the machine that you are connecting TO by using xhosts (must be done as root).

You'll also have to call SSH with the option to forward X connections, which I believe is done by the -X option:

ssh -X

I'm at work without a linux box in front of me :-( so I can't tell you the exact commands from memory. The above is as close as I can get, but hopefully it helps.


Last edited by slightcrazed; 12-17-2004 at 12:22 PM.
Old 12-17-2004, 04:38 PM   #3
Registered: Nov 2004
Distribution: RHEL 2.1, RHEL 3.0, SUSE 9.2
Posts: 31

Original Poster
Rep: Reputation: 16
Thanks for the response, Slight.

Here's some additional information based on your post and further testing:

For any other application, opening an X window isn't a problem. We're connecting to the server (Redhat Enterprise Linux 3.0, btw) using putty with X tunnelling enabled, and running winaXe on our windows machines to run X sessions locally. For example, I can ssh to the server, type mozilla at the prompt, and the browser opens on my machine. (BTW, if you use the -X switch, you don't have to change the DISPLAY variable; ssh handles this for you. At least that's what I've read and it works for me.)

I just finished running a series of tests on the server to figure out what the different scenarios are that result in successful printing and what result in failure. Here's how that turned out:

user logged into console, manually launching script: success

user logged into console, script called via crontab: success

no one logged into console, script called via crontab: failure

The failed scenario resulted in the xlib errors in my initial post. I did not yet run with a different user logged on at the console, but my feeling is that it will fail with anyone other than the app's owner.

So I know it's a problem with the app, and the app developer is looking into it, but what's the problem and can we address it while waiting for a fix from the developer?
Old 12-17-2004, 04:45 PM   #4
Registered: Nov 2004
Distribution: RHEL 2.1, RHEL 3.0, SUSE 9.2
Posts: 31

Original Poster
Rep: Reputation: 16
About my tests -- all were conducted with no SSH connections by the app owner. Just wanted to clear that up. Another test for me to conduct is what happens if the app owner is connected via SSH as well as logged on at the console. It's on my list...
Old 12-17-2004, 05:55 PM   #5
LQ Newbie
Registered: Dec 2004
Posts: 21

Rep: Reputation: 15
Jobs submitted to Cron should not require any user interaction---they should not require any input and should not require use of an X Display.

If the job requires an X-Display then it will fail when one is not available. That is why you get the X connection error if the owner is not logged in at the console when the cron job runs.

The "export DISPLAY=:0.0" in the script tells the app to use the local display. It can only do this if the owner is logged in at the local console.

If the app is non-interactive (and it should be if it is scheduled with Cron) then it should not use the X Display. The correct fix would be to get an update of the application that does not request an X-Display.

As a work-around, if a fix for the app is not available, the owner of the job can run a vncserver using Xvnc. Then set the DISPLAY variable to point to the Xvnc server in the script (for example :1 or :2, depending on which display the vncserver is running on). The Vncserver can be kept running even when the user is not logged on.

Old 12-29-2004, 04:27 PM   #6
Registered: Nov 2004
Distribution: RHEL 2.1, RHEL 3.0, SUSE 9.2
Posts: 31

Original Poster
Rep: Reputation: 16

Thanks for your post. I've tested your suggestion and it appears to work, giving us a workaround until the problem gets resolved. According to a developer, their executable uses X functionality for other tasks (not what is required for the scripted job), so that's why Xlib is being used. No word yet on whether it can be bypassed for this scripted task.

Thanks again for your help!

matt (fiservguy)


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
cron job the_rhino Linux - Newbie 10 10-02-2004 04:34 PM
CRON Job tommytomato Fedora 12 09-13-2004 01:38 AM
cron job working2hard Programming 6 07-28-2004 10:12 PM
Cron job rajasekarvr Linux - General 4 05-03-2004 06:35 PM
Cron Job imanahmadi Linux - Newbie 1 07-04-2003 12:39 AM > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 12:33 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration