cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4221
Views
0
Helpful
11
Replies

Error opening vty no more tty lines error

Hello Community,

Whenever I attempt to run a Tcl script I get the following error message:

Tcl policy execute failed: cannot get pty for exec: Error opening vty no more tty lines

I inreased the number of vty lines to 10 but every I run the script it takes virtually all the lines, see below.

Can someone please help

Brislington_DM001#show line

   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int

     0 CTY              -    -      -    -    -      0       0     0/0       -

     5 AUX   9600/9600  -    -      -    -    -      0       0     0/0       -

*    6 VTY              -    -      -    -    -    127       0     0/0       -

*    7 VTY              -    -      -    -    -     12       0     0/0       -

*    8 VTY              -    -      -    -    -      0       0     0/0       -

*    9 VTY              -    -      -    -    -     22       0     0/0       -

*   10 VTY              -    -      -    -    -      2       0     0/0       -

*   11 VTY              -    -      -    -    -      1       0     0/0       -

*   12 VTY              -    -      -    -    -      0       0     0/0       -

*   13 VTY              -    -      -    -    -      0       0     0/0       -

*   14 VTY              -    -      -    -    -      0       0     0/0       -

    15 VTY              -    -      -    -    -      0       0     0/0       -

    16 VTY              -    -      -    -    -      0       0     0/0       -

Cheers

11 Replies 11

Jeffrey Ness
Level 1
Level 1

I had this problem when I first started writing EEM TCL scripts and found it was due to opening an exec session to execute CLI commands and not closing the session at the end of the script using cli_close.

Jeffrey,

Thanks for responding.

I've read somewhere that your suggestion may be the cause. However, the exact same script works on a number of other other devices.

I think there must be fundamental problem..

For almost all versions of EEM in IOS, once the EEM script exists any open vty's will be automatically closed even if you don't explicitly call cli_close.  It has been this way for a really long time.  The only exceptions might be if there is a bug, if you have a really long max run timer or if you use high performance eem policies (which don't actually exit but instead wait with the tcl shell still loaded for the next event to come in).  Another possibility is if you get events fast enough to consume vty's faster than they can be cleared but this does not appear to be what is happening here based on the show line output provided since the number of uses is not increasing on the higher numbered lines.

It would be difficult to help in this situation simply due to a lack of information.  What version of code and platform is being used in both the functional and non-functional cases?  What is the script doing?  What is the EEM config on the device?  AAA config if any?

Mike

Hi Mike, thanks for responding.

The maxrun timer is 20 seconds.

As I mentioned, I have run the exact script on the routers with the exact specification as the this one.

The version is as follows:

Brislington_DM001#show ver
Cisco IOS Software, C181X Software (C181X-ADVIPSERVICESK9-M), Version 12.4(6)T7, RELEASE SOFTWARE (fc5)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 29-Mar-07 02:54 by khuie

ROM: System Bootstrap, Version 12.3(8r)YH12, RELEASE SOFTWARE (fc1)

Brislington_DM001 uptime is 18 weeks, 2 days, 12 hours, 32 minutes
System returned to ROM by Reload Command
System restarted at 20:37:28 BST Thu Oct 18 2012
System image file is "flash:c181x-advipservicesk9-mz.124-6.T7.bin"

You continued assistance in resolving this issue will be greatly appreciated.

Cheers

Carlton

Hello Community,

I think I may have found the problem, (but don't know of a remedy)

I did show flash and noticed all the tcl files that I have been trying write to flash, as described above, but wouldn't work,  see below (all the tcls showing errorsInterfaceErrors are the Tcl's that I want to remove).

9125 Feb 22 2013 17:04:30 +00:00 errorsInterfaceErrors1234.tcl

20        9119 Feb 23 2013 23:09:14 +00:00 errorsInterfaceErrors44.tcl

21        9122 Feb 23 2013 23:43:48 +00:00 errorsInterfaceErrors223.tcl

22        9119 Feb 24 2013 00:12:30 +00:00 errorsInterfaceErrors55.tcl

25        9122 Feb 24 2013 08:20:56 +00:00 errorsInterfaceErrors777.tcl

However, when a run the delete flash:errorsInterfaceErrors44.tcl (or any of the other tcl's) I get the following error message:

File in use in an incompatible mode

I think if I can somehow delete the tcl I believe the original problem will be resolved.

You're help will be greatly appreciated.

Cheers

Carlton

Hi Carlton,

You stated:

I did show flash and noticed all the tcl files that I have been trying write to flash, as described above, but wouldn't work

Maybe I missed it but I don't see where you described this above.

It will be very difficult to understand what might be happening without actually seeing the script you are using.  There are different ways to write to files and there is a chance that not being able to delete the files is simply a symptom of the actual issue rather than the cause.  If the scripts are not exiting after the max run timer, then most likely we will also need the output of some debug commands to try and figure out what is going on.  The output of 'show flash: all' might be helpful though. If you are not comfortable providing this level of detail in a public forum I would suggest opening a TAC case and providing the TAC case number to me in a private message.

I do not have easy access to a lab today to double check the debug commands so I can not be certain of which ones to ask for for the specific version of code you are running.  I can provide more guidance tomorrow.  12.4(6)T7 is very old code with respect to EEM though.

Mike

Hi Mike, thanks for responding and sorry for the delayed response.

I will provide the output of the show flash all tomorrow and the actual script. I really need to fix this issue.

Thanks for sticking with me on this

Cheers

Hi Carlton,

Please check whether your EEM policy triggering leads to same policy execution again and again.  If there is a loop in repeated execution, it would consume the ALL vty lines. 

Just to give a background. Prior to EEM policy exection, EEM would check for availability of TWO FREE vty lines. One for the EEM policy to execute and another one for others to use(like telnetting to the box).  If there is no two vty lines free, you would be getting the 'no more vty lines error'

Looks like your box supports at max 16 vty lines and it is exhausted due to repeated call to cli_open. 

              The repeated calls

                       - May be due to logic issue in the EEM policy itself and enters the loop and calls cli_open.  OR

                       - The cli_open is executed by various EEM policies at the same time as a result of events in the box OR

                       - Triggering the EEM policy invoke's the same policy again & again and it enters the loop.

You are running older version of software(compiled on 29-Mar-07).  There were some defects that are resolved  for restricting repeated executions due to EEM policies executions(i.e point 3 mentioned above).

Would be happy to help if you need anything further.

Hi Anby,

Thanks for responding. I will look into upgrading the IOS. I will let you know how I get on.

Kind regards

Carlton

Carlton,

It seems obvious that what anbv suggests might be happening is not based on the output of show line you provided.  The number of uses on the lines is 0 for vty's 8, 12, 13 and 14.  This means that they are not cycling quickly through the vty's.  They are just sitting there and not clearing out the old used lines.  In other words the policies seem hung with the vty's opened and the max run timers are not clearing out the policies. 

I do remember troubleshooting something in the past with relation to resolving domain names causing EEM policies to remain in the pending state past the maxrun timers.  However, this was 4 and a half years ago so I'm really streching my recollection abilities here.  I don't believe it was limited to just resolving DNS names but rather any output that may have gone beyond the terminal length limit and presented the -- More -- prompt.  It was resolved by CSCsj77885.  The conditions listed in the customer visible sections of this bug are far too specific in my opinion.  Any Tcl EEM policy, regardless of how it is triggered, that takes any output via the cli_library that can send data to the console incorrectly (like the -- More -- prompt or domain name resolution) can run into this issue.  If you connect to the console and hit the space bar or the return key a few times the policies might clear out. 

Some debug commands that would be helpful:

debug event manager tcl cli_library

debug event manager common

debug event manager server

And show command output when policies are hung:

show event manager policy pending

show event manager policy active

These show commands may be version dependent.  I was testing with 12.4(24)T8 which has EEM version 3.0.  You may need to use different 'show event manager policy' commands to show the hung commands.

Mike

Edit:  Corrected the word "thermal" to "terminal."

anbv,

I have revisited your answer, and it seems like you've hit a right note:

Please take look at error output:

MX_DMVPN_HUB6          1541987: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl: Tcl policy execute failed: cannot get pty for exec: Error opening vty no more tty lines

MX_DMVPN_HUB6          1541986: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl:     (file "system:/lib/tcl/base.tcl" line 50)

MX_DMVPN_HUB6          1541985: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl:      interp share {} stderr slave..."

MX_DMVPN_HUB6          1541984: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl:      interp share {} stdout slave

MX_DMVPN_HUB6          1541983: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl:      interp create -safe slave

MX_DMVPN_HUB6          1541982: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl: "if {$security_level == 1} {       #untrusted script

MX_DMVPN_HUB6          1541981: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl:     invoked from within

MX_DMVPN_HUB6          1541980: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl: "eval_script slave $scriptname"

MX_DMVPN_HUB6          1541979: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl:     invoked from within

MX_DMVPN_HUB6          1541978: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl:     (procedure "eval_script" line 7)

MX_DMVPN_HUB6          1541977: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl: "$slave eval $Contents"

MX_DMVPN_HUB6          1541976: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl:     invoked from within

MX_DMVPN_HUB6          1541975: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl: "cli_open"

MX_DMVPN_HUB6          1541974: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl:     while executing

MX_DMVPN_HUB6          1541973: Jul  5 08:02:56.577: %HA_EM-6-LOG: utilisationUHub6.tcl: cannot get pty for exec: Error opening vty no more tty lines

The script opens the file a vty session, but doesn't seem to close it.

Any thoughts.

Mike

I never did say thank you for your input. I would welcome your thoughts.

Cheers

Carlton

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: