Operating System - HP-UX
1844016 Members
2330 Online
110226 Solutions
New Discussion

Problem with PTY allocation

 
Sandip Ghosh
Honored Contributor

Problem with PTY allocation

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
Good Luck!!!
14 REPLIES 14
Paul Sperry
Honored Contributor

Re: Problem with PTY allocation

increase the kernel parameter nstrpty to fit your needs.
Sridhar Bhaskarla
Honored Contributor

Re: Problem with PTY allocation

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
You may be disappointed if you fail, but you are doomed if you don't try
Sandip Ghosh
Honored Contributor

Re: Problem with PTY allocation

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
Good Luck!!!
Paul Sperry
Honored Contributor

Re: Problem with PTY allocation

Sandip Ghosh
Honored Contributor

Re: Problem with PTY allocation

Thanks Paul for replying.

But I think you have not understood the problem.

Sandip
Good Luck!!!
James A. Donovan
Honored Contributor

Re: Problem with PTY allocation

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.
Remember, wherever you go, there you are...
Mike Stroyan
Honored Contributor

Re: Problem with PTY allocation

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.
Sandip Ghosh
Honored Contributor

Re: Problem with PTY allocation

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
Good Luck!!!
James A. Donovan
Honored Contributor

Re: Problem with PTY allocation

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.
Remember, wherever you go, there you are...
Sandip Ghosh
Honored Contributor

Re: Problem with PTY allocation

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
Good Luck!!!
Mike Stroyan
Honored Contributor

Re: Problem with PTY allocation

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.
Animesh Chakraborty
Honored Contributor

Re: Problem with PTY allocation

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
Did you take a backup?
Sandip Ghosh
Honored Contributor

Re: Problem with PTY allocation

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
Good Luck!!!
Mike Stroyan
Honored Contributor

Re: Problem with PTY allocation

| 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.