Improper logout from telnet session pegs cpu utilization

[Paul Maglinger]

We use scanner guns that telnet into our HP-UX servers. If the users do not log out of the sessions properly sometimes the session stays active and in some cases the ksh process hammers the CPU utilization above 90 percent and isn't doing anything. Idle timeout will not work because the system is seeing it as doing something. Does anyone have any suggestions for correcting this issue?

[Steven E. Protter]

Shalom,

You can use a UNIX95 ps feature to identify such processes and kill them.

This is really an application problem.

For safety, see that a recent system QPK is installed or telnet patch is available from http://itrc.hp.com Patch HP-UX

SEP

[Paul Maglinger]

Thanks for the reply. I've been using the ps command to find and kill off the offending processes. I pretty much determined that it was an application problem. I was hoping to come up with a solution on the administration side until it was fixed on the development side.

[Bill Hassell · Accepted solution]

This sounds like /etc/profile or .profile have trapped the SIGHUP signal and are ignoring it. The following /etc/profile line is normal in all HP-UX versions:

trap "" 1 2 3

This command disables QUIT INT and HUP signals. This prevents a login session from aborting in the middle of the profile script. HOWEVER, it is imperative that the following line is also in /etc/profile at the end of the file:

trap 1 2 3

They look almost identical but are VERY different. The first has "" as the action to take for the listed signal numbers -- which is: do nothing (ignore).

The second form restores normal operation. When your scanner guns do not logout but simply disconnect from the network (like power off) then a Hang-UP event has occurred. Normally, HP-UX will then terminate the session. But if the HUP signal has been trapped and assigned "" (which means do nothing) then the session will hang and consume CPU cycles as the shell tries to talk to the non-existent device.

To see if traps are enabled, put this line into the scanner login files (ie, .profile):

logger "Active traps: \"$(trap)\""

[Paul Maglinger]

I checked the /etc/profile and both entries are in there. That being the case, would the additional logging provide useful information? Would the same trap entries need to be in the .profile as well?

[Bill Hassell]

The first trap entry is to ensure that lines in /etc/profile are always run and the user cannot escape the script. At the end, the traps are re-enabled. If your scanner actually logs in and runs /etc/profile and .profile, put the logger statement at the end of both files. If you get nothing, then the login is non-standard and you'll need to debug the login manually. Typing the trap command at a shell prompt will show you the exceptions.

Does this login use a special shell?

[Dennis Handly]

>in some cases the ksh process hammers the CPU

So there are no child processes? If none, it doesn't seem to be an application problem, since there is none at this time. (Unless you consider a shell script or the scanner software to be an application?)

Can you use tusc to see what is going on in the looping shell?

[Paul Maglinger]

Using a third party process monitoring tool to kill the process when it runs away.