Initial telnet limit

[Terrence]

I found out the hard way that the default telnet limit on new rp servers is 60. I had changed the npty, nstrtel, and nstrpty kernel settings to 1000, but discovered that the limit of telnet sessions was still 60. One frantic call to the HP response center (while similtaneously searching the ITRC) revealed that I had to run the following commands (even though I had taken care to reboot the server)

insf -d pts -s 1000 -e -v
insf -d ptym -n 1000
insf -d pts -s 1000 -e -v

This still didn't work so following a tip from the itrc I then ran

insf -e

Eureka! This worked!

My questions? Why didn't a reboot create the device files? Am I the only one taken unawares by this? Do I really have to run all 4 commands? Should I create an unholy army of the undead and march on HP for vengence?

Opinions?

[Steven E. Protter]

Shalom,

The kernel imposes further limits.

nstrpty 60 - 60
nstrtel 60 - 60


Raise those two parameters and you will be able to get beyond 60 simultaneous sessions.

SEP
:-(

[Jeff Schussele]

Hi Terrence,

No - normally ioinit will do the insf commands at the reboot.
Check the /etc/rc.log to see if there was an error in ioinit.

Rgds,
Jeff

[Jeff Schussele]

SEP

Appears to me he did that....

Jeff

[Terrence]

No ioinit references at all in /etc/rc.log. Also no errors.

[Sandman!]

Hi Jeff,

The maximum number of telnet sessions allowed is controlled by the kernel parameter "nstrtel" in conjunction with the "tels" device files. Even though you changed the kernel parameter, you didn't increase "tels" device files thru...

# insf -d tels -s 1000

Infact before and after running insf -e you should have counted the number of existing telnet device files as:

# ls /dev/pts/t* | wc -w

Do a man on tels(7) and telm(7) for details on telnet device files. The npty kernel parameter does not control telnet sessions. It affects ptys used for non-telnet and non-r-commands such as dtterm, hpterm and xterm ptys. See pty(7). The nstrpty kernel parameter controls r-command like rlogin etc. and secure shell pty's called pts. See pts (7) and ptm(7).

cheers!

[Terrence]

Nice explanation Sandman, yet I was able to resolve the issue by running the commands in my initial question.

I did not run the command you suggested.

This suggests a disconnect, or more than one way to skin this cat.

[Sandman!]

Hi Terrence,

According to your post the following commands didn't work:
> insf -d pts -s 1000 -e -v
> insf -d ptym -n 1000
> insf -d pts -s 1000 -e -v

which doesn't have "insf -d tels -s 1000" command listed in there so I thought that was the problem. However "insf -e" did work which is an all-inclusive command implying that "insf -d tels -s 1000" is a subset of "insf -e". Since the nstrtel parameter was bumped up to 1000, "insf -e" would install the remaining 940 device files in the "/dev/pts" directory. You can verify with the following:

# kmtune -q nstrtel
<...should be 1000>

# ls /dev/pts/t* | wc -w
<...should be 1000>

cheers!