03-05-2009 07:14 AM - edited 03-06-2019 04:24 AM
Has anyone seen this before? This is definitely a first for me.
Here is the problem:
If I telnet to a router and execute the "sh start" command and then try to execute it again using another remote telnet session, the startup config will not open up.
The error message I get is the following:
%Error opening nvram:/startup-config (Device or resource busy)
The way to eliminate this message is to terminate the original telnet session OR return to the command prompt in the original telnet window. In other words, when executing the "sh start" command, do not leave it where there is still "-more-" configuration to view. Type any letter to break it and get back to the command prompt. If you do that, the "sh start" command will work from the second telnet session.
I think this is weird behavior and I have never seen it before. Cisco does have a webpage that dicusses it, but it doesnt elaborate on whether this is a bug or normal behavior or why this happens. They also dont tell you about returning to the command prompt on the initial session to get it to work on the second one. All they tell you to do is terminate the original session.
Any ideas?
03-05-2009 07:16 AM
Victor
Long time ...
I have seen this many times and the only way i have of working around it is as you say to either terminate the session or more often to just make sure you haven't left it at the --More-- prompt.
Not a great deal of help i know.
Jon
03-05-2009 07:22 AM
HI Victor, [Pls RATE if HELPS]
When there is simultaneous access to a router's NVRAM, you might encounter these two errors:
While you display the contents of the NVRAM with the show startup-config command:
Router#show startup-config
Using 5524 out of 129016 bytes
%Error opening nvram:/startup-config (Device or resource busy)
While you save a configuration to the NVRAM with the copy running-config startup-config command:
Router#copy running-config startup-config
Destination filename [startup-config]?
startup-config file open failed (Device or resource busy)
Solution:
=========
clear the line the other user(s) is (are) connected on and free the NVRAM, issue the clear line command.
Note: The "*" next to line No# vty No# indicates the line used in this session.If there are more multiple users, clear all of them, except for the line with the "*".
Try accessing NVRAM now !!
Hope I am Informative.
Best Regards,
Guru Prasad R
03-05-2009 07:32 AM
Jon, thanks. What you say does help because it lets me know that I have a grasp on whats going on and how to handle it.
Now mosey on over to the other thread Im about to start regarding troubleshooting ethernet interfaces. :-)
Guru:
Thanks for your input. I know where you got all that information: its from the webpage I have been reading on Cisco's website regarding this problem. Its the one I reference in my original post. Appreciate your efforts...
Victor
03-05-2009 08:08 AM
Hello Victor,
this is a common problem.
you can see nvram: as a file system and the startup-config as a file.
During sh startup-config
the file is opened for reading
we can say that the nvram: filesystem doesn't support concurrent reading.
If I remember correctly some Lan switches allow to enable concurrent access to NVRAM
Edit:
I tried what is possible with switches is concurrent access to config mode with
no configuration mode exclusive
Hope to help
Giuseppe
03-05-2009 08:19 AM
Thanks, G.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide