[SOLVED] Error "System has no more ptys." when using "expect" and "spawn"

[Lee]

Update 2012-12-14 1807:   Changed subject to better reflect the issue.  Original Subject was
       The system has no more ptys.  Ask your system administrator to create more.
  Marked as [SOLVED] since the functionality now works (with sudo).

I'm trying to use an "expect script to send a simple command to a remote box via ssh.  The script looks like this:

Code: [Select]

#!/usr/local/bin/expect
# whack871 - log in to the cisco 871 and warm boot it entirely under script
#            control.
#

# set Variables from arguments
set ipaddr [lrange $argv 0 0]
set user [lrange $argv 1 1]
set password [lrange $argv 2 2]
set command [lrange $argv 3 3]
#
set arg1 [lrange $argv 4 4]
set timeout -1
#
# connect to remote ssh server (ipaddr) with given command to execute
spawn ssh $user@$ipaddr $command $arg1
match_max 100000
#
# Look for password prompt
expect "*?assword:*"
#
# Send password aka $password
send -- "$password\r"
#
# send blank line (\r) to make sure we get back to gui
send -- "\r"
expect eof

and is invoked like this:

Code: [Select]

whack871 <IP ADDRESS> <USERNAME> <PASSWORD> <COMMAND>
with command in quotes if it contains spaces.

but it results in this:

Code: [Select]

spawn ssh tc@192.168.0.97 xtrlock
The system has no more ptys.  Ask your system administrator to create more.
    while executing
"spawn ssh $user@$ipaddr $command $arg1"
    (file "/home/tc/bin/whack871" line 18)

Under Cygwin on Windows Server 2008 R2, I can use this to warmboot my router.

Under Core 4.7.1, I cannot use this to send a command to another Core 4.7.1 box.  Booting the local box with the multivt boot code does not seem to help.

I have openssh.tcz, expect.tcz and tcl.tcz loaded and I can ssh to the remote box.

Does anyone know how to add more ptys ?

[gerald_clark]

Try the boot code 'pty.legacy_count=32'
---- Edit ----
I tried it.  It looks like legacy ptys are not enabled in the kernel.

[Lee]

Thanks gerald_clark.

I was hoping for a simple boot code solution and it looks like that would have been it.

I'll look for a work around using something other than "spawn" - maybe something with exec and redirection.  If that doesn't work, is there any down-side that you know of to enabling legacy ptys in the kernel?

[tinypoodle]

What is output of

Code: (bash) [Select]

cat /proc/sys/kernel/pty/maxand of

Code: (bash) [Select]

watch -n 1 cat /proc/sys/kernel/pty/nrjust at the moment you get the error?

[Lee]

cat /proc/sys/kernel/pty/max

says 4096


watch -n 1 cat /proc/sys/kernel/pty/nr

shows an unchanging  2

[tinypoodle]

Could you check for same on target machine?

[Lee]

On the target machine it is pretty much the same, except

watch -n 1 cat /proc/sys/kernel/pty/nr

shows 6

This number reflects the number of terminal windows open - it goes up as I open additional ssh sessions - which is really what I want the expect script to do anyhow. I wonder if I can replace that spawn command with something else.

When I run the watch command on the remote box and run the expect script on the remote box, it is exactly as when I run them on the local box.

When I run the watch command on the remote box and the expect script on the local box, the watched value still does not change.

[curaga]

Expect should work fine with current PTYs. In fact, when I run your script here, it works as is.

I wonder if something is changing your permissions, on the host where you run expect. What's your permissions for /dev/ptmx and /dev/pty?

[Lee]

Code: [Select]

tc@apollo:~$ ls -l /dev/ptmx /dev/pty
ls: /dev/pty: No such file or directory
crw-rw-rw-    1 root     staff       5,   2 Dec  2 09:13 /dev/ptmx
tc@apollo:~$
tc@apollo:~$
tc@apollo:~$ ls -l /dev/ptmx /dev/pty?
ls: /dev/pty?: No such file or directory
crw-rw-rw-    1 root     staff       5,   2 Dec  2 09:13 /dev/ptmx
tc@apollo:~$

This is with the multivt boot code that I added in yesterday:

Code: [Select]

tc@apollo:~$ cat /proc/cmdline
quiet host=cruzr0 noutc tz=GMT+5 tce=LABEL=cruzr0/boot/core4.7.1/tce waitusb=30:LABEL=cruzr0 multivt


[curaga]

Typo, /dev/pts not pty.

[Lee]

Ok then.  I was a little worried for a minute there. 

Code: [Select]

tc@apollo:~$ ls -l /dev/ptmx /dev/pts
crw-rw-rw-    1 root     staff       5,   2 Dec  2 11:27 /dev/ptmx

/dev/pts:
total 0
crw-------    1 tc       staff     136,   0 Dec  2 11:27 0
c---------    1 root     root        5,   2 Dec  1 09:54 ptmx
tc@apollo:~$

The mention of permissions gave me the idea to try the whole thing using sudo... and that worked, though I had to tweak my script a bit to be able to pass arguments to the remote command.

Still, it seems like it ought to be able to do this as non-root.

[curaga]

Sorry, I mean the pts dir itself - "ls -lhd /dev/pts".

[Lee]

Code: [Select]

tc@apollo:~$ ls -lhd /dev/pts
drwxr-xr-x    2 root     root           0 Dec  1 09:54 /dev/pts/
tc@apollo:~$

Looks like only root can write to the directory...

[gerald_clark]

Why would you want to write to that directory?

[tinypoodle]

So it seems like that error msg is misleading and comes down to a permission issue.

BTW, just wondering, have you considered key authentification rather than using password?