urgent: "Cannot allocate pty"

[Paul Senior_1]

Unfortunately I had to rebuild our production system from scratch last week.
It is a k460 running on hpux 10.2
I reinstalled the o/s from disk, then recreated the lvm structure and applied an frecover, using the graph file below:-

e /stand/bootconf
e /stand/system
e /dev
e /etc/checklist
e /etc/fstab
e /etc/fstab
e /stand/ioconfig
e /ioconfig
e /etc/lvmtab
e /etc/lvmconf

Users are back in,but are experiencing 2 problems:-
1) cannot print (I think this is related to missing /dev device files, so I'm about to copy those back from an frecover

2)we can only get 60 users logged on through telnet sessions at any one time (we need 90)
the syslog shows the following:-

"Jun 12 12:10:02 alk460 telnetd[28601]: Cannot allocate pty"

The sysdef command (attatched) shows npty and nstrpty set to 400 each, although the /stand/system (attacthed) shows it set to 60. Obviously if I copied back the /stand/vmunix and this is up-to-date , but the /stand/system (see below) is out of date, does this matter?

alk460 /stand >cat system | pg
***************************************
* $Source: /usr/local/kcs/sys.DAVIS_800/filesets.info/CORE-KRN/RCS/generic,v $
* $Revision: 1.3.98.1 $ $Author: root $
* $State: Exp $ $Locker: CRT $
* $Date: 95/07/20 10:24:09 $
*
***************************************
* Generic system file for new computers
***************************************
*
* Drivers/Subsystems
ccio
c720
sctl
sdisk
mux2
CentIf
ps2
scsi3
scsi1
target
tape2
lanmux0
cdfs
vxbase
lvm
lv
hpstreams
clone
strlog
sad
echo
sc
timod
tirdwr
pipedev
pipemod
ffs
lan2
lan3
dlpi
inet
uipc
nm
ni
tpiso
inet_cots
inet_clts
netdiag1
ldterm
ptem
pts
ptm
pckt
nfs
diag0
dump lvol
nstrpty 60
maxswapchunks 750

[Paul Senior_1]

sorry, sysdef output is included in this attatchment

[Pete Randall]

"Obviously if I copied back the /stand/vmunix and this is up-to-date , but the /stand/system (see below) is out of date, does this matter?"


It will matter the next time you build a kernel, because the npty value present in /stand/system will be used.


Pete

[Paul Senior_1]

fair point, but why can't I get more than 60 pty's with the current kernel when it has npty and nstrpty both set to 400?

[Pete Randall]

I would try fixing /stand/system, then re-building the kernel and see what you get.


Pete

[Paul Senior_1]

I now think the /stand/system file being out of date is a red-herring RE why we can only get 60 users on the server.

I've done a count on the No of pty's we have setup and it is 62.
I now want to create more device drivers; bearing in mind people are in using the system at present, how can I create extra pty's without affecting existing users?

[James R. Ferguson]

Hi Paul:

Try:

# insf -d pty -n 400

Regards!

...JRF...

[Paul Senior_1]

will running insf to create more ptty's destroy the active ptty sessions?

[Bill Hassell]

pty values require two changes: kernel params *and* device file creation. Set all 3 params:

npty = nstrpty = nstrtel = 400

to 400, then run insf -e. Since your system was restored in a piecemeal fashion, SAM may or may not work correctly to set the pty values and create the needed device files. I cannot stress enough that you should be using Ignite/UX for your VG00 backup.

[James R. Ferguson]

Hi (again) Paul:

You should be able to run 'insf' without impacting your current sessions.

Regards!

...JRF...

[Paul Senior_1]

I ran insf -d pty -n 400 and no users seem to have been adversly affected and we seem to have pty's on tap again.
excellant, thankyou to everyone that responded. I'm almost out of the woods...