Anyone have any clues about what could "use up" some resource used to create a forwarded X connection (ssh -X)?
I've got these testbeds that run 24/7 on random collections of both real and virtual machines, and they are all started from inside a VNC session using ssh -X to get to the target test machine. The theory is that any test which needs a X server will be happy with the VNC server.
After running for a few months, tests sometime start failing because they can't open the X server. Reboot the host (which is running fedora 13) and recreate the VNC server and things work again.
Seems like something is getting "used up" that the reboot cleans up, but I haven't been able to find out what that something is :-).
Tom Horsley wrote:
Anyone have any clues about what could "use up" some resource used to create a forwarded X connection (ssh -X)?
I've got these testbeds that run 24/7 on random collections of both real and virtual machines, and they are all started from inside a VNC session using ssh -X to get to the target test machine. The theory is that any test which needs a X server will be happy with the VNC server.
After running for a few months, tests sometime start failing because they can't open the X server. Reboot the host (which is running fedora 13) and recreate the VNC server and things work again.
Seems like something is getting "used up" that the reboot cleans up, but I haven't been able to find out what that something is :-).
I saw something similar on fedora 13 some time ago.
Connections failing because the pseudo-file (Unix socket) /tmp/.X11-unix had been deleted for some reason.
In my case it was apparently a tmpwatch script cleaning away something more than what it should have.
I never understood if the problem was with stuff from Fedora 13 (atime, ctime, mtime flags to tmpwatch, effects of relatime...) or from other vendors, as this machine has additional proprietary software installed (including cronjobs).
It has been working for a few weeks now; maybe an update fixed it. Not sure.
On 10/03/2010 03:27 PM, Roberto Ragusa wrote:
Tom Horsley wrote:
Anyone have any clues about what could "use up" some resource used to create a forwarded X connection (ssh -X)?
I've got these testbeds that run 24/7 on random collections of both real and virtual machines, and they are all started from inside a VNC session using ssh -X to get to the target test machine. The theory is that any test which needs a X server will be happy with the VNC server.
After running for a few months, tests sometime start failing because they can't open the X server. Reboot the host (which is running fedora 13) and recreate the VNC server and things work again.
Seems like something is getting "used up" that the reboot cleans up, but I haven't been able to find out what that something is :-).
I saw something similar on fedora 13 some time ago.
Connections failing because the pseudo-file (Unix socket) /tmp/.X11-unix had been deleted for some reason.
In my case it was apparently a tmpwatch script cleaning away something more than what it should have.
I never understood if the problem was with stuff from Fedora 13 (atime, ctime, mtime flags to tmpwatch, effects of relatime...) or from other vendors, as this machine has additional proprietary software installed (including cronjobs).
It has been working for a few weeks now; maybe an update fixed it. Not sure.
Hi Tom, When the failure happens, in addition to checking the /tmp/.X11-unix socket, have you looked at memory? top should tell you how much is available and how much is used and by whom. If the socket is still there, and vnc fails due to lack of a resource, it might be memory. Many apps leak memory, and perhaps vnc is no exception.
Cheers,
JD
On Sun, 03 Oct 2010 17:11:20 -0700 JD wrote:
Hi Tom, When the failure happens, in addition to checking the /tmp/.X11-unix socket, have you looked at memory? top should tell you how much is available and how much is used and by whom. If the socket is still there, and vnc fails due to lack of a resource, it might be memory. Many apps leak memory, and perhaps vnc is no exception.
Nah, there is a ton of memory, and VNC itself is working fine. If I run xhost + in the VNC session, I can connect to the VNC server just fine using hostname:1 as the DISPLAY. It is only ssh -X forwarding that stops working.
Running strace on an X client shows that it even thinks it can open the X connection, but the first read it does always appears to get an EOF and it errors off with connection closed.
On 10/03/2010 03:27 PM, Roberto Ragusa wrote:
Tom Horsley wrote:
Anyone have any clues about what could "use up" some resource used to create a forwarded X connection (ssh -X)?
I've got these testbeds that run 24/7 on random collections of both real and virtual machines, and they are all started from inside a VNC session using ssh -X to get to the target test machine. The theory is that any test which needs a X server will be happy with the VNC server.
After running for a few months, tests sometime start failing because they can't open the X server. Reboot the host (which is running fedora 13) and recreate the VNC server and things work again.
Seems like something is getting "used up" that the reboot cleans up, but I haven't been able to find out what that something is :-).
I saw something similar on fedora 13 some time ago.
Connections failing because the pseudo-file (Unix socket) /tmp/.X11-unix had been deleted for some reason.
In my case it was apparently a tmpwatch script cleaning away something more than what it should have.
I never understood if the problem was with stuff from Fedora 13 (atime, ctime, mtime flags to tmpwatch, effects of relatime...) or from other vendors, as this machine has additional proprietary software installed (including cronjobs).
It has been working for a few weeks now; maybe an update fixed it. Not sure.
Tom, what exactly is the error message, and is it at the vnc server or at the vnc client?
On Sun, 03 Oct 2010 18:25:29 -0700 JD wrote:
Tom, what exactly is the error message, and is it at the vnc server or at the vnc client?
Neither. The error comes from any X client I try to run under an ssh -X command started from inside the VNC session. The X clients all error off trying to talk to the forwarded X display connection. If I provide them with the direct DISPLAY="vnchostname:1" and run xhost + to allow connections inside the VNC session, then the X clients work fine.
On 09/27/2010 11:51 PM, Tom Horsley wrote:
Anyone have any clues about what could "use up" some resource used to create a forwarded X connection (ssh -X)?
I've got these testbeds that run 24/7 on random collections of both real and virtual machines, and they are all started from inside a VNC session using ssh -X to get to the target test machine. The theory is that any test which needs a X server will be happy with the VNC server.
After running for a few months, tests sometime start failing because they can't open the X server. Reboot the host (which is running fedora 13) and recreate the VNC server and things work again.
Seems like something is getting "used up" that the reboot cleans up, but I haven't been able to find out what that something is :-).
The VNC server running out of file descriptors?
-
Ed Greshko -
JD -
Roberto Ragusa -
Tom Horsley