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:
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:
then I can launch programs from that shell window, but if I again do:
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
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
Version-Release number of selected component (if applicable):
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.
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.
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.
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.