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: Always 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.
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 ftp://people.redhat.com/mharris/testing/8.0 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. Thanks.
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: /tmp/.X11-unix/X0 causing the unix connection to X to fail. I haven't seen the failure yet since fixing this. I think this is NOTABUG.