Subject: FVWM: Lose ability to connect to X after some days

From: Kyle <[email-masked]>
Date: Mon, 30 Dec 2002 12:28:12 -0700

I have several servers all showing the same problem.  I have redhat 8.0 
and fvwm 2.4.14.

On the console (:0.0) after running a session for about 2 weeks, I lose 
the ability to launch new programs from fvwm.  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

There is not the usual Xauth message indicating that the connection was 
refused etc.  Just the message showing the failure.  "xauth list" shows 
a cookie for the display that looks like it is supposed to.

If I do:

export DISPLAY=hostname:0.0

then I can launch programs from the shell window (via tcp), but if I 
again do:

export DISPLAY=:0

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

If I try to restart fvwm, the session crashes and I have to log back in 
again.  Then the session works for a number of days again and then 
mysteriously fails again.

I thought of always starting fvwm with -d hostname:0.0, but no luck.  It 
still forces the DISPLAY variable to :0.0.  Besides, the unix connection 
is supposed to be more efficient so it would be nice if I could get it 
to work.

I don't know if this is an fvwm or an X problem but I wanted to see if 
anyone else had seen it or knows what it is.  And I don't think I've 
ever seen it on a stock (gnome) redhat box.

Kyle

--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Mon, 30 Dec 2002 17:39:38 -0500

> Error: Can't open display: :0
...
> mysteriously fails again.
...
> ever seen it on a stock (gnome) redhat box.

I read everything that comes into the fvwm mailing list and
I can't remember a problem report like this.

I'd suspect some kind of memory leak in the X server.
Maybe you should run:

ipcs -a

every once in a while for shared memory.  And run top
or ps for conventional memory.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Cameron Simpson <[email-masked]>
Date: Wed, 1 Jan 2003 12:54:54 +1100

On 12:28 30 Dec 2002, Kyle <[email-masked]> wrote:
| If I do:
| 
| export DISPLAY=hostname:0.0
| 
| then I can launch programs from the shell window (via tcp), but if I 
| again do:
| 
| export DISPLAY=:0
| 
| It still fails.  So its like unix access to the server doesn't work, but 
| tcp access still does.

Check to see if the unix socket is still there:

	% ls -la /tmp/.X11-unix
	total 32
	drwxrwxrwt    2 root     cameron      4096 Dec 29 14:50 .
	drwxrwxrwt  294 root     root        28672 Jan  1 12:51 ..
	srwxrwxrwx    1 root     cameron         0 Dec 29 14:50 X0

Maybe some overly helpful /tmp cleaning program has removed it.
How precise is that "two weeks" time measurement? Like clockwork,
or just touchy-feely?

| If I try to restart fvwm, the session crashes and I have to log back in 
| again.  Then the session works for a number of days again and then 
| mysteriously fails again.

Work around it in your .xsession (or .xinitrc, depending) by setting
$DISPLAY there.

| I thought of always starting fvwm with -d hostname:0.0, but no luck.  It 
| still forces the DISPLAY variable to :0.0.

More likely it doesn't touch the $DISPLAY variable at all. So all your
subprograms are using :0.0 while fvwm is using hostname:0.0.

| Besides, the unix connection 
| is supposed to be more efficient so it would be nice if I could get it 
| to work.

Indeed.

| I don't know if this is an fvwm or an X problem but I wanted to see if 
| anyone else had seen it or knows what it is.  And I don't think I've 
| ever seen it on a stock (gnome) redhat box.

See if my /tmp cleaning idea holds.

Cheers,
-- 
Cameron Simpson, DoD#743        [email-masked]    http://www.zip.com.au/~cs/

The revolution will not be televised.	- Mike Mitten, [email-masked], DoD#522