topic Re: Problem with PTY allocation in Operating System - HP-UX

Problem with PTY allocation

Sandip Ghosh — Wed, 18 Jun 2003 20:31:05 GMT

Hi All,

We are facing a strange problem in our environment. We are running HP-UX 11.00 on N4000.

Whenever we are doing rlogin to the system it is allocating the ptys to rlogin but when the user is logging out the kernel is not releasing the ptys. So, after a certain time we are running out of the ptys. And the system is giving the message "Unable to allocate pty". Have you guys faced this kind of problem before?

For your information our npty and nstrpty is set to 60 (default). We know that we need to increase the npty, nstrpty and nstrtel but my question is, if we increase also, some time will come when we will be again going out of resources.

Thanks in advance for your replies........

Sandip

Re: Problem with PTY allocation

Paul Sperry — Wed, 18 Jun 2003 20:42:58 GMT

increase the kernel parameter nstrpty to fit your needs.

Re: Problem with PTY allocation

Sridhar Bhaskarla — Wed, 18 Jun 2003 20:44:20 GMT

Hi Sandip,

Is it happening for rlogin only or even telnet is affected?.

What is the current patch level on the system?. Try installing reasonbly latest patch bundles.

-Sri

Re: Problem with PTY allocation

Sandip Ghosh — Wed, 18 Jun 2003 20:49:11 GMT

If you increase the kernel parameters also it will not solve the problem but it will deffered the problem. But it will again re-appear when it will reach that particular no.

And
Sri,
The Patch level is Sep 2002 Quality Pack Bundle.
It is not happening with telnet. It is happening with rlogin only.

Sandip

Re: Problem with PTY allocation

Paul Sperry — Wed, 18 Jun 2003 20:52:43 GMT

Take a look here:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x39b1854994d9d4118fef0090279cd0f9,00.html

Re: Problem with PTY allocation

Sandip Ghosh — Wed, 18 Jun 2003 20:55:22 GMT

Thanks Paul for replying.

But I think you have not understood the problem.

Sandip

Re: Problem with PTY allocation

James A. Donovan — Wed, 18 Jun 2003 21:01:55 GMT

Do a netstat -a. Do you have a lot of connections in the FIN_WAIT_2 state? If so, then the remote sessions may not be properly closing the connections, and you may need to set the tcp_fin_wait_2_timeout value using ndd.

Re: Problem with PTY allocation

Mike Stroyan — Wed, 18 Jun 2003 21:11:31 GMT

It is not clear how you determined that the stream ptys were not released. Perhaps there
is some group of processes that is opening more and more stream ptys. You could examine what processes are using ptys by running this command-

fuser /dev/ptmx /dev/pts/* 2>&1 | grep 'o$'

You may find that more and more ptys are being held open by processes.

Re: Problem with PTY allocation

Sandip Ghosh — Wed, 18 Jun 2003 21:13:25 GMT

I am having around 43 FIN_WAIT in my system.

I have also read abt the FIN_WAIT in a previous thread. I need to know that if I change the tcp_fin_wait value on the fly, what are the possible things could get affected?

Sandip

Re: Problem with PTY allocation

James A. Donovan — Wed, 18 Jun 2003 21:23:57 GMT

Changing the tcp_fin_wait_2_timeout on the fly is unlikely to harm anything. The fin_wait state means that your system is simply waiting for an acknowledgement that the session is indeed over and that the connection should be closed.

If all of your FIN_WAIT state connections are due to old rlogin connections not being cleared and your npty and nstrpty settings are 60, it's pretty clear as to why you're getting the "unable to allocate" messages.

Re: Problem with PTY allocation

Sandip Ghosh — Wed, 18 Jun 2003 21:24:57 GMT

Mike,

If you look at the /dev/pts directory you will see that some of the devices are owned by root:sys and some of them are owned by the users. The pty's those are not used those will show you as root:sys, others are in use. In my system I could see that there are around 57/58 devices are there which is in use by some user. But when I am giving ps command I couldn't find those pty's.

By the fuser command I couldn't find any of them in use. I have looked through "last|grep still" command also. but I couldn't found any of them.

Sandip

Re: Problem with PTY allocation

Mike Stroyan — Wed, 18 Jun 2003 22:41:50 GMT

What does fuser say about /dev/ptmx ?

If there are rlogind or other master side processes holding /dev/ptmx open, then they could be keep the slave sides of the ptys busy even though no process has the slave side open.

That would fit the FINWAIT problem.

Re: Problem with PTY allocation

Animesh Chakraborty — Thu, 19 Jun 2003 04:57:29 GMT

Hi Sandip,
If you have glance then
#glance -t will show the used npty numbers.
You can also donload lsof to monitor the process being used.

Regards

Re: Problem with PTY allocation

Sandip Ghosh — Thu, 19 Jun 2003 20:47:52 GMT

Hi Mike,

It is not showing anything on /dev/ptmx.

Animesh,

It is showing available=60 and used=2. HP is also looking at the problem. The problem is that once it is allocating one terminal it is not releasing from the kernel when the users are getting out of the system.

So, how is life in Singapore? Everybody is fine over there?

Sandip

Re: Problem with PTY allocation

Mike Stroyan — Mon, 23 Jun 2003 14:47:16 GMT

| If you look at the /dev/pts directory you will see
| that some of the devices are owned by root:sys and
| some of them are owned by the users. The pty's
| those are not used those will show you as
| root:sys, others are in use. In my system I could
| see that there are around 57/58 devices are there
| which is in use by some user. But when I am
| giving ps command I couldn't find those pty's.

The ownership of /dev/pts/* files does not indicate whether they are currently in use. The ownership is often set when a stream pty starts to be used. There is no convention of changing the ownership when the pty is no longer in use. (The grantpt() function runs the /usr/lbin/chgpt program to give ownership to the current user of the pty.)

Perhaps you are looking at the system when the problem is not occuring at all. You may have to wait for an "Unable to allocate pty" message before you run the fuser command to look for the cause of the trouble.