Tru64 V5 unexpected X-windows applications timeout

[Geert Van Pamel]

I am running a freshly installed Tru64 V5 DS20E server. System parameters are all default.

Problem is that my X-applications are auto-logged out after a timeout of (one or several?) hours. Actual imeout period seems not really fixed?

I have 4 other Tru64 systems running which do not experience this problem. I have been using Tru64 since 1994 and never encountered such a problem.

I did not find any reference in ITRC nor on internet about this problem. The problem is annoying me, since I have to login each time over and over again. Can anybody help me?

[Steven Schweda]

What is the X server (display) here, a Tru64
system or something else?

What's a typical application? How is it run?
Except for a terminal window (dtterm, xterm),
you don't actually log into (or out of) a
typical application. An application may lose
its connection to the X server and die. A
network problem could cause this, or the
process on the application server (X client)
could die for some reason.

The only thing I can think of quickly which
might last for hours would be a DHCP lease,
but I assume that all the Tru64 systems have
static IP addresses.

[Rob Leadbeater]

Hi,

Can you confirm exactly which version of Tru64 you're running please...

Are the other 4 Tru64 systems all the same hardware and OS ?

Cheers,

Rob

[Geert Van Pamel]

I have 2 almost identical DS20E machines running exactly the same Tru64 V5.1 version. One machine is showing the problem, the other does not.

The user accounts are the same (/etc/passwd being identical on all machines).

uname -a
OSF1 xxx V5.1 2650 alpha

Both machines are displaying screen output to the same X display.

My conclusion is that there is nothing wrong with the display server (running Exceed on Windows), because it works perfectly for one of the Tru64 machines, but not for the other.

Actually I start my sessions on both Tru64 machines via Exceed Client Startup as follows:

Using the REXEC protocol:

export DISPLAY=1.2.3.4:0.0; /usr/bin/X11/xterm -ls

So now you understand why I am talking about logging into an X application!?

I have 3 other Tru64 V4.0D machines using the same display server; neither of those machines experience the problem.

All machines are physically in the same data center.

One small difference is that the machine experiencing the problem has only 1 GB RAM; the other which does not have the problem does have 4 GB memory. But still there is sufficient RAM memory free on both machines.

procs memory pages intr cpu
r w u act free wire fault cow zero react pin pout in sy cs us sy id
[on bad machine]
3 177 43 99K 12K 12K 1 0 0 0 1 0 23 99 133 0 0 100

[on good machine]
3 243 43 417K 43K 47K 23 15 21 0 28 0 80 912 428 2 1 97


Perhaps there could be some oher system parameter different amongst those 2 DS20E Tru64 V5.1 machines?

[Geert Van Pamel]

Some more information about this very strange, yet unsolved, timeout problem. Seems that I have only timeout problems with the X-term applications:

/usr/bin/X11/xterm
/usr/bin/X11/dxterm
/usr/dt/bin/dtterm

The user accounts on the different systems are setup identically; however only 1 Tru64 V5 system is experiencing X-term timeout problems.

All other X-Window applications seems not to experience timeout problems. Examples:

/usr/bin/X11/xclock
/usr/bin/X11/demos/cpuinfo

[Steven Schweda]

Maybe it's more shell-related than X-related.
"man csh", look for "autologout"?

[Geert Van Pamel]

Thanks, Steven, but we are using ksh; not csh

echo $SHELL
/bin/ksh

set |grep TMOUT
TMOUT=0

The origin of the problem is still not identified. Other ideas? Since it is occurring with all of xterm, dtterm, dxterm I am wondering more and more if it could be really an X-Windows problem?!

Shouldn't it rather be a system-wide process parameter issue?

[Geert Van Pamel]

One step further into the solution.

I just physically moved the "good" Tru64 V5 machine into the data center, and now also this machine has the problem of loosing X connections.

We suspect that the network switch has a timeout on port 6000 ?

Does the network manager not like X11 connections of long duration?

What is strange is that when we keep running a utility like tail -f /dev/null (or some other file) the timeout seems not to occur.

[Rob Leadbeater]

Hi,

Is there a firewall somewhere between the client and servers ??

That would very probably cause the problem you're seeing...

Cheers,

Rob

[Geert Van Pamel]

You are right, I assume it is the switch which has statefull traffic inspection enabled.

When there is no more traffic on the X11 port, then this port is closed by the switch, effectively terminating the idle xterm.

The only thing we can do is to start the xterm again from the Exceed client. Thanks.

[Geert Van Pamel]

Confirmed by network management.

The system is connected through a load balancer that disconnects inactive network connections.

Since xterm does not have a keep-alive timer, the only option is to manually restart lost xterm sessions, or to run e.g. collect -sd to generate some activity when the session is not actively used.

[Hein van den Heuvel]

>> Confirmed by network management.

>> The system is connected through a load balancer that disconnects inactive network connections.

So tell them to fix it.
They are a service provider right, and they are not delivering to your needs.
You are the customer, they should adapt, not you. Anythign you needc to do to workaround it is a waste of resource for you, your system, and their precious network.

The 'idle session' kill may well be a bad idea always, or it may just be a bad idea for your sessions.
Can they use parameters (ip addresses, port numbers) to exclude your systems from their sillyness?

Groetjes,
Hein.