Discussion:
Exceed session freezes after a longer while
(too old to reply)
Lukasz Zielinski
2006-04-27 12:29:52 UTC
Permalink
Hi there,
I have a strange situation here for last few weeks. Poeple are working
on their Ms Windows 2000 machines with Hummingbird Exceed 10.0.0.5 as X
servers. They are connecting via ssh to an AIX 5.2 machine, exporting
DISPLAY to their local Windows workstations and running our
application. Everything is working fine, but several times a day (today
it was like seven times) the session freezes and it's not possible to
do anything, but killing the session with `kill -9`.

In $HOME/.dt/errorlog I have:
Workspace Manager: I/O error on display:: frappc152:0.0

frappc152 is a Windows workstation. The screen saver is disabled in
/usr/dt/config/Xstartup:
/usr/X11R6/bin/xset -dpms
/usr/X11R6/bin/xset s off

Do you have any idea where is the clue? Our firewall team checked
everything, both machines stand in one location, the network works just
fine, in general. Nothing in Hummingbird's support area. Is it
dt-related or Exceed-related or what?

Sincerely,
Lukasz

--
Lufthansa Systems Aeronautics
Frankfurt, Germany
Bobohoolie
2006-04-27 12:38:44 UTC
Permalink
Hi,

I've seen this before and you're looking at DT or Exceed but as far as
I know it has something to do with firewall and SSH ! Let the netwerk
guys check on port 22 and connections status and if it worked fine
beofre ask them if they changed something recently ! (Or check your own
changes !). First be sure you have no timeout settings in
/etc/ssh/ssh(d).config files before you ask them.

Grussen aus Holland

Marcel
Timothy J. Bogart
2006-04-27 19:20:32 UTC
Permalink
Post by Lukasz Zielinski
Hi there,
I have a strange situation here for last few weeks. Poeple are working
on their Ms Windows 2000 machines with Hummingbird Exceed 10.0.0.5 as X
servers. They are connecting via ssh to an AIX 5.2 machine, exporting
DISPLAY to their local Windows workstations and running our
application. Everything is working fine, but several times a day (today
it was like seven times) the session freezes and it's not possible to
do anything, but killing the session with `kill -9`.
Workspace Manager: I/O error on display:: frappc152:0.0
frappc152 is a Windows workstation. The screen saver is disabled in
/usr/X11R6/bin/xset -dpms
/usr/X11R6/bin/xset s off
Do you have any idea where is the clue? Our firewall team checked
everything, both machines stand in one location, the network works just
fine, in general. Nothing in Hummingbird's support area. Is it
dt-related or Exceed-related or what?
Sincerely,
Lukasz
--
Lufthansa Systems Aeronautics
Frankfurt, Germany
A little more info - is there really a firewall between the machines if
'they stand in one location'? During the 'freeze' can you telnet port
22 on the Win machine? Ping it? Randomly across machines? All
machines at one time? Mostly on one machine?

The only real experience I can offer is whenever I have been called in
by 'the PC guys' to deal with an X package - if there is no obvious
problem with the Universe, reinstalling the OS and the X server fixes
things till Win gets cranky again. Registry pruning/revigorating at
your own risk.

Cheers.
Lukasz Zielinski
2006-04-28 08:42:34 UTC
Permalink
Thanks for your emails. Well, the situation is following: we have
plenty of servers and workstations here and all of them are working
fine. Lately, we needed to install a new machine for a new customer.
Installation was "default" - AIX 5.2, updates, our applications and so
on. Exceed on Windows machines was the same as before (and it's working
fine with another servers). When I'm tracing the route between the new
server and any of workstations it's exactly the same as between Windows
workstations and every of "old" servers.
I've ordered monitoring of the link between the server and the
workstations for next 24 hours, maybe I'll find something in results.
The problem is that I cannot administrate the firewalls, because we
have "the rules" and proper team for that. I rather cannot do anything
on the Windows workstations, becasue they work fine with another
servers. For now, I can login to the new server, do anything I want,
but after an idle time, it hangs (Exceed) and the ssh connection breaks
down. Answering Timothy's email: we have two different locations, two
different networks, after hanging everything is pingable, I must admit,
I haven't checked if it's possible to log into 22 port on the new
server, I'll check this out.

Cheers.
Gerhard Gonter
2006-04-29 02:53:55 UTC
Permalink
[...] For now, I can login to the new server, do anything I want,
but after an idle time, it hangs (Exceed) and the ssh connection breaks
down.
So, they ssh connection may be breaking first and everything then hangs,
is that possible? Check autologout or something similar. process
limits may also be a problem, but not if someone changed something.

If "your network" decides to drop the connection, because it does not
see any packets for a while, you can produce them, e.g. by starting
xclock. In a similar situation, I used ping's output to generate enough
traffic to keep those tcp session monitors happy...

GG
Claudiu Costin
2006-05-01 15:52:29 UTC
Permalink
Hi,

On Sat, 29 Apr 2006 06:53:55 +0400, Gerhard Gonter
Post by Gerhard Gonter
[...] For now, I can login to the new server, do anything I want,
but after an idle time, it hangs (Exceed) and the ssh connection breaks
down.
So, they ssh connection may be breaking first and everything then hangs,
is that possible? Check autologout or something similar. process
limits may also be a problem, but not if someone changed something.
If "your network" decides to drop the connection, because it does not
see any packets for a while, you can produce them, e.g. by starting
xclock. In a similar situation, I used ping's output to generate enough
traffic to keep those tcp session monitors happy...
A simple solution (see: man ssh_config):
ssh -o TCPKeepAlive=yes ***@host
That way a router with NAT would see traffic and reset TCP session expire
counters.
Post by Gerhard Gonter
GG
--
kind regards,
Claudiu Costin
Lukasz Zielinski
2006-05-02 12:10:14 UTC
Permalink
Hi Claudiu,
Thanks for posting.
This option does not work on our system:
$ ssh -o TCPKeepAlive=yes qlhualtp
command-line: line 0: Bad configuration option: TCPKeepAlive

Second thing, hanging doesn't happen on other systems, that's
interesting. Still investigating...

Sincerely,
Lukasz

--
http://lukasz.com/

Loading...