SSH problem

[sumdomo]

HI,

We have an custom make application install in HPUX 11.31 ia64

People access/launch through passwordless ssh from their Solaris 10 workstation (64bits)  with same login account.

Recently the time it took to launch the app is so long. It took about 2 sec to ssh login but about 2-3 minutes to launch application.

Any idea/suggest for how to troubleshoot this? Since this are two different OS does the type of ssh mater?

[Matti_Kurkela]

If the time delay was between the successful authentication and the shell prompt/execution of the login script, the most common reason for delays like this is that the /var/adm/wtmp and/or /var/adm/wtmps files have grown very large.

After a successful login, HP-UX normally searches through wtmp[s] for the previous login time in order to display it to the user. If the system has a lot of logins and/or FTP server activity, the wtmp[s] files can grow very large. There is no automated wtmp[s] rotation process in HP-UX by default. Before 11.31, the SAM included a Routine Task to shorten the appropriate system logfiles, including wtmp; but in the default system configuration, it had to be run manually.

The wtmp[s] files can be truncated manually, but it is generally wise to do it when the system has no or just a few users logged in, as some tools may behave a bit oddly if used in a login session that no longer has a corresponding wtmp record. This is usually just a minor inconvenience, however.

If you can login to the system and see the shell prompt appear without a significant delay, the problem is likely elsewhere. First you should check the condition of the disk that holds the application. If it is a local disk, it might be experiencing read errors, indicating that the disk is close to a complete failure. In this case, you will typically see a lot of SCSI error messages in the "dmesg" listing and in the /var/adm/syslog/syslog.log file. If this is the reason, make sure your application and its data is backed up and have the disk replaced.

(If the system is in serious production use, you always should have mirrored disks, *and* some way of monitoring the condition of the disks. The monitoring is important: otherwise you are likely to notice a problem only when one half of the mirror has already failed, and the second half is starting to fail. By that time, some of your data may already have been damaged, and it may be impossible to replace the disks while the system is in use.)

[sumdomo]

Thanks for your reply,

I do noticed that the wptm(s) file grow very big and I did purge it by cp /dev/null  wptm(s).

But it has no effect.

The disks actually is SAN Disk and the OS is HPVM guest.

[feeble]

If ssh still connects in a timely fashion, then I doubt that ssh is the issue. But if you truly want to rule it out, I would suggest opening telnet temporarily, connecting, and see if you still have the issue. If that is the case, it is probabaly the app.