07-27-2010 08:31 AM
The customer observed the same error mentioned in this thread:
https://supportforums.cisco.com/message/3038760#3038760
When running a quick report in Campus Manager (User Tracking > Reports) the following error appears:
Application error: URN_NOT_FOUND : urn "ogs_server_urn" : Not found !!.
Also, the reason here was the same, a config file with with wrong content:
NMSROOT/MDC/tomcat/webapps/cmapps/WEB-INF/lib/ctm_config.txt
Interestingly, the file was touched when a specific job started. So I assume that this job somehow scrambles up that file.
the content of the "wrong" file was:
================
#CSTM Configurations
#Thu Jul 01 11:35:32 CEST 2010
SERVER_PORT=45589
MAX_VM_PORTS=20
MAX_THREADS=100
CTM_FILE_DOWNLOAD_URL=\:ctm/FileDownload
CTM_SSL=1
CTM_URL=\:443/campus/CTMServlet
CTM_FILE_UPLOAD_URL=\:443/ctm/FileUpload
===================================
Also I found a strange "copy" of that file (or part of it) here: /opt/CSCOpx/nullctm_config.txt
root@server # cat /opt/CSCOpx/nullctm_config.txt
#CSTM Configurations
#Sat Jul 10 11:40:22 CEST 2010
SERVER_PORT=54456
root@sdeu1120 #
the timestamp of both files:
-rw-rw-r-- 1 casuser casusers 226 Jul 10 11:40 /opt/CSCOpx/MDC/tomcat/webapps/cmapps/WEB-INF/lib/ctm_config.txt
-rw-r----- 1 casuser casusers 70 Jul 10 11:40 /opt/CSCOpx/nullctm_config.txt
The job showed up with /usr/ucb/ps -gauxwww as follows:
casuser 21770 0.0 0.316640095080 ? S 11:40:00 0:44 CSCO.1599 -cw /opt/CSCOpx -cw:jre /opt/CSCOpx/MDC/jre -Xmx1280m -Xincgc -XX:MaxPermSize=128m -Dnm.jrm.jobid=1599 -cp:p MDC/tomcat/webapps/cmapps/WEB-INF/classes/:MDC/tomcat/webapps/cmapps/WEB-INF/lib/:campus/lib/classpath/:campus/www/classpath/:MDC/tomcat/webapps/cmapps/WEB-INF/lib/ctm.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/iText.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/log4j.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/ogs-client.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/ogs-server.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/ogs-sharedasa.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/ogs-sharedgroup.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/ogs-sqlasa.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/ogs-testasa.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/ogs-util.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/struts.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/uii.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/utng.jar:MDC/tomcat/webapps/cmapps/WEB-INF/lib/xerces.jar:campus/lib/classpath/servlet.jar:campus/www/classpath/share.jar:campus/www/classpath/ogs-client-sign-1-3.jar:campus/www/classpath/ogs-cmclient1.2-sign-1-3.jar:campus/www/classpath/ogs-server-sign-1-3.jar:campus/www/classpath/ogs-util-sign-1-3.jar:campus/www/classpath/share-sign-1-3.jar:campus/www/classpath/log4j.jar:campus/www/classpath/ogs-client.jar:campus/www/classpath/ogs-server.jar:campus/www/classpath/ogs-cmclient1.2.jar:campus/www/classpath/xerces.jar:campus/www/classpath/xerces-sign-1-3.jar:campus/www/classpath/ogs-util.jar:MDC/tomcat/shared/lib/xerces.jar:MDC/tomcat/shared/lib/MICE.jar:MDC/tomcat/shared/lib/NATIVE.jar:MDC/tomcat/shared/lib/ctm.jar:www/classpath/SecretClient.jar:lib/classpath/servlet.jar:lib/classpath/cmfjms.jar:lib/classpath/License.jar:lib/classpath/log4j-1.2.8.jar com.cisco.nm.ani.clients.utng.application.JobRunner 1599 481 1233657331085.ser
If I remember well this job was of the type "Switch Port Report-Switch Port Summary". But I could not see this job. The reason for this could be that there were a huge amount of jobs listed in CS > Server > Admin > Job Browser: more then 30 000 history entries.
After cleaning up the number of history jobs, the same error appeared again a few day later. What can cause this strange error ?
Solved! Go to Solution.
08-28-2010 05:55 PM
You can add the property to both files. It does not hurt.
Note the line REGISTRY_LOCATION in the cmapps file. This line tells CSTM where to find its registry files. There is only one registry that is shared between both Campus Manager and UT (campus and cmapps). Therefore, you will never see a registry under the cmapps directory tree.
The bug is not being fixed in LMS 4.0. It will be release noted, and a fix is expecting in a future release. The files are opened for read-write access since the port number property may need to be updated if the port in question is already being used. Adding the DYNAMIC_PORT_ALLOCATION=0 property ensures that the files are never overwritten, but could lead to a port conflict if another, non-LMS app tries to occupy the configured CSTM TCP port.
07-29-2010 04:08 PM
08-26-2010 07:20 AM
thanks!
As I noticed, the same file is in both these directories:
A) /opt/CSCOpx/MDC/tomcat/webapps/campus/WEB-INF/lib/
B) /opt/CSCOpx/MDC/tomcat/webapps/cmapps/WEB-INF/lib/
and only the one in B) was bad.
so I just copied the one from A) to B) and restarted the services.
Interestingly, some days later again a problem occured when trying to create UT > Reports but both files where ok;
I noticed that there are these 2 files in the above directories, also:
ctmregistry
ctmregistry.backup
The files in A) had a timestamp that was 1h after daeomon start whereas the files in B) had an older timestamp (around 1 month ago, with the same time (but not date) when ctm_config.txt did get corrupted)
I did copy the files from A) to B) without restarting the daemon and the problem seems to be gone. But I do not think it is a proper way to go ...
If these files are deleted I assume they will be recreated when dmgtd gets restarted (we will do the test this evening) - So I think it would be a good idea, that if the issue with ctm_config.txt appears one should also delete ctmregistry and ctmregistry.backup.
08-26-2010 02:28 PM
The ctmregistry files can be deleted as they will be recreated when dmgtd is restarted. You should not need to delete them if ctm_config.txt becomes corrupt, but under certain situations, the ctm_config.txt corruption could lead to bad data in ctmregistry, so you can try deleting the registry as well.
08-27-2010 06:13 AM
I am still confused with this error...
after the first occurence of the problem I added the line (DYNAMIC_PORT_ALLOCATION=0) to ctm_config.txt as you suggested, restarted the service and the problem was gone;
is it necessary to do this also for the file in the campus path?
/opt/CSCOpx/MDC/tomcat/webapps/campus/WEB-INF/lib
a week later or so the customer said that the problem reoccured without corruption of ctm_config.txt - could this be possible?
As I described above, according to the timestamps of ctmregistry (in cmapps) it was not rewritten after dmgtd restart - ok - but why was it possible to generate the UT > Reports without a problem first an later not?
this is what I observed with the last test:
after deleting ctmregistry in both directries it was only recreated in
/opt/CSCOpx/MDC/tomcat/webapps/campus/WEB-INF/lib
around 20 mins afer ANIServer start time and it did not get created in
/opt/CSCOpx/MDC/tomcat/webapps/cmapps/WEB-INF/lib
although, the reports in UT > Reports > Report Generator are running fine
I assume ctmregistry in cmapps will get created on the first request but this is not the task of generating the report. Instead I think another tasks/action creates this file but when it exists the Report Generater makes use of it. I observed that with a bad ctmregistry file and a good ctm_config.txt in
/opt/CSCOpx/MDC/tomcat/webapps/cmapps/WEB-INF/lib
the Device Selector for UT > Reports > Report Generator did not show any Devices...
so I am a little confused about this behaviour...
Is there/will there be a patch available for LMS 3.2 that prevents ctm_config.txt to get corrupted? It is a config file - shouldnt it be opened read-only by any LMS process?
08-28-2010 05:55 PM
You can add the property to both files. It does not hurt.
Note the line REGISTRY_LOCATION in the cmapps file. This line tells CSTM where to find its registry files. There is only one registry that is shared between both Campus Manager and UT (campus and cmapps). Therefore, you will never see a registry under the cmapps directory tree.
The bug is not being fixed in LMS 4.0. It will be release noted, and a fix is expecting in a future release. The files are opened for read-write access since the port number property may need to be updated if the port in question is already being used. Adding the DYNAMIC_PORT_ALLOCATION=0 property ensures that the files are never overwritten, but could lead to a port conflict if another, non-LMS app tries to occupy the configured CSTM TCP port.
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