Anyone else getting this problem that SCO says does not exist ? 2

[SpenBabe]

We are at the end of the road with this one !!!!

We have 20+ clients that we have upgraded to 5.0.5 or 5.0.6 over the last 2 years. Some of the upgrades involved new hardware as well.

The problem is that on an hourly basis, telnet sessions are "freezing" up. By whatever means (rebooting PC, closing emulation software, etc), the user starts a new telnet session, which gives them a new ttyp? number & everything appears to be fine.

However the ttyp? number they were using is still there with all the processes still running, but who, finger & whodo does not report the user as being logged in on that terminal. When you look at the process table using ps, you find that initial shell (ksh or sh) has a parent PID of 1 where current connections have a parent PID which is the PID of the telnet daemon (telnetd)

If these processes are not manually killed, they consume a license & eventually the server begins to slow down.

We have, on SCO's advice, changed network cards to 3C980C ones & we have even gone as far as changing one of our clients servers (at our own expense) to a Hewlett Packard server recommended to us by SCO Hardware Certification Team which made no difference.

I have a "gut feeling" that SCO 5.0.5 & above has a problem with faster processors (all affected machines are 800Mhz Pentium III or above) or is less tolerant of network transmission problems that older versions.

I am not asking for a solution (though it would be nice) What I need is some moral support & some evidence that I'm not going mad !! SCO have started to take the attitude that they are not interested & we should use OpenLinux instead !! With over 20 man-years work invested in Unix application software, we feel that is unacceptable !!!!

Thank in advance


Spencer Window (not a joke name)
spencer.window@eastmidlandcomputers.ltd.uk

 

[aixinstall]

Hello Spencer,

We have installed SCO 5.0.6 more then 50 times, and we do not have the problems you have.I also installed on a 2,4 Ghz processor, so on a Pentium III it has to work.
We have installed many new servers, if the customer has an older version of SCO, we don't upgrade but we do a fresh installation.
The problem is that you have to configure all the printer en user information on the new server.
But is this an SCO problem, maybe it's a network problem.
- Is your networkcard speed 10 or 100 and not "auto detect".
If your server is conected to dual speed hub or switch this can give a problem.
- Have you checked the message and syslog file, is there a problem with kernel parameters???????
- Use "netstat" to check your network status.

 

[pub101]

Are the users login into a 3rd party application?

We've experienced problems where a remote user telnet's to the server remotely, logs into an application, then closes the telnet session without loging out of the application. This will most likely keep the process out there for the application login, so it won't release the shell process either.

We did experience problems without the user logging into an application, but it was on AIX. We resolved this by adding the following to the user's .profile:

TO=7200
echo "Setting Autologout to $TO"
TIMEOUT=$TO
TMOUT=$TO
export TIMEOUT TMOUT

I don't know if it will work on SCO, but it's worth a try. It just sets the timeout value to a number (in seconds).

<It's not even worth my time to speak about SCO's lack of support on issues that appear to stump them>

 

[Annihilannic]

See man idleout for a way to achieve this in OpenServer. Annihilannic.

 

[RShaw]

One REALLY silly question...

Are you by any chance using the SCO Box as a DHCP host?

I have many clients that for some insane reason what to run teh SCO box as a DHCP host and problems are soon to follow


For the Record...I HATE DHCP! Makes my life as a remote network analyst a living hell!

 

[SpenBabe]

Nope, not using SCO as DHCP server & just in case you ask, most of the sites affected don't have any form of DHCP at all ! Spencer Window (not a joke name)
spencer.window@eastmidlandcomputers.ltd.uk