Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 80824 - Lose ability to connect to X over time
Lose ability to connect to X over time
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-12-31 13:15 EST by Kyle Bateman
Modified: 2007-04-18 12:49 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-09 12:02:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kyle Bateman 2002-12-31 13:15:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021220

Description of problem:
I'm running rh8.0 with xdm directly enabled in inittab as follows:

x:5:respawn:/usr/X11R6/bin/xdm -nodaemon

I also have a ~/.Xclients that calls fvwm2 as the window manager (so the gnome
desktop is not being utilized).

On the console (:0.0) after running a session for about 2 weeks, I lose  the
ability to launch new programs.  If I open a shell window 
and try to launch any program (xcalc, for example), I get an error:

Error: Can't open display: :0

If I do:

export DISPLAY=hostname:0.0

then I can launch programs from that shell window, but if I again do:

export DISPLAY=:0

It then fails again.  So its like unix access to the server doesn't work, but 
tcp access still does.

If I try to restart fvwm (at this point), the session crashes and I have to log
back in again.  On some servers, the system dumps back to a text console and I
can't get an xdm login again without restarting xdm.  After logging back in, the
session works for about 2 weeks again and then eventually fails again in the
same way.

This problem shows up on at least 4 servers.  It existed under rh7.2 as well.

I've posted this to the fvwm group too, but it seems more like an X or  config
or distribution issue to me so I'll put it here too to see if anyone else is
seeing it.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install rh80
2. run xdm in leiu of prefdm
3. start fvwm in .Xclients
4. log in to X on console
5. make sure DISPLAY=:0
6. use system for about 2 weeks

Actual Results:  All attempted program launches from session yield error:

Error: Can't open display: :0

or its equivalent.

Expected Results:  Program should be able to connect to X server and open a window.

Additional info:

I thought it might be an xauth problem, but I don't get the usual authorization
error message.  And "xauth add ..." doesn't fix the problem.

Once the problem exhibits itself, some attempts to open or close windows will
crash the session resulting in loss of work.  When xdm has to be restarted, this
boots other users off the system.
Comment 1 Mike A. Harris 2003-01-02 03:26:29 EST
First a side note:  The proper "Red Hat" way of running xdm, is to set
DISPLAYMANAGER=XDM in /etc/sysconfig/desktop

Is your hostname changing at all while X is running?  Perhaps a DHCP lease?
The hostname of a machine must not change while X is running or bad things
will happen.  This is an intentional security feature.

Another problem, is that X does not like the time changing drastically while
it is running.  If you run NTP, or some other time synchronization software
periodically, it may cause the X server to lock up or wreak havoc.  A fix
for this long standing issue in all X servers is in current rawhide XFree86,
as well as XFree86 4.2.1 test packages I have available on

I've not had any other similar reports to this before, so I'm not sure what
to suggest other that the above.  Problems that are hard to reproduce, and
only occur every 2 weeks on someone's system are essentially unfixable unless
the person can narrow down the problem to a distinct reason, or provide
details on how to reproduce it more easily.

Can you try the 4.2.1 packages on my ftpsite and see if they fix the problem?
If not, we can troubleshoot further from there.

Comment 2 Kyle Bateman 2003-01-09 12:02:48 EST
I think I've found the most likely problem.  We have a local cron job that
cleans out old files in /tmp.  It was left over from the days before the OS had
a built in function for this.  I think it was deleting the file:


causing the unix connection to X to fail.  I haven't seen the failure yet since
fixing this.  I think this is NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.